SBC Features and Principles

Quidway SessionEngine2000 Series Feature Description
Contents
Contents
2 Features and Principles ........................................................................................................ 2-1
Issue 02 (2007-06-30)
Huawei Technologies Proprietary
Figures
Figures
Figure 2-1 Networking of adopting default route...............................................................................................2-7 Figure 2-2 Networking adopting a VRRP virtual router.....................................................................................2-8 Figure 2-3 Typical networking of SE2000 backup .............................................................................................2-9 Figure 2-4 SE2000 backup state.......................................................................................................................2-10 Figure 2-5 Hierarchical protocol relation between VRRP management group and backup groups ................. 2-11 Figure 2-6 Data channel for transferring VGMP packets .................................................................................2-13 Figure 2-7 Relation between VRRP management group and backup group ....................................................2-14 Figure 2-8 Networking diagram of the SE2000 in master/backup mode .........................................................2-15 Figure 2-9 Data path in master/backup mode...................................................................................................2-16 Figure 2-10 Hierarchical protocol relation between VRRP backup group, VRRP management group and HRP ...........................................................................................................................................................................2-17 Figure 2-11 Register flow.................................................................................................................................2-19 Figure 2-12 Call flow .......................................................................................................................................2-20 Figure 2-13 Media processing flow..................................................................................................................2-21 Figure 2-14 Typical networking application of the SE2000 .............................................................................2-22 Figure 2-15 Communication between the SE2000 and Softx3000...................................................................2-23 Figure 2-16 Typical networking in single domain mode ..................................................................................2-24 Figure 2-17 Typical networking in multi-domain mode...................................................................................2-25 Figure 2-18 IP addresses related to the SE2000 ...............................................................................................2-25 Figure 2-19 Ports related to the SE2000...........................................................................................................2-27 Figure 2-20 Typical signaling stream and media stream of the SE2000 media stream bypass process............2-28 Figure 2-21 Networking diagram of address overlapping ................................................................................2-30 Figure 2-22 Networking model of the UDP tunnel ..........................................................................................2-32 Figure 2-23 UDP tunnel header........................................................................................................................2-33 Figure 2-24 UDP tunnel packet structure .........................................................................................................2-33 Figure 2-25 Schematic diagram of signaling and media stream direction when the SBC function is disabled on the SDD.............................................................................................................................................................2-35
Issue 02 (2007-06-30)
iii
Figures
Figure 2-26 Schematic diagram of signaling and media stream direction when the SBC function is enabled on the SDD.............................................................................................................................................................2-36 Figure 2-27 Networking diagram of SDD hot-system hot backup ...................................................................2-37 Figure 2-28 Networking diagram of signaling and media stream in the C-BGF feature..................................2-38
iv
Issue 02 (2007-06-30)
Tables
Tables
Table 2-1 Device state in master/backup mode ................................................................................................2-15
Issue 02 (2007-06-30)
2 Features and Principles
2
About This Chapter
Section 2.1 Attack Defense 2.2 Dual-System Hot Backup Error! Reference source not found.Error! Reference source not found. 2.3 Full Proxy of NAT 2.4 Address Overlapping 2.5 UDP Tunnel 2.6 Large Capacity 2.7 C-BGF
Features and Principles
The following table shows the contents of this chapter. Description This section describes attack defense. This section describes the dual-system hot backup. This section describes dual-homing.
This section describes the full proxy of NAT traversal. This section describes the address overlapping. This section describes the UDP tunnel. This section describes the large capacity. This section describes the C-BGF.
Issue 02 (2007-06-30)
2-1
2.1 Attack Defense

The network attacks intrude or destroy network servers or hosts to steal sensitive data on the servers or interrupt server services. Certain network attacks even directly destroy network devices. In the event of a network attack, the service becomes abnormal or even stops functioning. The attack defense of the SE2000 can detect various types of network attacks and take the measures to protect internal networks from malicious attacks. As a result, the SE2000 can ensure that the internal networks and systems run normally.
2.1.1 Types of Network Attacks

Network attacks can be classified into the following three types: DoS attack Scanning and snooping attack Defective packet attack
DoS Attack
The Denial of Service (DoS) attack attacks a system by sending a large number of data packets. As a result, the system cannot receive requests from valid users or the host is suspended and cannot work normally. The DoS attacks include: SYN Flood Fraggle ICMP UDP Flood The DoS attack differs from other types of attacks. In the DoS attack, attackers prevent valid users from accessing resources or routers. In other types of attacks, attackers search for ingresses of internal networks.
Scanning and Snooping Attack

The scanning and snooping attack detects a potential target by identifying an existing system in the network by means of ping scanning (including ICMP and TCP). Through TCP and UDP port scanning, the attacker detects the running system and monitors its services and then gets a general idea of its service type. The attacker also traces the potential security defect of the system so as to prepare for the further intrusion.
Defective Packet Attack

The defective packet attack sends a defective IP packet to the destination system so that the system crashes when it processes the IP packet. The defective packet attacks include Ping of Death and Teardrop.
2-2
Issue 02 (2007-06-30)
2.1.2 Typical Network Attacks

Signaling Attack
The signaling attack attacks a system by sending a large number of SIP, MGCP and H.323 signaling. In case of a Flood attack, the SE2000 discards packets once a fault occurs. In case of a signaling attack, the SE2000 classifies the signaling into different priority queues according to the user registration and user access statistics. The users with a higher priority enjoy more and higher-level services, and the users with a lower priority enjoy less and lower-level services. Thus, the SE2000 can protect itself and the Softx3000 as well as provide services for valid users. On the SE2000, the unregistered users have a lower priority and the registered users have a higher priority. The users who are prone to attack have a lower priority and the normal users have a higher priority.
Fraggle Attack
The Fraggle attack is similar to the Smurf attack, but the Fraggle attack attacks a network by sending a UDP packet instead of an ICMP packet. After receiving the UDP packets, both the UDP port 7 (ECHO) and 19 (Chargen) respond to the packets. The port 7 responds with the packet which is the same as the received packet, while the port 19 generates a character string. Thus, a large number of response packets are generated and returned to the source host and as a result, the source host crashes. The attacker sends UDP packets to the subnet broadcast address. The source addresses of these UDP packets are the IP addresses of the attacked host or network. Port numbers of hosts in the subnet are 7 or 19. The Fraggle attack causes each system to respond to the attacked host and then a large number of packets are sent; as a result, the network is congested or the attacked host crashes. If the Fraggle attack is disabled in the subnet, the system generates an ICMP unreachable message that continues to occupy the bandwidth. If the source port of the attacked host is "Chargen" and the port of the target host in the subnet is "ECHO", response packets are generated continuously. The Fraggle attack, thus, becomes more harmful to the attacked host.
Land Attack
The Land attack configures both the source address and the destination address of a TCP SYN packet as the IP address of the attack target. Thus, the target sends the SYN-ACK message and sends back the ACK message to the target itself, forming a null connection. All the null connections exist until timeout. Different targets have different responses to the Land attack. For instance, many UNIX hosts will crash while the Windows NT hosts slow down.
Ping of Death Attack and Extra-Large-ICMP Packet Attack

The extra-large-ICMP packet attack attacks a network system by sending large-sized ICMP packets. The Ping of Death attack is a particular case in the extra-large-ICMP packet attack. The field length of an IP packet is 16 bits and the maximum length of an IP packet is 65535. If the data length of an ICMP request packet is greater than 65507, the entire length of the ICMP packet (ICMP data + IP header 20 + ICMP header 8) will be greater than 65535. Upon receiving such a packet, the routers or systems may crash, die or reboot.
Issue 02 (2007-06-30)
2-3
WinNuke Attack
The WinNuke attack causes a NetBIOS fragment overlap by sending an Out-Of-Band (OOB) data packet to the NetBIOS port (139) of the specific target that is installed with the Windows system. The WinNuke attack causes the target host status to be Down. Besides, an IGMP fragment packet can also cause the target host to be Down. This is because the IGMP packet cannot be fragmented and few systems can resist the attack caused by an IGMP fragment packet. If a host receives an IGMP fragment packet, it means that the host is under a WinNuke attack.
SYN Flood Attack

The TCP/IP protocol stacks permit only a restricted number of TCP connections due to the limited resources. The SYN Flood attacker takes advantage of the situation to forge a SYN packet with a fake source address or a non-existent address and initiates a connection to the server. The server, therefore, will not receive any ACK packet for its SYN-ACK response packet and semi-connection forms. A large number of such semi-connections will exhaust the network resources. As a result, valid users cannot access the network until the semi-connections time out. The SYN Flood attack also takes effect in the applications whose connection number is not limited to consume system resources such as the memory.
ICMP and UDP Flood Attack

The ICMP and UDP Flood attack sends a large number of ICMP messages (such as ping) and UDP packets to the specific target to seek response in a short time. The target system is therefore unable to process valid packets normally.
IP Spoofing Attack
To get an access authority, an intruder generates a packet with a fake source address. This fake source address allows an unauthorized client to access the system by applying the IP authentication even in the root authority. This may destroy the system even though the response packet does not reach the system. This is known as the IP Spoofing attack.
Address/Port Scanning Attack

Address/port scanning attack detects the target address and port via scanning tools. The attack traces the active system and connects to the target network to receive responses from the system and the port. The system and the port are used by the host to provide services.
ICMP Redirect and ICMP Unreachable Packet Attack

Normally, the network device sends the ICMP redirect packets to the hosts in the same subnet to request the hosts to change their routes. The malicious attacker, however, may send a fraud redirect packet to the host in another network to change the host's routing table and to disturb the host's normal IP packets forwarding. On receiving the ICMP packets that cannot reach the network (the code is 0) or the host (the code is 1), some systems consider the subsequent packets sent to this destination to be still unreachable. The system then disconnects the destination and the host.
Route Record, Source Route and Timestamp Attack

The following three IP packet options are used to test or debug the network.
2-4
Issue 02 (2007-06-30)
Route-Record records the routers through which the packets pass before arriving at the destination. Source-Route shows a route that goes across the Internet specified by the source host. Timestamp records the time and the date when the router processes data. They, however, may be used to probe the architecture of the Intranet viciously.
Teardrop Attack
The More Fragment (MF) bit, Offset field and Length field in an IP packet show which segment of the original packet is contained in this fragment. Some systems running TCP/IP crash when they receive a bogus segment containing an overlap offset. The Teardrop attack makes use of the flaw of some systems that do not find the validity of fragment information to attack the system.
IP Fragment Packet Attack

Some fields in the IP packet are related to fragmentation, such as Don't Fragment (DF) bit, More Fragment (MF) bit, Fragment Offset and Length. If the following problems occur and they are not given proper handling, the device is affected and even breaks down. DF bit and MF bit are set at the same time or fragment offset is not 0. DF bit is 0 but fragment offset + length > 65535. In addition, the device must directly discard the fragment packet, whose destination address is the same as the device address, because such a packet burdens buffer and reassembly of the destination device.
Smurf Attack
The simple Smurf attack attacks a network by sending an ICMP request to the broadcast address of the target network. All the hosts in the network respond to the request and thus the network is congested. The advanced Smurf attack attacks the target host by setting the source address of the ICMP request packet as the address of the target host to crash the host finally. The attack takes effect when so many attack packets are sent out over a long period that the network is congested. Theoretically, the more hosts are in the network, the more obvious the effect is. Another new form of the Smurf attack is Fraggle attack.
Tracert Packet Attack

By tracing the paths of a returned ICMP timeout packet with Time to Live (TTL) value being 0 and ICMP port-unreachable packet, the Tracert attack can pry into the architecture of the network.
2.1.3 Monitor Technologies in Attack Defense

In the attack defense, you can check whether the network is suffering from the attack according to the abnormal data detected on the SE2000. The data to be detected includes: CPU utilization of the SE2000
Issue 02 (2007-06-30)
2-5
Traffic that passes the SE2000 When the CPU utilization of the SE2000 exceeds the upper limit, an alarm about abnormal CPU utilization is raised. When the CPU utilization restores its normal state, an alarm about normal CPU utilization is raised. When the traffic that passes the SE2000 exceeds the upper limit, an alarm about abnormal traffic is raised. When the traffic reduces to less than the value of "the threshold x the security coefficient", an alarm about normal traffic is raised.
2.1.4 Call Admission Control

Call Admission Control (CAC) is mainly used to limit: Total number of registered users Number of the concurrent calls User register rate Call rate The total number of registered users and the number of the concurrent calls are limited for all users who pass the SE2000. The limit on register rate and call is applied to specific users. When the connection rate of a user is too fast, its connection is limited. In abnormal conditions, the CAC can protect the SE2000 and Softx3000, and provide services for normal users.
2.1.5 Session-based CAR

Committed Access Rate (CAR) is used to control the traffic of packets. The SE2300 classifies the packets according to pre-set matching rules. For the packets without traffic control, the SE2000 forwards them directly. For the packets with traffic control, the SE2300 limits its bandwidth according to pre-set rules of traffic control. Based on the session-based CAR technology, users can get various bandwidths of media stream and Differentiated Services CodePoint (DSCP) value. A maximum of 16 CAR levels can be pre-set, with different bandwidths and DSCP values at each level. The matching policy between end users and CAR levels are listed below: If the registered user on the SE2300 is a caller, you should match the called number first (for MGCP and H.248 users, you must match domain name first), and then match the calling number. If the registered user on the SE2300 is a callee, you must match only the called number. After the matching succeeds, the user can obtain bandwidth and DSCP value of the corresponding level. If session-based CAR technology is adopted, we can allocate network resources more flexibly, guarantee the quality of service, and prevent bandwidth embezzlement at the same time.
2-6
Issue 02 (2007-06-30)
2.2 Dual-System Hot Backup

2.2.1 Stand-alone Default Route
Usually, each host on an internal network is configured with a default route to the next hop, which is the IP address of the egress router; that is, 10.100.10.1 as shown in Figure 2-1. Each host on the internal network that wants to access external networks will send packets to the egress Router A, which forwards these packets. In this way, internal hosts can communicate with external networks. Figure 2-1 Networking of adopting default route
10.100.10.1 Internet RouterA
PC Server Internal network 10.100.10.0/24
In default route mode, there is only one router at the egress of the internal network. When the Router A fails, all hosts (whose default next hop is Router A) on the internal network will fail to communicate with external networks. Therefore, communication is unreliable in the default route mode.
2.2.2 VRRP Overview

Virtual Router Redundancy Protocol (VRRP) addresses the communication problem in default route mode. As a type of redundant backup protocol, VRRP applies to a LAN that supports multicast or broadcast, such as Ethernet. It organizes several devices on a LAN together into a virtual device, named a backup group. In a backup group, only one device is in active state, which is named Master. Others devices are in monitoring state and are ready to take over traffic at any time based on the priority, and these inactive devices are named Backups. In the VRRP backup group, each member has a priority value in the range of 1 to 255. The VRRP determines the state of members based on their priorities. The member with the highest priority becomes the Master. Figure 2-2 shows a backup group composed of three routers.
Issue 02 (2007-06-30)
2-7
Figure 2-2 Networking adopting a VRRP virtual router

10.100.10.2 Master RouterA
PC Server Internal network 10.100.10.0/24
10.100.10.3 Backup RouterB Backup RouterC
Internet
Backup group Virtual IP Address 10.100.10.4 10.100.10.1
Routers A, B and C make up of a backup group (act as a virtual router), whose virtual IP address is 10.100.10.1. Router A is the Master with the IP address 10.100.10.2. Routers B and C are Backups with addresses 10.100.10.3 and 10.100.10.4 respectively. In VRRP only Master device can forward the packet that takes virtual IP address as the next hop. All hosts on the internal network just know the virtual IP address 10.100.10.1, instead of the IP address of the Master or Backup. Therefore, each host configures its default route as the virtual IP address. All hosts on the internal network thus can communicate with external networks through this backup group. The VRRP module on the master router monitors the state of communication interface and sends notification packets to the backup routers in multicast mode. When the master router fails (such as interface or link faults), the VRRP notification packets would not be sent as usual. When the backup routers do not receive any VRRP notification packet in a specific interval, the backup router with the highest priority will change its state from the VRRP state to the master state, based on the VRRP protocol. In this way, the services running on the previous master router will continue to run on the new master router. As a result, the VRRP enables communication to be uninterrupted, and ensures reliability.
2.2.3 Disadvantages of Traditional VRRP on the SE2000

In the current networking application, users have requirement for higher network reliability. Users require that communication should be uninterrupted particularly in the following cases: At some important service ingress At access points of terminals traversing NGN network As a session border controller, the SE2000 is usually located between enterprise networks and the NGN network to provide signaling proxy and media proxy services. If only one SE2000 connects the enterprise network and the NGN, the network may be interrupted due to single point failure, though the SE2000 is very reliable. In this case, redundancy backup mechanism is developed to improve the stability and reliability of the entire system.
2-8
Issue 02 (2007-06-30)
One side of the SE2000 is connected with enterprise networks or Customer Premises Network (CPN), and the other side is connected with NGN network. The route redundancy backup is fulfilled by two SE2000s. One acts as the master device, while the other acts as the backup device. Interfaces on the master device and the backup device are connected with networks separately.
Typical Networking of SE2000 Backup

Based on the traditional VRRP, each network needs a VRRP group to monitor the working state of interfaces connected with the network. The interfaces connected with each network on SE2000 form a backup group (the virtual router) and each group is assigned with a virtual IP address, as shown in Figure 2-3. Figure 2-3 Typical networking of SE2000 backup
Backup group 1 Virtual IP Address 10.110.10.1
Enterprise network 1
SE2000-A Master
SoftX3000
10.100.10.0/24
NGN network
Backup group 3 Virtual IP Address 202.38.10.1
Backup
Backup group 2 SE2000-B Virtual IP Address 10.110.20.1
10.100.20.0/24
SE2000 A is the master device and SE2000 B is the backup device. Interfaces connected with enterprise network 1 on the master and backup devices compose backup group 1. Its virtual IP address is 10.100.10.1. Interfaces connected with enterprise network 2 on the master and the backup device compose backup group 2. Its virtual IP address is 10.100.20.1. Interfaces connected with the NGN on the master and backup devices compose backup group 3. Its virtual IP address is 202.38.10.1.
State Requirements for SE2000 Backup

The SE2000 dynamically maintains a state entry for each session between the audio and video terminals. Only the subsequent packets that match the session entries can pass through the SE2000. Therefore, the inbound path and the outbound path of the same session must be consistent, as shown in Figure 2-4.
Issue 02 (2007-06-30)
2-9
Figure 2-4 SE2000 backup state

(1) (8) IAD Enterprise network 1 (7) (6)
SE2000-A Master
Session entry
(2)
SoftX3000
(3)
NGN network
(9) IAD Enterprise network 2

SE2000-B Backup
Actual connection Packet traffic
(5)
(4)
Other terminal
If an audio or video terminal in enterprise network 1 accesses one terminal in another enterprise network or CPN, a packet is sent along the path (1)-(2)-(3)-(4) as shown in Figure 2-4. When the signaling flow or media stream passes SE2000 A, a dynamic session entry is generated. When the signaling flow or media stream returns from terminals in other enterprise networks along the path (5)-(6)-(7)-(8), it can match with the session entry and successfully reach the host. In this case, VRRP state of both the SE2000 is consistent. If the session entries on SE2000 A differ from those on SE2000 B, the returned signaling flow or media stream might be sent along the path (5)-(9). In this case, it may not match session entries on SE2000 B and hence is discarded. As a result, the communication is interrupted. In other words, if the VRRP state is consistent, the state of interfaces connected with various networks on the SE2000 is identical, that is, all the interfaces are either in master state or in backup state. In addition, one side of the SE2000 is connected with enterprise networks and the other side is connected with the NGN network. Interfaces on the SE2000 connected with each network make up of a backup group. Based on the traditional VRRP mechanism, VRRP in each backup group works in an independent state. Therefore, the state of VRRP on each interface on the same SE2000 cannot keep consistent. That is, the traditional VRRP cannot achieve a state that is consistent with the SE2000.
2.2.4 VGMP Overview

In this case, Huawei develops a protocol based on VRRP, named VRRP Group Management Protocol (VGMP). VGMP implements centralized management over VRRP state of each backup group in it, covering: State consistency management Preemption management Channel management
2-10
Issue 02 (2007-06-30)
Introduction to VRRP Management Group

VRRP management group is introduced in the SE2000 to manage many backup groups, including: State consistency management Preemption management Channel management A VRRP management group is a logical collection of several backup groups that meet some backup requirement. It performs centralized management over each backup group so that VRRP backup groups can communicate with each other. Based on backup requirements, a backup group can be added into the VRRP management group. The VRRP management group, however, cannot manage such backup groups that are not added into it.
Hierarchical Protocol Relation Between VRRP Management Groups and Backup Groups
The hierarchical protocol relation between VRRP management groups and backup groups is shown in Figure 2-5. Figure 2-5 Hierarchical protocol relation between VRRP management group and backup groups
VRRP management group VGMP packet VRRP backup group Traditional VRRP packet Interface
A VRRP management group functions as a logical layer over VRRP backup groups. The VRRP management group exchanges information between each other through VGMP packets. VRRP backup groups interact with interfaces through traditional VRRP packets. VRRP backup groups report their own states to the VRRP management group. The VRRP backup groups are managed by the VRRP management group. When there is an error on a certain interface or link in a certain backup group, the backup group state changes. As a result, the state of VRRP management group changes. In addition, some VRRP backup groups can run without need of being added into VRRP management group. The master state of these backup groups that are not joined might be inconsistent with that in the management group. To prevent this, you must configure higher priorities for backup groups in VRRP management group.
Functions of VRRP Management Group

State consistency management
Issue 02 (2007-06-30)
2-11
After VRRP group management is enabled, each backup group needs to notify the change of state to its VRRP management group. If the VRRP management group rejects to switch between the master or backup VRRP state, states of the SE2000s in this backup group cannot change. In the traditional VRRP, the VRRP cannot remain independent. In the VRRP management group, state consistency management makes it possible. The VRRP management group determines whether to switch master or backup state of each device in it so that the state of each VRRP backup group can be consistent. Besides sending notification packets to the Backup based on the traditional VRRP mechanism, the Master can also send Hello messages to the Backup. Then the Backup sends back the notification packets after receiving Hello messages. In this way, the Master and Backup can perform state communication between each other. Preemption management When a backup group is added into a VRRP management group and the VRRP management group has been enabled, preempt behavior is determined by the VRRP management group instead of the preemption configured on SE2000. In other words, whether a SE2000 performs preemption depends on the VRRP management group even though its priority is higher than that of the current Master. When communication between VRRP backup groups is interrupted, but the VGMP can still normally communicate, the state consistency can still be assured. In this case, no state switch occurs. When the Master and the Backup fail to communicate between each other, no VGMP packet can be transmitted. That is, all data channels are interrupted. In this case, the Backup will automatically switch to the master state. Therefore, two master devices are available on the network when the network communication recovers and they send notification packets to each other. In this case, the VRRP management group determines the master based on the priority. For instance, if the priority of the original Master is lower, the VRRP management group designates the original Backup the new Master. Channel management Channel management can provide reliable channels to transfer:

VGMP packets Relevant packets carrying VGMP VRRP state packets
A VRRP management group includes many data channels. You can configure them along with traffic flow channels on a physical link or configure a single traffic flow on a physical link. Moreover, you can configure whether the data channel state will affect the state of each VRRP in the VRRP management group. Figure 2-6 shows the relation between service channels and data channels.
2-12
Issue 02 (2007-06-30)
Figure 2-6 Data channel for transferring VGMP packets

SE2000-A Master A1 A3
A3 -S
1 S-B A1Enterprise network 1
A2
A4 A4-H-B4
-B
SoftX3000
3
NGN network
Hub
B1
A 2S-B 2
B4
B2
B3 Backup A1 A2 A3 are interfaces of EudemonA SE2000-B

B1 B2 B3 are interfaces of EudemonB S represents LAN Switch
Actual connection Data channel
Interfaces connected with each network on the Master can act as starting points of the data channels and ending points are on the Backup. Data channels thus traverse switches in LAN between start point and end point. In Figure 2-6, A and B stand for interfaces, S refers to LAN Switch, and A1-S-B1, A2-S-B2 and A3-S-B3 are data channels. As far as the link bandwidth is concerned, you can directly connect the Master with the Backup (multiple lines are allowed) in certain cases, to prevent VRRP state information from disturbing the traffic flow transmission. As a result, you can set up a data channel named A4-H-B4 between the Master and the Backup. H refers to hub.
Relation Between VRRP Management Group, Backup Group and Interface

Each network is configured with a VRRP backup group. At least one VRRP management group is defined for each SE2000 to manage the backup groups connected with various networks to achieve the consistency of VRRP states. The relation between VRRP management group and backup group is shown in Figure 2-7.
Issue 02 (2007-06-30)
2-13
Figure 2-7 Relation between VRRP management group and backup group
Backup group 1
SE2000-A Master A1 A3
Management group 1
SoftX3000
A2
NGN network
B1 B2
Backup group 2
Backup group 3
B3 Backup SE2000-B
Management group 1 Actual connection Traffic
A1 A2 A3 are interfaces of EudemonA B1 B2 B3 are interfaces of EudemonB
In the redundancy backup mechanism of the SE2000, the relation between interfaces, backup group and management group is described as below: Relation between interfaces on two SE2000 Connections between interfaces and networks on two SE2000 must be identical, including:

Interface slot Type Number Relevant configurations (except IP address)
For example, interface A1 on SE2000 A must be identical with interface B1 on SE2000 B. Both should be Ethernet interfaces, both should be numbered as 1/0/0 and both should belong to backup group1, and so on. Relation between VRRP backup groups on two SE2000 Backup group numbers as well as the components on two SE2000 must be completely the same. For instance, interface A1 on SE2000 A should belong to backup group1. Interface A2 on SE2000 A should belong to backup group2. Interface A3 on SE2000 A should belong to backup group3. Similarly, interfaces B1, B2 and B3 on SE2000 B should belong to backup groups 1, 2 and 3 respectively. Relation between VRRP management groups on two SE2000s Management group number as well as components on two SE2000s must be completely the same. For instance, SE2000 A should include management groups 1, 2 and 3. SE2000 B should also include management groups 1, 2 and 3. Relation between interfaces, backup groups and management groups on a SE2000 On an SE2000 (such as SE2000 A), a physical interface can associate with multiple VRRP backup groups. A backup group can associate with multiple physical interfaces
2-14
Issue 02 (2007-06-30)
and multiple virtual IP addresses. A VRRP management group can contain multiple backup groups but the same backup group cannot belong to different VRRP management groups.
2.2.5 Backup Mode Classification

Interfaces, backup groups and management groups can work with each other so that two SE2000s can fulfill master/backup mode. Based on VGMP mechanism, you can carry out backup for two SE2000s. Each SE2000 is configured with a VRRP management group with the same number but different priorities, as shown in Figure 2-8. Figure 2-8 Networking diagram of the SE2000 in master/backup mode
SE2000-A Master A1
Backup group 1
A3 SoftX3000
A2
NGN network
B1 B2
Backup group 2
Backup group 3
B3 Backup SE2000-B
Actual connection Traffic
A1 A2 A3 are interfaces of EudemonA B1 B2 B3 are interfaces of EudemonB
VRRP management group 1 on SE2000 A contains backup groups 1, 2 and 3 with level 1 priority. VRRP management group 1 on SE2000 B also contains backup groups 1, 2 and 3 but with level 2 priority. Since level 1 priority is higher than level 2 priority, SE2000 A behaves as the Master and SE2000 B behaves as the Backup. Table 2-1 Device state in master/backup mode SE2300 Management group1 Component A B Backup groups 1, 2 and 3 Backup groups 1, 2 and 3 Priority Level 1 Level 2 State Master Backup Session volume Whole 0
Issue 02 (2007-06-30)
2-15
Hosts send service data to interfaces A1, A2 and A3 on SE2000 A (Master). All sessions are transferred through SE2000 A while SE2000 B (Backup) does not transfer any data. When the Master or its links fails, its state will change. The Backup will become the Master and transfer all the session data.
2.2.6 HRP
HRP Application
The SE2000 maintains the state information on a session entry for audio or video session connection, as shown in Figure 2-9. Figure 2-9 Data path in master/backup mode
(1) (8) IAD Enterprise network 1 (7) (6) (3) NGN network SE2000-A Master
(2)
Session entries
SoftX3000
(5) IAD Enterprise network 2 SE2000-B Backup
(4)
Actual connection Traffic path
Other terminal
In master/backup mode, if SE2000 A is the Master, it takes up all the data transmission task and many dynamic session entries are set up on it. SE2000 B is the Backup device and no data passes through it. When errors occur on SE2000 A or on the associated links, SE2000 B becomes the Master and begins to transfer data. If there is no backup session entry, user registration information and configuration command on SE2000 B before the state switch, all the sessions that have passed through SE2000 A are disconnected as a result of mismatch. Services then are interrupted. To enable the Backup to smoothly take over traffic from the Master when the Master breaks down, backup configuration commands and session entries, user registration information between the Master and the Backup are necessary. Huawei Redundancy Protocol (HRP) is developed to address this issue. HRP is transmitted over VGMP packets on data channels in VRRP management group.
Master/Backup
SE2000s are grouped into Masters and Backups. The device that sends configuration backup contents is the Master. The device that receives configuration backup contents is the Backup. Only the SE2000 with the master state in the VRRP management group can become a Master.
2-16
Issue 02 (2007-06-30)
To ensure the stability of the Master, the Master remains fixed unless it fails or quits the VRRP backup group.
Configuration Command and State Information Backup

The dual-system hot backup of the SE2000 supports: Configuration commands backup User registration information backup Session state information backup The information that needs to be backed up includes: User registration information on SIP/MGCP/H.323 MGCP session entries In dual-system hot backup of SE2000, information is backed up from the Master to the Backup.
2.2.7 Hierarchy Relation Between VRRP Backup Group, VRRP Management Group and HRP
The hierarchical protocol relation between VRRP backup group, VRRP management group and HRP is shown in Figure 2-10. Figure 2-10 Hierarchical protocol relation between VRRP backup group, VRRP management group and HRP
HRP module
HRP packet
VRRP management group

VGMP packet
VRRP backup group
When the status of the VRRP management group changes, the system notifies the HRP and the Master or the Backup of the change in states. In this way, configuration commands, user registration information and session state information between two SE2000s can be backed up in time. The HRP state affects the VRRP management group state. In other words, VRRP adjusts its priorities and the change in VRRP state based on the result of HRP state switch. When the state of the VRRP backup group changes, the VRRP management group determines whether to change its own state and then determines the states of HRP and the Master or the Backup.
Issue 02 (2007-06-30)
2-17
2.3 Full Proxy of NAT Traversal

2.3.1 Definitions of Signaling Proxy and Media Proxy
Signaling Proxy
A signaling proxy device is essentially a special type of gateway, which divides the call process into the following two parts: Call from a voice/video terminal located in a private network or a Customer Premises Network (CPN) to the proxy Call from the proxy to the call control center on a public network The proxy solves the network address translation (NAT) traversal problem and security problem by relaying calls.
Media Proxy
A media proxy device is essentially the proxy of Real-time Transport Protocol (RTP) or RTP Control Protocol (RTCP) multimedia stream. All the voice/video terminals in a private network or a CPN converge on a media proxy. This media proxy is used to forward the media stream to the called voice/video terminal. The media proxy performs policy management and control over the media stream. The media proxy, thus, solves the problem of the NAT traversal and QoS assurance.
2.3.2 Implementation of Signaling Proxy and Media Proxy on the SE2000

The SE2000 is usually located at the edge or on the convergence layer of an IP network. All the session signaling and media streams converge on the SE2000 and both the signaling proxy and the media proxy take effect on the SE2000. Moreover, it can provide proxy services for multiple Softx3000s. The SE2000 supports the following signaling proxy and media proxy: Resolution and forwarding of SIP signaling packets Resolution and forwarding of MGCP signaling packets Resolution and forwarding of H.248 signaling packets Resolution and forwarding of H.323 signaling packets Resolution and forwarding of iDo signaling packets Resolution and forwarding of U-Path signaling packets Voice/video media stream proxy The SE2000 can support the above functions without need of modifying the existing network topology and configuration.
2.3.3 Basic Workflow

Taking the SE2000 networking at the convergence layer in MANs as an example, this section describes the basic workflow of full proxy (Suppose SIP is adopted). The following three flows are involved:
2-18
Issue 02 (2007-06-30)
User register flow Call flow Media processing flow

As the NGN user considers the SE2000 as a signaling proxy device and a media proxy device, you should configure the Softx3000 address as the client address of the SE2000 on the user terminal or IAD.
Register Flow
Figure 2-11 shows the deployment of the SE2000 at the convergence layer in MANs. The serial numbers register request and register response flows are shown in opposite directions. Figure 2-11 Register flow
SoftX3000 SoftX3000
3 SE2000 2 IP backbone network SE2000
1 (1) Enterprise network 1
NAT/Firewall
NAT/Firewall
Calling side
Called side
1.
A calling user or a called user sends a register request (the source address in the packet header and the address in the payload are the private network address or the port of the terminal). Receiving the register request, the NAT device assigns a public network address or port, translates the source address in the register packet header. The NAT device then forwards the packet to the SE2000. Receiving the register packet, the SE2000 assigns a public network signaling address or port. The SE2000 then translates the addresses both in the packet header and the payload, records the mapping relationship of the addresses. After recording the mapping, the SE2000 initiates a register request to the SoftX3000. The SoftX3000 identifies the user and sends the response packet to the SE2000 if the ID authentication succeeds. After receiving the response packet, the SE2000 modifies the addresses in the packet header and the payload based on the address mapping and then forwards the response packet to the user side. After receiving the response packet, the NAT or firewall device translates the destination address in the packet and forwards the packet to the end user. Thereby, the register flow is complete.
2.
3.
4. 5.
6.
Issue 02 (2007-06-30)
2-19
7.
The SE2000 sends UDP packets to the NAT or firewall device regularly to refresh the NAT entries. In this way, it can maintain the validity of address translation on the NAT or firewall.
Call Flow
Figure 2-12 shows the deployment of the SE2000 at the convergence layer in MANs. The serial numbers call request and call response flows are shown in opposite directions. Figure 2-12 Call flow
SoftX3000 4 3 SE2000 2 IP backbone network 5 SE2000 SoftX3000
1 (1) Enterprise network 1
6 Enterprise network 2 NAT/Firewall NAT/Firewall
1.
A calling user initiates a call. The source address in the packet header, the address in the payload and media receiving address are all private network addresses or ports of the terminal. After receiving the call request from the calling user, the NAT or firewall device on the calling side assigns a public network address or port. The NAT or firewall, then translates the source address in the packet header, and forwards the packet to the SE2000. After receiving the call request packet, the SE2000 on the calling side assigns media receiving address or port and signaling address or port on the extranet for the call. The SE2000 then records the address mapping relationship and forwards the packet to the SoftX3000 after translating the addresses both in the packet header and the payload. After receiving the call request, the SoftX3000 forwards the packet to the SE2000 on the called side. The SE2000 on the called side assigns media receiving address or port and signaling address or port on the intranet for the call and records the address mapping. The SE2000 then forwards the packet after translating the addresses in the packet header and the payload to the NAT device connected with the callee. The NAT or firewall device translates the address in the packet header based on the address mapping and forwards the packet to the called end user. The called terminal sends out the call progress response (it sets its private network address or port as the receiving address for the called media stream). After receiving the response packet through the NAT or firewall, the SE2000 on the called side assigns media receiving address or port on the extranet for the session. It then translates the
2.
3.
4. 5.
6. 7.
2-20
Issue 02 (2007-06-30)
addresses in the packet header and the payload, and forwards the packet to the SoftX3000. 8. The SoftX3000 forwards the packet to the SE2000 on the calling side. After receiving it, the SE2000 assigns media receiving address or port on the intranet for the session. It then translates the addresses in the packet header and the payload, and then forwards the packet to the calling terminal. The called terminal sends out the call success response with similar flow to the call progress response (ACK response from the calling terminal is also omitted here for the same reason).
9.
10. After the call succeeds, media stream begins to interact between the calling and called terminals. Before the interaction begins, the SE2000 media proxy is complete. For details, see Media Processing Flow. 11. After the session is finished, the calling or called side initiates a call termination request. The other side responds to the request through the SE2000. With this, the entire call flow ends.
Media Processing Flow

Figure 2-13 shows the deployment of the SE2000 at the convergence layer in MANs. Media processing flow is shown in Figure 2-13. Figure 2-13 Media processing flow
SoftX3000 SoftX3000
SE2000
IP backbone network
SE2000
(1) Enterprise network 1
Enterprise network 2 NAT/Firewall NAT/Firewall
Calling side
Called side
The SE2000 has sensed the related description about media stream through the processing of the call signaling processing and generates the description on control policy for the media stream (such as RTP address or port translation, bandwidth and flow direction) before transmitting the RTP packet. The SE2000 performs the following functions for the received RTP stream based on the media stream control policy: Security check QoS assurance NAT processing
Issue 02 (2007-06-30)
2-21
It learns the source address after NAT, translates media destination address, and then forwards the media stream.
There is no user register flow in the SE2000 networking because it does not directly interact with users. Other flows are similar to the above description.
2.3.4 Typical Networking Application of the SE2000

For example, there is an organization whose intranet contains multiple IAD devices that support various signaling protocols, OpenEye, U-Path terminals, telephone terminals and video terminals. The intranet is connected with the Internet through a firewall (with NAT function) and a router. To implement the Next Generation Network (NGN) voice/video services on the original network, the ISP only needs to add a SE2000 at the egress of the NAT device instead of modifying the network topology, as shown in Figure 2-14. Figure 2-14 Typical networking application of the SE2000
PC
NAT/ Firewall SoftX3000 Router
Internal network IAD

Telephone
IP backbone network
SE2000
Connecting with the NAT device and the egress router, the SE2000 is transparently added into the original network without need of modifying the network topology. The SE2000 provides the signaling proxy and the media proxy in this NGN application. When the SE2000 is deployed between a terminal device and the SoftX switch, the proxy of the SE2000 is the same regardless of the kind of signaling, such as SIP, MGCP, iDo, U-Path, H.323 or H.248, is processed. The following section introduces the communication process when the SE2000 provides SIP/MGCP/H.323 signaling proxy, as shown in Figure 2-15.
2-22
Issue 02 (2007-06-30)
Figure 2-15 Communication between the SE2000 and Softx3000

IAD
H.323 telephone
Other termial SE2000 SoftX3000 SE2000 OpenEye H.323 telephone
OpenEye
SIP/MGCP/ H.323
SIP/MGCP/ H.323
RTP
RTP
RTP
Signaling Proxy
The SE2000 can be regarded as a Softx3000 system for NGN users because all the register and call messages are first sent to the SE2000. The messages are forwarded to the Softx3000 system (such as the SoftX3000 of Huawei) after signaling processing through the SE2000. The SE2000 can also be regarded as a client of the Softx3000 system because the Softx3000 system first sends the response message to the SE2000. The SE2000 then forwards the message to the end user after signaling processing. The SE2000 can obtain information such as session address change and bandwidth requirements by analyzing and processing the signaling. Based on the session status, it determines whether to allow the media stream to pass through. Thus, it can protect the network and prevent bandwidth embezzlement.
Media Proxy
All the media streams between intranets and extranets are processed and forwarded through the SE2000. The SE2000 first checks the validity of a packet, and then defines a media stream forwarding policy (such as the firewall, QoS and NAT policy) based on the result of signaling processing. Regardless of the networking scheme that is applied, the SE2000 can correctly forward the media stream with the QoS assurance and security control by specifying the destination address and port for the RTP stream of intranet or extranet users.
The common data stream, such as the one related to the intranet PC in Figure 2-14, is directly forwarded through the NAT device to the router. This data stream need not pass through the SE2000.
The SE2000 processes and forwards all the call packets and media streams in the specific direction. It translates the addresses between different networks by re-specifying the destination address and port for the RTP stream of intranet or extranet users. In this way, the NAT traversal is carried out.
Issue 02 (2007-06-30)
2-23
Different from NAT Application Level Gateway (ALG), the SE2000 applies full proxy mode to directionally transmit the media stream instead of translating the IP address in the media stream. Thus, it ensures the system performance and transmission speed of the device.
2.3.5 Classification of Application Modes

Generally, Intranet users access the Internet through the NAT, while home or office users can access the Internet directly. Two application modes involved are as follows: Single domain mode Multi-domain mode
Single Domain Mode

When the SE2000 on the internal network side is not connected with any NAT device, it works in single domain mode. The single domain mode can be used at home or in the office. Figure 2-16 shows the typical networking in single domain mode. Figure 2-16 Typical networking in single domain mode
PC Router IP network IAD Telephone SE2000 IAD IP backbone network SoftX3000
In the single domain mode, you can access the Internet only by connecting the terminal telephones or the IAD devices of video terminals to the SE2000.
Multi-Domain Mode
When the SE2000 on the internal network side is connected with a NAT device or with a NAT device and an IAD simultaneously, it works in the multi-domain mode. The multi-domain mode can be used in the enterprise after translation. Figure 2-17 shows the typical networking in multi-domain mode.
2-24
Issue 02 (2007-06-30)
Figure 2-17 Typical networking in multi-domain mode

PC NAT/Firewall Router Internal network IAD Telephone SE2000 IAD IP backbone network SoftX3000
In the multi-domain mode, the SE2000 should connect with both the NAT device and the egress router. It sends a UDP packet to the NAT device regularly to refresh the NAT entries. Thus, it maintains the address translation relationship.
2.3.6 IP Addresses Related to the SE2000

When the SE2000 operates in the network, the following three important IP addresses are involved: Client Address ServerAddress SoftXAddress The IP addresses related to the SE2000 are shown in Figure 2-18. Figure 2-18 IP addresses related to the SE2000
PC NAT/Firewall Internal network IAD Telephone ClientAddress SE2000 ServerAddress Router IP backbone network SoftXAddress SoftX3000
ClientAddress
The SE2000 connects with the Client (such as NAT or IAD device) through an interface and the address of this interface is called ClientAddress. One or more such interfaces can exist on a SE2000. Signaling and media stream can have different client addresses.
Issue 02 (2007-06-30)
2-25
ServerAddress
The SE2000 connects with the SoftX switch through an interface and the address of this interface is known as ServerAddress. One or more such interfaces can exist. Signaling and media stream can have different server addresses.
SoftXAddress
SoftXAddress is the IP address of the SoftX switch connected with the SE2000. The SE2000 can provide proxy services for multiple Softx3000s.
The Client interface and the Server interface of the SE2000 can be identical or different. If the same physical interface is used, multiple logical sub-interfaces should be configured on this interface. Some of the logical sub-interfaces are used as the Client interfaces while the others are used as the Server interfaces. The ClientAddress and the ServerAddress, therefore, have separate IP addresses even though both use the same physical interface. For the same ClientAddress, it is recommended to set the same ServerAddress for signaling address map and media stream address map.
The SE2000 Client interface receives the register and call messages, which are sent to the SoftX switch through the SE2000 Server interface after signaling processing. The SE2000 Client interface also receives the client RTP media streams, which are sent to the called SE2000 or terminal through the SE2000 Server interface after packet processing. In this way, ClientAddress, ServerAddress and SoftXAddress form the basic interaction path between the user and the NGN system.
2.3.7 Communication Ports Related to the SE2000

As we know, multiple NAT and IAD devices are attached to the SE2000 and multiple voice or video terminals are attached to the IADs. The SE2000 should distinguish the session requests from different users so that each message can be correctly sent back to the terminal. The triplet address mapping of ClientAddress, ServerAddress and SoftXAddress is not suitable here because there are not enough IP addresses for sessions and the expected expansion in the number of users. However, the multi-port mapping makes it possible to send each message to the terminal correctly. It maps various sessions to the same server address but with different port numbers. Therefore, only one ServerAddress is enough. In addition, well-known ports and dynamic ports must be configured on the SE2000, as shown in Figure 2-19.
2-26
Issue 02 (2007-06-30)
Figure 2-19 Ports related to the SE2000

SIP/MGCP/H.323 well-known port NAT/Firewall Router Internal network IAD Telephone SIP/MGCP/H.323 SE2000 SIP/MGCP/H.323 well-known port well-known port IP backbone network
PC
SoftX3000
The SE2000 receives the register and call messages through the Client well-known port. After the signaling processing and selecting a dynamic port of some signaling protocol, it sends the messages to the well-known port of the SoftX switch through the Server dynamic port. Similarly, the SE2000 receives the RTP media stream through the Client well-known port. After the packet processing and selecting a dynamic port of some media stream, the SE2000 sends the media stream to the called SE2000 or terminal through the SE2000 dynamic port.
Client-oriented Well-Known Port on the SE2000

The client-oriented well-known port refers to the well-known port that the SE2000 provides for the client. Client terminals initiate session connections to the SE2000 through these well-known ports.
Softx3000-oriented Dynamic Port on the SE2000

The ports include the port ranges used by: SIP MGCP H.323 iDo U-Path H.248 RTP media stream The port number is automatically assigned by the system. You can specify the port range for such ports.
Well-Known Port on the Softx3000

The well-known port refers to the communications port on the Softx3000, through which the SE2000 initiates session connections to the Softx3000. Ensure that the port information on the SE2000 is identical with that on the Softx3000. As shown in Figure 2-18 and Figure 2-19, a sextuple composes a complete interaction path between the user and the NGN system. Such a sextuple includes ClientAddress, well-known
Issue 02 (2007-06-30)
2-27
port on the SE2000, ServerAddress, dynamic port on the SE2000, SoftXAddress and well-known port on the Softswitch.
Configure the IP address of the call entity on the IAD as the ClientAddress of the SE2000. For the related IAD configuration, refer to "Typical Example for Configuring Signaling Proxy and Media Proxy" in this chapter.
2.3.8 Media Stream Bypass

If the SE2000 serves as the proxy for all media streams, the two problems that may occur are as follows: It demands the SE2000 device for much higher forwarding performances. The more the users, the higher the demand for forwarding performance of the SE2000. The SE2000 serves as the proxy for all media streams, so media streams occupy a lot of network bandwidth especially in video applications. The media stream bypass is required. That is, the media streams are transmitted over IP networks connected with terminals rather than pass the SE2000, as shown in Figure 2-20. Figure 2-20 Typical signaling stream and media stream of the SE2000 media stream bypass process
IP network SE2000
IP network Server
Signaling stream Media stream
2.3.9 User Roaming Restriction

To control the registration of users, you can permit or deny the registration of users on a certain network segment. You can bind the IP address with user information on the SE2000. Based on the binding rules, the SE2000 can determine whether to permit or deny the registration of a user.
2-28
Issue 02 (2007-06-30)
2.4 Address Overlapping

2.4.1 Overview of Address Mapping
With the development of MultiProtocol Label Switching (MPLS) and Virtual Private Network (VPN), the SE2000, which acts as the key equipment enabling the enterprise users to access the NGN, is required to meet new requirements. The IP addresses of users in different VPN or private networks may be the same. The SE2000 as an access device needs to interconnect the VPN or private network and serves as the proxy for terminal users in the VPN or private network. Therefore, the SE2000 should support the address mapping and thus it can serve as the proxy for the terminals with the same IP address. By supporting the address overlapping feature, the SE2000 implements the multi-instance function. Users in the private networks where addresses overlap can access each other without network address translation (NAT). Besides, the address overlapping feature allows the signaling and media streams to traverse the specified VPNs. In this case, the SE2000 acts as a convergent point of multiple networks. It transmits the signaling, media, and management packets to the corresponding networks.
2.4.2 Principle of Address Overlapping

The address mapping feature distinguishes the users whose addresses overlap through isolating interfaces or sub-interfaces into different VPN instances. The IP addresses of users in different VPNs can be the same. Each VPN has its own routing table and ARP entries. An SE2000 can be regarded as multiple virtual devices. The interfaces in different VPNs must be separated by virtual LAN (VLAN). Thus the link layer is separated when the packets are transmitted between the SE2000 and other devices. While receiving the packets, the SE2000 tags VLAN IDs on the packets according to the VPNs to which the interfaces belong. Then the packets are routed and the ARP addressing is performed based on the VPN IDs. The SE2000 supports address overlapping on the terminal side or the server side.
2.4.3 Address Overlapping Processing Flow

As a proxy, the SE2300 can be accessed by the users of multiple VPNs. Each VPN has its own address scheme, and the IP addresses of users in different VPNs may be the same. As shown in Figure 2-21, the SE2000 is connected to a LAN switch. The diagram shows a sample of the SE2000 networking. You can deploy the SE2000 according to the actual networking.
Issue 02 (2007-06-30)
2-29
Figure 2-21 Networking diagram of address overlapping

IADMS SoftX3000
Management VPN
Service VPN
PE
Lanswitch
SE2000 IP backbone network 192.168.216.2/16 192.168.216.1/16 VPN 2
VPN 1
192.168.216.2/16 192.168.216.1/16
Private Network Address Overlapping

The provider edge (PE) tags VLAN IDs, which vary with the VPNs, on the packets and then sends the packets to the SE2000 through the LAN switch. After receiving the register packets sent from the terminal, the SE2000 records the IP address, port number and VLAN ID of the terminal user, by which the SE2000 identifies the terminal. The Softx3000 sends the register response packets to the SE2000. Then, the SE2000 tags VLAN IDs on the packets and forwards the packets to the PE. The PE forwards the packets to the corresponding VPN according to the VLAN IDs, and thus the terminal is registered successfully. The succeeding call flow is similar.
Softx3000 or IADMS Address Overlapping

The IP addresses on the different Softx3000s or Integrated Access Device Management System (IADMS) servers may be the same. The Softx3000s or IADMS servers do not send packets to the SE2000, so the SE200 cannot obtain the VLAN IDs from packets and therefore
2-30
Issue 02 (2007-06-30)
it does not know the VPNs to which the Softx3000 or IADMS server belong. In this case, you should know the VLAN IDs allocated by the PE to the Softx3000 or IADMS server, and then configure the VLAN IDs on the SE2000. Thus the SE2000 tags the VLAN IDs on the register packets sent to the Softx3000 and then forwards the packets to the PE. The PE forwards the packets to the corresponding VPN according to the VLAN IDs. When the SE2000 receives the packets from the Softx3000, the processing flow is similar.
2.5 UDP Tunnel

2.5.1 Overview of the UDP Tunnel
The firewall and the NAT device are usually deployed at the border of the private network and the public network. By default, a session can be actively established from the private network to the public network, but it cannot be done in the reverse direction. Therefore, some NGN terminals cannot properly develop the services because they cannot actively establish sessions. For example, in the H.323 terminal, Q.931 signaling and H.245 signaling employ the TCP protocol, which is directive. Therefore, signaling packets cannot traverse NAT devices from the public network to the private network to establish TCP connections. To solve the problem, the SE2000 supports the UDP tunnel that can traverse the NAT device. First of all, you need to configure the UDP tunnel client in the private network, and meanwhile configure the UDP tunnel server in the public network. Then you need to establish a UDP tunnel between the UDP tunnel client and the UDP tunnel server. In this way, the network topology does not need changing or the terminal does not need configuring afresh. Even if the sending ports of RTP packets are not consistent with the receiving ports, RTP packets can still be transmitted through the UDP tunnel. The SE2000 is a learning-oriented device, which cannot send packets to the receiving port on the terminal in the private network by traversing the NAT device. The voice or video, however, is directive: one direction is "speak"; the other direction is "listen". The SE2000 can learn the IP address of the sending port on the terminal in the private network after NAT translation, but cannot learn the IP address of the receiving port on the terminal in the private network after NAT translation. In the "listen" direction, packets are not sent. Most packets on the application layer can traverse NAT devices through the UDP tunnel. The SE2000 can serve as both the UDP tunnel server and the UDP tunnel client.
2.5.2 Networking Model

The UDP tunnel client is deployed between the terminal and the firewall/NAT device in the private network. The SE2000-1 serves as the UDP tunnel client; the SE200-2 serves as the UDP tunnel server. After the UDP tunnel function is enabled, packets based on all protocols are processed by the UDP tunnel by default. Since a fault occurs when H.323 packets traverse the NAT device, H.323 packets are processed by the UDP tunnel but packets based on other protocols are not processed by the UDP tunnel. Transported based on TCP, Q.931 and H.245 packets are processed by the UDP tunnel by default. (Registration, Admission, Status) RAS is based on UDP. The RAS well-known port number should be configured to the UDP tunnel port number. You can configure two IP addresses for two mapping groups respectively on the downstream interfaces of the SE2000-2. H.323 packets use one of the mapping groups. The networking model of the UDP tunnel is shown in Figure 2-22.
Issue 02 (2007-06-30)
2-31
Figure 2-22 Networking model of the UDP tunnel

Softx3000 NAT/Firewall Internal network Terminal (H.323) IP backbone network
Terminal (SIP)
SE2000-2 UDP Tunnel Server SE2000-1 UDP Tunnel Client UDP tunnel
Signaling Media stream
2.5.3 UDP Tunnel Processing Procedure

If the terminal fails to serve as the UDP tunnel client, another device should be deployed in the network to serve as the UDP tunnel client. The terminal is registered with the UDP tunnel client. For the terminal, the UDP tunnel client serves as the Softx3000; for the UDP client, the UDP tunnel server serves as the Softx3000. The UDP tunnel is established between the UDP tunnel client and the UDP tunnel server. While receiving packets from the terminal, the UDP tunnel client checks whether packets meet the requirements of being processed by the UDP tunnel according to the configuration. If the requirements are met, the UDP tunnel header with the length of 12 bytes is added to packets. The structure of the UDP tunnel header is shown in Figure 2-23. The meaning of the fields of the UDP tunnel header is as follows: Source port (two bytes): for the UDP tunnel client, it indicates the port number bound with the UDP tunnel client; for the UDP tunnel server, it indicates the port number of the UDP tunnel server configured on the UDP tunnel client. Destination port (two bytes): for the UDP tunnel client, it indicates the port number of the UDP tunnel server configured on the UDP tunnel client; for the UDP tunnel server, it indicates the port number bound with the UDP tunnel client. Length of UDP tunnel packet (two bytes): indicates the length of the UDP tunnel packet. It consists of the UDP tunnel packet header and user data. Checksum (two bytes): indicates the Cyclic Redundancy Check (CRC) checksum of the UDP tunnel packet. Type of the UDP tunnel (one byte): indicates the type of the UDP tunnel. The field is not used for the time being, but instead it is reserved for expanding the packet header. Payload protocol (one byte): indicates the protocol that is run to transport the packet without adding the UDP tunnel header. The protocol is TCP or UDP. Tunnel fragment information (two bytes): indicates the fragment information about the tunnel packet.
2-32
Issue 02 (2007-06-30)
Figure 2-23 UDP tunnel header

Destination Length of the Type of UDP UDP tunnel Checksum Source port port tunnel packet packet (2 bytes) (2 bytes) (2 bytes) (1byte) (2 bytes) Payload Tunnel fragment protocol information (1 byte) (2 bytes)
The UDP tunnel packet is generated through inserting a UDP tunnel header between the IP header and TCP/UDP header. After passing through the firewall or the NAT device, the UDP tunnel packet header is changed. The structure of the UDP tunnel packet is shown in Figure 2-24. On receiving a packet, the UDP tunnel server checks whether the packet is a UDP tunnel packet. If so, the UDP tunnel server removes the UDP tunnel header and then sends the packet to the Softx3000. Figure 2-24 UDP tunnel packet structure
Eth header IP header UDP tunnel Original TCP/UDP header (12 bytes) header Data
On receiving a packet returned from the Softx3000, the UDP tunnel server checks whether the packet is a UDP tunnel packet. If so, the UDP tunnel server inserts a UDP tunnel header after the IP header. Thus, a UDP tunnel packet is generated. On receiving a packet returned from the NAT device, the UDP tunnel client checks whether the packet is a UDP tunnel packet. If so, the UDP tunnel client removes the UDP tunnel header and then sends the packet to the terminal.
2.6 Large Capacity

2.6.1 Overview of Large Capacity
As a signaling proxy and media proxy device, the SE2000 is targeted for solving problems in NGN, such as NAT traversal, QoS, and security. Located at the edge of networks, the SE2000 facilitates the access of enterprise users to NGN. For the NGN users, the SE2000 acts as the Softx3000. Currently, to support large capacity networks, the carriers usually deploy multiple SE2000s in the networks. As a result, the carrier must configure multiple server addresses for numbers of terminal users and the workload on maintenance increases tremendously. This hinders the development of new users. To solve the problem, a signaling dispatching device (SDD) is required. The SDD acts as a uniform external interface of a group of SE2000s. All the signaling messages destined for the SE2000s are sent to the SDD first, and then the SDD dispatches the messages to the corresponding SE2000 according to the configured policies. Before dispatching the messages to the SE2000, the SDD checks the capacity of the SE2000. If the capacity is insufficient, the SDD can discard the messages or send the messages to other SE2000s. The SDD can forward the succeeding signaling messages to the same SE2000. The media streams are not sent to the SDD, and instead they are routed to the SE2000s directly. The SE2300 can serve as the SDD by means of software upgrade; the SE2200 cannot serve as the SDD.
Issue 02 (2007-06-30)
2-33

When the large capacity network is established initially, one SE2000-1 is adequate because the user quantity is small. (The capacity of one SE2300 is 50000 users; the capacity of one SE2200 is 10000 users.) As the number of users increases, one SE2000-2 can be added. The carrier configures signaling dispatching policies on the SDD and then dispatches some of the signaling messages to the SE2000-2 according to the policies. The advertised client address is not changed. If the number of users increases continuously, the carrier can add the SE2000-3, the SE2000-4, and so on. The carrier only needs to modify or add policies on the SDD to expand the capacity. The capacity expansion is transparent to users, so the configuration on the terminals is not changed. The SDD can serve as the SBC. When there are not too many users, the SBC function can be enabled on the SDD.
Disabling the SBC Function on the SDD

When the SBC function is disabled on the SDD, the SDD is responsible for only dispatching signaling. The direction of signaling and media stream in the networking is shown in Figure 2-25. Signaling direction (from the UE to the Softx3000): UE NAT Lanswitch1 SDD Lanswitch2 SE2000-1 Lanswitch2 Lanswitch1 Softx3000 Signaling direction from the Softsx3000 to the UE is reverse to the above mentioned direction. Media stream direction (from the UE to the SE2000-1): UE NAT Lanswitch1 Lanswitch2 SE2000-1 Media stream direction from the SE2000-1 to the UE is reverse to the above mentioned direction, but media streams do not pass through the SDD or the Softx3000.
2-34
Issue 02 (2007-06-30)
Figure 2-25 Schematic diagram of signaling and media stream direction when the SBC function is disabled on the SDD
IADMS
Softx3000 SE2000-1
Lanswitch2
Lanswitch1
NAT SDD SE2000-2 User network UE UE
Media stream Signaling
Enabling the SBC Function on the SDD

When the SBC function is enabled on the SDD, the SDD serves as the SBC as well as dispatches signaling. If the SDD is responsible for dispatching signaling only, the direction of signaling and media streams is the same as that shown in Figure 2-25. If the SDD serves as the SBC, the direction of signaling and media streams is shown in Figure 2-26. Signaling direction (from the UE to the Softx3000): UE NAT Lanswitch1 SDD Lanswitch1 Softx3000 Signaling direction from the Softx3000 to the UE is reverse to the above mentioned direction. Media stream direction (from the UE to the SDD): UE NAT Lanswitch1 SDD Media stream direction from the SDD to the UE is reverse to the above mentioned direction, but media streams do not pass through the Softx3000.
Issue 02 (2007-06-30)
2-35
Figure 2-26 Schematic diagram of signaling and media stream direction when the SBC function is enabled on the SDD
IADMS
Softx3000 SE2000-1 SDD
Lanswitch2
Lanswitch1
NAT SE2000-2
Media stream Signaling
User network UE UE
2.6.3 Overview of SDD Dual-System Hot Backup

All the signaling messages are sent to the SDD, so the SDD must be highly reliable. SDD dual-system hot backup is required to reduce the single point failure. The networking diagram of SDD dual-system hot backup is shown in Figure 2-27. The priority of the SDD-1 is higher than that of the SDD-2, so normally the SDD-1 in active state and the SDD-2 is in standby state. All signaling messages are dispatched to the SDD-1. The backup entries added to the SDD dual-system hot backup are the resource status table and the signaling session table. The SDD supports real-time backup. After receiving the register information from the SBC, the SDD-1 updates the information in the resource status table and then backs up the resource status table to the SDD-2. Meanwhile, the SDD-1 backs up the updated signaling session table to the SDD-2 at intervals. The SDD also supports manual and automatic batch backup. Manual batch backup is triggered by the command line; automatic batch backup is automatically triggered when the master/backup switchover occurs. During batch backup, the SDD-1 backs up all entries (the resource status table and the signaling session table) to the SDD-2.
2-36
Issue 02 (2007-06-30)
Figure 2-27 Networking diagram of SDD hot-system hot backup
IADMS
SE2000-1 SDD-1
Softx3000
Lan switch2 SDD-2 SE2000-2 NAT
Lan switch1
User network UE UE
2.7 C-BGF
2.7.1 Overview of C-BGF
The SE2300 supports the C-BGF feature; the SE2200 does not support this feature.
In IMS network, the SE2300 serves as the Core Border Gateway (C-BGF). The SE2300 forwards the SIP signaling packets after NAT to the Proxy-Call Session Control Function (P-CSCF). In this way, SIP signaling implements NAT through the SE2300. The SE2300 interacts with the P-CSCF through the SBCI interface to apply for, modify or release the media resources. Media proxy is thus implemented. The SE2300 interacts with the Session Policy Decision Function (SPDF) through the Ia interface to apply for, modify or release resource reservation, as well as release resources in exceptional cases. QoS control of fixed network terminal access is thus implemented. The SPDF issues QoS orders to the SE2300 and the SE2300 enforces the task. In IMS network, the SE2300 supports precise detect of no media stream. The SE2300 sets the aging time for the RTP session of each user. After both call parties are disconnected, the SE2300 can precisely detect that no media stream passes through. If no media stream passes through within the aging time of the RTP session defined by the SE2300, the SE2300 actively reports the exceptional information about media streams to the P-CSCF through sending the Common Open Policy Service (COPS) message so that the P-CSCF deletes the session related to signaling in time.
Issue 02 (2007-06-30)
2-37
In IMS network, the SE2300 implements COPS master/backup link switchover, real-time backup and batch backup of media proxy and session through dual-system hot backup of the COPS service. When the master SE2300 fails, the backup SE2300 takes over services. Thus, services are not interrupted, and the demand for reliability of the carrier-level device is met.

Serving as the C-BGF, the SE2300 is located between the terminal and the P-CSCF or the SPDF. The SE2300 implements the functions of signaling NAT, media stream and QoS control of fixed network terminal access. The SE2300 interacts with the P-CSCF and the SPDF through COPS. The terminal interacts with the P-CSCF through Session Initiation Protocol (SIP). Media streams do not pass through the P-CSCF or the SPDF. The networking diagram of signaling and media stream in the C-BGF feature is shown in Figure 2-28. Figure 2-28 Networking diagram of signaling and media stream in the C-BGF feature
P-CSCF
SPDF
SE2300
SIP signaling Media stream BRAS BRAS COPS signaling
UE-1
UE-2
2.7.3 Implementation Principle of the C-BGF

Signaling NAT
In IMS network, SIP signaling, which is exchanged between the terminal in the private network and the P-CSCF in the public network, can implement NAT through the SE2300. When the terminal registers, the P-CSCF delivers the signaling NAT mapping update messages through the SBCI interface. The P-CSCF thus requests the SE2300 to update the aging time of the NAT entry as the temporary mapping time of NAT. Meanwhile, the P-CSCF requests the SE2300 to create the Hello entry and send Hello messages regularly. Thus, the NAT entry of SIP signaling of the NAT device or the firewall, which is deployed between the SE2300 and the terminal, can keep alive.
2-38
Issue 02 (2007-06-30)
The SE2300 returns the register address of the terminal in the response message to the P-CSCF. After the terminal registers successfully, the P-CSCF delivers the signaling NAT mapping update message to request the SE2300 to update the aging time of the NAT entry as the reregister time of the terminal. When the terminal deregisters, the P-CSCF delivers the signaling NAT mapping deletion message to the SE2300. The SE2300 then deletes the signaling NAT entry and the Hello entry.
Media Proxy
In IMS network, the SE2300 interacts with the P-CSCF through the SBCI interface and the COPS protocol to create, update, query and release the media mapping. Media proxy is thus implemented. When the user initiates the call request, the P-CSCF delivers the message in request for creating the media mapping to the SE2300. The request message contains the media address and port number of the terminal. After allocating the media address and port number on the access device side ( the media client side of the BGF mapping group) and on the network side (the media server side of the BGF mapping group), the SE2300 notifies the P-CSCF and then the P-CSCF changes the SDP information in the SIP message to the port on the SE2300. When the P-CSCF obtains the media address and port number of the peer, it delivers the request message for updating the media stream to the SE2300. The request message contains the media address and port number of the terminal and the media address and port number of the peer. The SE2300 then updates the media mapping information and creates the temporary session table RTP. When the RTP packets are sent from the terminal to the SE2300, the SE2300 learns the entire session after matching the temporary session entry of RTP based on the destination address, port number and protocol type. Then the SE2300 forwards media streams according to the source address, the source port number, the destination address, the destination port number and the protocol number. During the call, the SE2300 checks whether the session entry exists regularly; the P-CSCF delivers the message in request for querying the media mapping regularly. If the session entry of the SE2300 ages, the aged media mapping information is contained in the response message. When the call ends, the P-CSCF delivers the message for deleting the media mapping to the SE2300. The SE2300 then deletes the media mapping information and the session entry.
QoS Control of Fixed Network Terminal Access

The SE2300 is the sole gate control of user media stream in the fixed network access. In service request, users apply for a small amount of bandwidth and Access Resource Admission Control (ARAC) accepts their QoS bandwidth reservation request. In practice, however, users intend to occupy more bandwidth. The SE2300 can avoid this situation by acting as the gate control. Even if two user terminals are connected with the SE2300 through the same Broadband Remote Access Server (BRAS), media steams between the two user terminals must pass through the SE2300. Thus, media streams are under the control of the SE2300. When users request services, the SE2300 allocates port numbers under the command of the P-CSCF and interacts with the SPDF. On receiving the service request message from the SPDF, the SE2300 searches the call control block (CCB) and the QoS resource status table according to the flow direction of the media stream contained in the request message and IP quintuple or triplet (destination address, destination port number and protocol number). Then the SE2300 judges whether the current resources are adequate. If the resources are adequate, the P-CSCF changes the SDP information in the SIP message to the port number of the SE2300 and enables media streams to pass through the SE2300.
Issue 02 (2007-06-30)
2-39
Through the Ia interface and running the COPS protocol, the SE2300 sends the policy installation success or failure message. If the QoS policy is installed successfully and the status of the gate control is "open", the SE2300 delivers the bandwidth reservation value and updates the QoS resource status table. If the QoS policy is installed unsuccessfully, the SE2300 does not reserve the bandwidth. At the request of QoS control, the SE2300 modifies the reserved resources: Adds media streams. Modifies the bandwidth of some media streams. Modifies the status of media streams. Modifies IP quintuple, that is, the source address the source port number, the destination address, the destination port number and the protocol number. During an offer and answer process, if the current resources in the access network are inadequate, the SE2300 fails to modify the resources, such as increase the bandwidth of media streams or add new media streams. As a result, the SE2300 is still in resource reservation state instead of releasing the reserved resources. When receiving the gate control message from the SPDF, the SE2300 configures the session status to invalid, if the gate control status is "close". The SE2300 configures the session status to valid, if the gate control status is "open"; in this case, the gate control is enabled and media streams can be forwarded. When receiving the message from the SPDF in request for deleting services, the SE2300 sends the QoS policy installation success or failure message to the SPDF. If the QoS policy is installed successfully, the SE2300 releases QoS resources and updates the QoS resource status table; if not, the SE2300 does not release QoS resources.
VLAN Address Overlapping

The IP addresses of users in different VPNs can be the same. Serving as the C-BGF, the SE2300 supports the VLAN address overlapping in IMS. The private networks where IP addresses overlap can be connected with the SE2300. The SE2300 distinguishes users in VPNs or private networks through different VLAN IDs and IP addresses. When the terminal initiates the register request, the P-CSCF delivers the message for updating the signaling NAT mapping through the SBCI interface. The SE2300 then returns the register address of the terminal in the response message. If multiple VLANs exist, the register address of the terminal contains the VLAN ID. After receiving the response packet, the P-CSCF stores the register address and VLAN ID of the terminal. When the terminal initiates the call request, the P-CSCF delivers the message in request for creating the media mapping to the SE2300. The message contains the register address and VLAN ID of the terminal. The SE2300 then matches the mapping group according to ACL rules and allocates the media address and port number according to the terminal address and VLAN ID.
Exception Processing
If the SPDF fails, the SE2300 releases media resources and the P-CSCF releases all signaling resources. All CCB and session entries are deleted and the resource status table is updated. If the P-CSCF fails, the SPDF requests the SE2300 to release resources. Meanwhile, CCB and session entries are deleted and the resource status table is updated.
2-40
Issue 02 (2007-06-30)
If the SE2300 fails and thereby all media streams passing through it are interrupted, the SE2300 sends the service deletion message to the SPDF. Thus, the supported services on the SE2300 are the same as those on the SPDF. The SPDF informs the P-CSCF of releasing the calls related to signaling. Meanwhile, CCB and session entries are deleted and the resource status table is updated.
Issue 02 (2007-06-30)
2-41

SBC Features and Principles

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

SBC Features and Principles

Încărcat de

Drepturi de autor:

Formate disponibile

Quidway SessionEngine2000 Series Feature Description

Huawei Technologies Proprietary

Quidway SessionEngine2000 Series Feature Description

Huawei Technologies Proprietary

Quidway SessionEngine2000 Series Feature Description

Huawei Technologies Proprietary

Quidway SessionEngine2000 Series Feature Description

Huawei Technologies Proprietary

Quidway SessionEngine2000 Series Feature Description

2 Features and Principles

Features and Principles

Huawei Technologies Proprietary

2 Features and Principles

Quidway SessionEngine2000 Series Feature Description

2.1 Attack Defense

2.1.1 Types of Network Attacks

Scanning and Snooping Attack

Defective Packet Attack

Huawei Technologies Proprietary

Quidway SessionEngine2000 Series Feature Description

2 Features and Principles

2.1.2 Typical Network Attacks

Ping of Death Attack and Extra-Large-ICMP Packet Attack

Huawei Technologies Proprietary

2 Features and Principles

Quidway SessionEngine2000 Series Feature Description

SYN Flood Attack

ICMP and UDP Flood Attack

Address/Port Scanning Attack

ICMP Redirect and ICMP Unreachable Packet Attack

Route Record, Source Route and Timestamp Attack

Huawei Technologies Proprietary

Quidway SessionEngine2000 Series Feature Description

2 Features and Principles

IP Fragment Packet Attack

Tracert Packet Attack

2.1.3 Monitor Technologies in Attack Defense

Huawei Technologies Proprietary

2 Features and Principles

Quidway SessionEngine2000 Series Feature Description

2.1.4 Call Admission Control

2.1.5 Session-based CAR

Huawei Technologies Proprietary

Quidway SessionEngine2000 Series Feature Description

2 Features and Principles

2.2 Dual-System Hot Backup

PC Server Internal network 10.100.10.0/24

2.2.2 VRRP Overview

Huawei Technologies Proprietary

2 Features and Principles

Quidway SessionEngine2000 Series Feature Description

Figure 2-2 Networking adopting a VRRP virtual router

PC Server Internal network 10.100.10.0/24

10.100.10.3 Backup RouterB Backup RouterC

Backup group Virtual IP Address 10.100.10.4 10.100.10.1

2.2.3 Disadvantages of Traditional VRRP on the SE2000

Huawei Technologies Proprietary

Quidway SessionEngine2000 Series Feature Description

2 Features and Principles

Typical Networking of SE2000 Backup

State Requirements for SE2000 Backup

Huawei Technologies Proprietary

2 Features and Principles