CX600 Product Description

Product Description
Quidway CX600 Metro Services Platform
HUAWEI TECHNOLOGIES CO., LTD.
Huawei Technologies Co., Ltd. provides customers with comprehensive technical support and service. Please feel free to contact our local office or company headquarters.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base Bantian, Longgang Shenzhen 518129 People's Republic of China Website: Email: http://www.huawei.com support@huawei.com
Copyright Huawei Technologies Co., Ltd. 2009. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd. All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The information in this document is subject to change without notice. Every effort has been made in the preparation of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this document do not constitute the warranty of any kind, express or implied.
Issue 03 (2009-03-10)
Commercial in Confidence
Page 2 of 200
Quidway CX600 Metro Services Platform Product Description
About This Document

Summary
This document describes the product features, hardware architecture, link features, software features, operation and maintenance, network management, networking applications, and technical specifications of the Quidway CX600 Metro Services platform. This document includes: Chapter 1 Product Features 2 System Architecture 3 Hardware Architecture 4 Link Features 5 Primary Service Features 6 Maintenance and Network Management System 7 Networking Applications 8 Technical Specifications Details This chapter introduces the product positioning and features of the CX600. This chapter describes the physical, logical, and software architecture of the CX600. This chapter describes the chassis, fans, power modules, and board types of the CX600. This chapter describes the link features of the CX600. This chapter describes the service features of the CX600. This chapter describes operation and maintenance, and network management of the CX600. This chapter describes the networking applications of the CX600. This chapter describes the technical specifications of the CX600.
Issue 03 (2009-03-10)
Page 3 of 200
Contents
1 Product Features............................................................................................................ 9
1.1 Positioning ................................................................................................................................ 10 1.2 Abundant Services .................................................................................................................... 10 1.3 High-Density LPUs .....................................................................................................................11 1.4 Powerful Forwarding Capacity ................................................................................................... 13 1.5 Perfect QoS Mechanism............................................................................................................ 13 1.6 Excellent Security Design .......................................................................................................... 14 1.7 Good IPv4 and IPv6 Compatibility.............................................................................................. 14 1.8 Compatibility and Extensibility.................................................................................................... 15 1.9 High Reliability .......................................................................................................................... 15
2 System Architecture .................................................................................................... 19

2.1 Physical System Architecture..................................................................................................... 20 2.2 Logical System Architecture....................................................................................................... 21 2.3 Software Architecture ................................................................................................................ 22 2.4 VRPv5 Architecture ................................................................................................................... 23
3 Hardware Architecture ................................................................................................. 25

3.1 Chassis ..................................................................................................................................... 26 3.2 Fans.......................................................................................................................................... 31 3.2.1 Ventilation and Heat Dissipation System............................................................................ 31 3.2.2 Fan Module....................................................................................................................... 32 3.3 Power Modules ......................................................................................................................... 33 3.3.1 DC-Input Power Supply..................................................................................................... 34 3.3.2 AC-Input Power Supply ..................................................................................................... 35 3.4 LCD .......................................................................................................................................... 37 3.4.1 Introduction....................................................................................................................... 37 3.4.2 Appearance ...................................................................................................................... 37 3.5 Board Cage ............................................................................................................................... 38 3.5.1 Board Cage ...................................................................................................................... 38 3.5.2 Board Distribution in the Board Cage ................................................................................ 39 3.6 Boards ...................................................................................................................................... 40 3.6.1 SRU.................................................................................................................................. 40 3.6.2 MPU ................................................................................................................................. 41 3.6.3 SFU .................................................................................................................................. 42 3.6.4 LPU .................................................................................................................................. 42
Issue 03 (2009-03-10)
Page 4 of 200
Quidway CX600 Metro Services Platform Product Description 3.6.5 SPU.................................................................................................................................. 47
4 Link Features................................................................................................................ 49
4.1 Ethernet Link Features .............................................................................................................. 50 4.1.1 Basic Features.................................................................................................................. 50 4.1.2 Ethernet Bundling ............................................................................................................. 50 4.1.3 Virtual Ethernet Interface................................................................................................... 51 4.2 FR Link Features....................................................................................................................... 51 4.3 POS Link Features .................................................................................................................... 52 4.3.1 SDH/SONENT Encapsulation............................................................................................ 52 4.3.2 POS Interfaces ................................................................................................................. 52 4.3.3 POS Sub-interfaces .......................................................................................................... 52 4.3.4 POS Bundling ................................................................................................................... 52 4.4 CPOS Link Features.................................................................................................................. 53 4.4.1 Channelization .................................................................................................................. 53 4.4.2 PPP/HDLC........................................................................................................................ 54 4.5 ATM Link Features..................................................................................................................... 54 4.5.1 SDH/SONENT Encapsulation............................................................................................ 54 4.5.2 PVP/PVC.......................................................................................................................... 54 4.5.3 IPoA ................................................................................................................................. 54 4.5.4 ATM Sub-interfaces........................................................................................................... 55 4.5.5 ATM OAM ......................................................................................................................... 55 4.5.6 1483B ............................................................................................................................... 55 4.5.7 ATM Cell Relay ................................................................................................................. 56 4.6 CE1/CT1/E3/T3/CT3 Link Features ........................................................................................... 57
5 Primary Service Features ............................................................................................ 59

5.1 Ethernet Features...................................................................................................................... 61 5.1.1 Switched Ethernet Features .............................................................................................. 61 5.1.2 Routed Ethernet Features ................................................................................................. 62 5.1.3 Ethernet Clock Synchronization......................................................................................... 62 5.1.4 PBB-TE ............................................................................................................................ 63 5.1.5 QinQ................................................................................................................................. 66 5.1.6 RRPP Link Features ......................................................................................................... 71 5.1.7 RSTP/MSTP ..................................................................................................................... 73 5.1.8 BPDU Tunnel .................................................................................................................... 73 5.2 IP Features................................................................................................................................ 74 5.2.1 IPv4/IPv6 Dual-Protocol Stacks......................................................................................... 74 5.2.2 IPv4 Features ................................................................................................................... 74 5.2.3 IPv6 Features ................................................................................................................... 75 5.2.4 GRE ................................................................................................................................. 75 5.2.5 IPv4/IPv6 Transition Technologies ..................................................................................... 78 5.3 Routing Protocols ...................................................................................................................... 80
Issue 03 (2009-03-10)
Page 5 of 200
Quidway CX600 Metro Services Platform Product Description 5.3.1 Unicast Routing................................................................................................................. 80 5.3.2 Multicast Routing .............................................................................................................. 80 5.4 MPLS Features ......................................................................................................................... 83 5.4.1 Basic Functions................................................................................................................. 83 5.4.2 MPLS TE .......................................................................................................................... 84 5.4.3 MPLS OAM....................................................................................................................... 86 5.5 VPN Features............................................................................................................................ 87 5.5.1 Tunnel Policy .................................................................................................................... 87 5.5.2 VPN Tunnel ...................................................................................................................... 87 5.5.3 MPLS L2VPN.................................................................................................................... 88 5.5.4 BGP/MPLS IP VPN........................................................................................................... 97 5.5.5 L2VPN Accessing L3VPN ............................................................................................... 106 5.5.6 VPN QoS ........................................................................................................................ 108 5.6 IPTN Features.......................................................................................................................... 111 5.7 QoS Features...........................................................................................................................112 5.7.1 DiffServ Model .................................................................................................................113 5.7.2 Traffic Classification .........................................................................................................114 5.7.3 Traffic Policing..................................................................................................................115 5.7.4 Queue Scheduling ...........................................................................................................116 5.7.5 Congestion Management .................................................................................................117 5.7.6 Traffic Shaping.................................................................................................................118 5.7.7 HQoS...............................................................................................................................118 5.7.8 QPPB ..............................................................................................................................118 5.7.9 Ethernet QoS ...................................................................................................................119 5.7.10 ATM QoS ...................................................................................................................... 120 5.7.11 FR QoS......................................................................................................................... 122 5.8 Load Balancing ....................................................................................................................... 123 5.8.1 Equal-Cost Load Balancing ............................................................................................. 124 5.8.2 Unequal-Cost Load Balancing ......................................................................................... 124 5.9 Traffic Statistics ....................................................................................................................... 124 5.9.1 URPF Traffic Statistics..................................................................................................... 124 5.9.2 ACL Traffic Statistics........................................................................................................ 125 5.9.3 CAR Traffic Statistics....................................................................................................... 125 5.9.4 HQoS Traffic Statistics..................................................................................................... 127 5.9.5 Interface-based Traffic Statistics...................................................................................... 127 5.9.6 VPN Traffic Statistics....................................................................................................... 127 5.9.7 TE Tunnel Traffic Statistics .............................................................................................. 127 5.10 IP Compression..................................................................................................................... 127 5.11 MSE Features........................................................................................................................ 129 5.12 Network Security ................................................................................................................... 132 5.12.1 Protocol Security Authentication .................................................................................... 132 5.12.2 RPF/URPF.................................................................................................................... 133
Issue 03 (2009-03-10)
Page 6 of 200
Quidway CX600 Metro Services Platform Product Description 5.12.3 MAC Limit ..................................................................................................................... 133 5.12.4 Unknown Traffic Suppression ........................................................................................ 134 5.12.5 DHCP Snooping............................................................................................................ 134 5.12.6 Local Anti-attack............................................................................................................ 135 5.12.7 GTSM ........................................................................................................................... 137 5.12.8 ARP Attack Defense ...................................................................................................... 138 5.12.9 Mirroring ....................................................................................................................... 139 5.12.10 NetStream................................................................................................................... 142 5.12.11 Lawful Interception ...................................................................................................... 144 5.13 Network Reliability................................................................................................................. 145 5.13.1 Backup of Key Modules................................................................................................. 146 5.13.2 High Reliability of the LPU............................................................................................. 146 5.13.3 Alarm Customized Damping .......................................................................................... 147 5.13.4 Ethernet OAM ............................................................................................................... 147 5.13.5 VRRP ........................................................................................................................... 149 5.13.6 GR................................................................................................................................ 151 5.13.7 BFD .............................................................................................................................. 152 5.13.8 FRR.............................................................................................................................. 153
6 Maintenance and Network Management System .................................................... 157

6.1 Maintenance Features and Functions ...................................................................................... 158 6.1.1 System Configuration Mode ............................................................................................ 158 6.1.2 System Management and Maintenance........................................................................... 158 6.1.3 HGMP............................................................................................................................. 158 6.1.4 System Service and Status Tracking ............................................................................... 158 6.1.5 System Test and Diagnosis ............................................................................................. 159 6.1.6 Upgrade Features ........................................................................................................... 159 6.1.7 Miscellaneous Features .................................................................................................. 160 6.2 Network Management ............................................................................................................. 160 6.2.1 NMS ............................................................................................................................... 160 6.2.2 LLDP .............................................................................................................................. 161
7 Networking Applications ........................................................................................... 162 8 Technical Specifications............................................................................................ 164

8.1 Physical Specifications ............................................................................................................ 165 8.2 System Configuration .............................................................................................................. 166 8.3 Specifications of System Features and Service Performances ................................................. 168 8.3.1 Specifications of System Features................................................................................... 168 8.3.2 Specifications of Service Performances........................................................................... 174
A Compliant Standards................................................................................................. 175

A.1 Standards and Telecom Protocols ........................................................................................... 175 A.2 Electromagnetic Compatibility Standards................................................................................. 192
Issue 03 (2009-03-10)
Page 7 of 200
Quidway CX600 Metro Services Platform Product Description A.3 Safty Standards....................................................................................................................... 192 A.4 Environmental Standards ........................................................................................................ 192 A.5 Other Standards...................................................................................................................... 193
B Acronyms and Abbreviations ................................................................................... 194
Issue 03 (2009-03-10)
Page 8 of 200
1 Product Features
About This Chapter
The following table shows the contents of this chapter. Section 1.1 Positioning 1.2 Abundant Services 1.3 High-Density LPUs 1.4 Powerful Forwarding Capacity 1.5 Perfect QoS Mechanism 1.6 Excellent Security Design 1.7 Good IPv4 and IPv6 Compatibility 1.8 Compatibility and Extensibility 1.9 High Reliability Description This section describes the positioning of the CX600. This section describes services that are supported by the CX600. This section describes the types of LPUs supported by the CX600. This section describes the power forwarding capability of the CX600. This section describes the QoS mechanism on the CX600. This section describes the security design on the CX600. This section describes the IPv4/IPv6 solutions supported by the CX600. This section describes the compatibility and scalability of the CX600. This section describes the reliability of the CX600.
Issue 03 (2009-03-10)
Page 9 of 200
1.1 Positioning
Huawei Quidway CX600 Metro services Platform (MSP) is a high end Ethernet product (hereafter referred to as the CX600). It focuses on carrier-class FMC Ethernet services access, aggregation and transmission in metro area. It mainly locates at metro access and aggregation point. To meet different demands of users, the CX600 provides four types of devices: CX600-16, CX600-8, CX600-4, and CX600-X3. The CX600-16 supports a maximum of 16 LPUs, the CX600-8 supports a maximum of 8 LPUs, the CX600-4 supports a maximum of 4 LPUs, and the CX600-X3 supports a maximum of 3 LPUs. You can choose either CX600-16, CX600-8, CX600-4, or CX600-X3 according to the networking demands. Thanks to its hardware based forwarding mechanism and non-blocking switching technology, CX600 is Developed on the basis of Huawei proprietary Versatile Routing Platform (VRP) and it has carrier class reliability, line speed forward capability, perfect QoS management, abundant services processing and excellent expansibility. With its Ethernet access, level 2 switching and EoMPLS transmission capability, CX600 also supports abundant level IP services. It can provide wide band Internet, Triple Play, IP special line, IP VPN services and etc. CX600 can perfectly co-work with some Huawei products such as CX200/300, NE80E, CX600, ME60 and MA5200G to set up a clearly hierarchical metro Ethernet to multiple services.
1.2 Abundant Services

Based on the VRPv5, the CX600 provides the following abundant service features:
l
Provides IPv4/IPv6 unicast and multicast routing protocols, multicast Call Admission Control (CAC) to ensure carrier-class QoS for multicast, complete MultiProtocol Label Switching (MPLS), MPLS Traffic Engineering (TE), and IP Telecommunication Network (IPTN) solutions. Provides Hot Standby (HSB) of multicast traffic and fast switching. Provides complete Virtual Private Network (VPN) services, such as L2VPN, Virtual Private LAN Service (VPLS), Hierarchy of VPLS (HVPLS), Virtual Leased Line (VLL), L3VPN, multicast VPN services, Huawei patent Hierarchy of VPN (HoVPN) services, and multi-role host services. Provides complete attack defense features, identifies attack packets and traces the source of attack packets, and supports local and remote port mirroring, which improves the reliability of devices. Provides complete Multi Service Edge (MSE) features to manage and control the local access users. Provides access management, login and logout control, accounting, and QoS for DHCP users, static users, Layer 2 dedicated line users, Layer 3 dedicated line users, and Layer 2 VPN users. Provides the Bandwidth on Demand (BOD) service for enterprise users and DHCP users. Provides the web authentication server.
l l
l l
l l
Issue 03 (2009-03-10)
Page 10 of 200

l
Provides rich Layer 2 service features, such as Layer 2 VLAN, selective QinQ, QinQ termination, Provider Backbone Bridging-Traffic Engineering (PBB-TE), Rapid Ring Protection Protocol (RRPP), Spanning Tree Protocol (STP), Rapid Spanning Tree Protocol (RSTP), and Multiple Spanning Tree Protocol (MSTP).
1.3 High-Density LPUs

The CX600 provides Line Processing Units (LPUs) and flexible plug-in cards of various types.
l
LAN and MAN Access interfaces:

Ethernet : 10M/100M/1000M/10G interfaces RPR: 10G RPR/2.5G RPR POS:155M/622M/2.5G/10G CPOS:155M ATM:155M/622M TDM:CE1/CT1/E1/T1/E3/T3/CT3
WAN Access interfaces:

Common interfaces that the CX600 supports Interface Type 10G POS Quantity per Slot 4 Quantity in the System CX600-16:32 CX600-8:16 CX600-4:8 CX600-X3:6 2.5G POS 4 CX600-1664 CX600-832 CX600-416 CX600-X312 622M POS 32 CX600-16:512 CX600-8:256 CX600-4:128 CX600-X3:96 155M POS 32 CX600-16:512 CX600-8:256 CX600-4:128 CX600-X3:96 155M CPOS 8 CX600-16:128 CX600-8:64 CX600-4:32 CX600-X3:24
Issue 03 (2009-03-10)
Page 11 of 200
Interface Type 10GE
Quantity per Slot 4
Quantity in the System CX600-16:32 CX600-8:16 CX600-4:8 CX600-X3:6
GE
24
CX600-16:384 CX600-8:192 CX600-4:96 CX600-X3:72
FE-TX
96
CX600-16:1536 CX600-8:768 CX600-4:384 CX600-X3:288
FE-SFP
24
CX600-16:384 CX600-8:192 CX600-4:96 CX600-X3:72
155M ATM
16
CX600-16:256 CX600-8:128 CX600-4:64 CX600-X3:48
10G RPR
CX600-16:16 CX600-8:8 CX600-4:4
2.5G RPR
CX600-16:64 CX600-8:32 CX600-4:16
622M ATM
CX600-16:128 CX600-8:64 CX600-4:32 CX600-X3:24
CE1/CT1
96
CX600-16:1536 CX600-8:768 CX600-4:384 CX600-X3:288
Issue 03 (2009-03-10)
Page 12 of 200
Interface Type E3/T3/CT3
Quantity per Slot 16
Quantity in the System CX600-16:256 CX600-8:128 CX600-4:64 CX600-X3:48
1.4 Powerful Forwarding Capacity

Designed with the hardware-based forwarding engine, the CX600 carries out full-duplex forwarding of IPv4, IPv6, MPLS, and Layer 2 packets at line speed on all interfaces. The CX600 also supports ACL-based forwarding at line speed. The hardware completes two-level packet replication to forward multicast at line speed:
l l
The Switch and Fabric Unit (SFU) replicates multicast packets to the Line Processing Unit (LPU). The forwarding engine of the LPU replicates the multicast packets to its interfaces.
The LPU supports packet buffer in 200 ms, which ensures that no packets are lost in the case of burst traffic.
1.5 Perfect QoS Mechanism

The CX600 provides the following Quality of Service (QoS) scheduling and buffer mechanisms:
l
Priority Queue (PQ), Weighted Round Robin (WRR), or Weighted Fair Queuing (WFQ) This guarantees fair scheduling and ensures that services of high priority are performed first and are not interfered.
Three-level switching network based on Combined Input and Output Queuing (CIOQ) This prevents head of line blocking. Flow-based scheduling It facilitates MPLS Traffic Engineering (TE) and supports Differentiated Service (DiffServ) and Integrated Service (InterServ). It combines MPLS TE and Diffserv, thus implementing MPLS DS-TE.
Eight priority queues This prevents traffic of high priority from being interrupted. Hardware-based QoS functions This ensures that packets are forwarded at line speed even if QoS is enabled. Five-level Hierarchical QoS (HQoS) scheduling
Issue 03 (2009-03-10)
Page 13 of 200
The perfect QoS mechanism answers the demands of the IP Telephony Network (IPTN). It provides guaranteed delay, jitter, bandwidth, and packet loss ratio of different services. It guarantees the launch of carrier-class services such as Voice over IP (VoIP) and meets the requirements for the development of multi-service IP networks.
1.6 Excellent Security Design

The CX600 takes multiple security measures to protect the data of Internet Service Provider (ISP) networks and end users. The measures can prevent Denial of Service (DoS) attacks, illegal access, and overload of the control plane. The CX600 adopts a distributed structure and guarantees the separation between the data plane and the control plane. It provides a security performance leading in the industry. The CX600 provides the following security features:
l l l
Three user authentication modes: local authentication, RADIUS authentication, and HWTACACS authentication Hardware-based packet filtering and sampling, which guarantees high performance and high extensibility Multiple authentication methods including plain text authentication and Message Digest 5 (MD5) for upper-layer routing protocols such as Open Shortest Path First (OSPF), Intermediate System-to-Intermediate System (IS-IS), Routing Information Protocol (RIP), and Border Gateway Protocol-4 (BGP-4) ACL on the forwarding plane and control plane Anti-attack features, including:

l l
Defends against TCPIP spoofing attacks. Traces sources of attacks. Defends the management and services planes. The CX600 can control management packets and some service packets on the physical interfaces. A physical interface can be specified as the management interface. Supports the application layer cooperation. If a protocol is enabled, the protocol packets are sent to the CPU for processing. If a protocol is disabled, the protocol packets are discarded or sent to the CPU at a limited bandwidth.
Lawful interception or Unicast Reverse Path Forwarding (URPF) URPF checks the source IP address of the received packets and then discards the illegal packets.
l l
DHCP snooping and limit on MAC addresses Generalized TTL Security Mechanism (GTSM)
Multi-Service Edge (MSE) that provides dynamic user access, authentication, and accounting, and HQoS
1.7 Good IPv4 and IPv6 Compatibility

The CX600 fully supports the Internet Protocol version 4 (IPv4) and IP version 6 (IPv6) dual stack. It can provide all IPv6 features, and offers a good solution to the smooth transition from IPv4 networks to IPv6 networks.
Issue 03 (2009-03-10)
Page 14 of 200

l l
Supports various IPv6 over IPv4 tunnels and IPv4 over IPv6 tunnels. Supports the routing table and the forwarding table with large capacities. This enables the CX600 to serve as the VPN Provider Edge (PE) and supports future expansion of services. Supports the distributed forwarding of IPv4/IPv6 and Multiprotocol Label Switching (MPLS). Supports IPv4/IPv6 dynamic unicast and multicast routing protocols.
l l
1.8 Compatibility and Extensibility

The CX600 has good compatibility and strong extensibility. It supports smooth expansion. The CX600 features the following:
l l l
The backplane of the CX600 has a large capacity, which reserves enough bandwidth for future expansion. The CX600 forwards services through the flexibly programmable Network Processor (NP). Thus, you can install software to carry new services. The Traffic Manager (TM) and Packet Forwarding Engine (PFE) are separate. The two PFEs, Application Specific Integrated Circuit (ASIC) and NP, are flexibly supported to meet the requirements of different applications.
1.9 High Reliability

Based on the carrier-class design, the chassis of the CX600 supports the hot swap of boards. The chassis can be installed in an N68E-22/N68E-18 cabinet or a standard 19-inch cabinet. The CX600 provides a powerful monitoring system. The CX600 manages and maintains the entire system by using the Switch and Route Processing Unit (SRU) or .the Main Processing Unit (MPU). The SRU/MPU manages, monitors, and maintains the boards, fans, and power modules. The CX600 complies with Electro Magnetic Compatibility (EMC). The modular design of the system carries out EMC isolation between boards. The CX600 fully meets the requirements for the high reliability of carrier-class and high-end routers. The CX600 provides the features described in Table 1-1 to ensure high reliability. Table 1-1 Reliability features Item System protection mechanism Description The boards, power modules, and fans are hot swappable. The SRU/MPUs run in 1:1 backup mode. The Switch Fabric Units (SFUs) on the CX600-16, CX600-8 and CX600-4 run in 3+1 load balancing and backup mode.
Issue 03 (2009-03-10)
Page 15 of 200
Item
Description The power modules, AC-input or DC-input, work in 1+1 backup mode. The power modules provide three power input routes and adopt the switched-mode power supply (SMPS). The key components such as the clocks and management buses work in backup mode. Protections against abnormalities The system restarts automatically when abnormalities occur and recovers the work. The system resets a board when abnormalities occur on the board and recovers the work. The system automatically restores the interface configuration. The system provides protections against over-current and over-voltage for power modules and interfaces. The system provides protection against mis-insertion of boards. Power alarm monitoring Voltage and environment temperature monitoring The system provides alarm prompt, alarm indication, running status query, and alarm status query. The system provides alarm prompt, alarm indication, running status query, and alarm status query.
Reliability design
The system adopts distributed hardware-based forwarding. The control channel is separated from the service channel to provide a non-blocking control channel. The system provides fault detection for the system and boards, indicators, and the NMS alarm function.
Reliable upgrade
The system supports in-service patching. The system supports version rollback. The system supports in-service upgrading of the BootROM. The backplane bus supports 8BCP check. The system supports the Error Checking and Correction (ECC) Random Access Memory (RAM).
Fault tolerance design
Data backup
The system supports hot backup of the data between the active and standby units. When the active unit fails, the standby unit automatically takes over the active unit for data transmission. This ensures that no data is lost. The system supports the synchronization between the SRU/MPUs and LPUs.
Synchronization configuration
Issue 03 (2009-03-10)
Page 16 of 200
Item
Description The system can automatically select and boot correct applications. The system supports the automatic upgrade and restoration of the BootROM program. The system can back up configuration files to the remote File Transfer Protocol (FTP) server. The system can automatically select and run correct configuration files. The system provides abnormality monitoring for the system software, automatic restoration, and log record.
Operation security
The system provides password protection for system operations. The system provides hierarchical protection for commands through the configuration of login user classes and command levels. The system can lock the terminal through commands to prevent illegal use. The system provides operation and confirmation prompts for some commands that may degrade the system performance.
Operation and maintenance center
The system adopts the generic integrated Network Management System platform developed by Huawei.
Issue 03 (2009-03-10)
Page 17 of 200
2 System Architecture
About This Chapter
The following table shows the contents of this chapter. Section 2.1 Physical System Architecture 2.2 Logical System Architecture 2.3 Software Architecture 2.4 VRPv5 Architecture Description This section describes the physical architecture of the CX600. This section describes the logical architecture of the CX600. This section describes the software architecture of the CX600. This section describes the VRPv5 architecture.
Issue 03 (2009-03-10)
Page 19 of 200
2.1 Physical System Architecture

Figure 2-1 shows the CX600 physical architecture with the DC-input power modules that includes the following systems:
l l l l
Power distribution system Functional host system Heat dissipation system Network management system
Figure 2-1 Physical architecture

-48 V -48 V RTN Integrated chassis -48 V RTN -48 V RTN -48 V -48 V
Power distribution system
Functional host system
Monitorbus
Fan heat dissipation system
Ethernet Network management subsystem
RTN indicates Return.
Except the network management system (NMS), all other systems are in the integrated cabinet. Both the power distribution system is in 1+1 backup mode. The following introduces only the functional host system. The functional host system processes data. In addition, it monitors and manages the whole system, such as the power distribution system, the fan heat dissipation system, and the NMS through NMS interfaces. Figure 2-2 shows the functional host system of the CX600.
Issue 03 (2009-03-10)
Page 20 of 200
Figure 2-2 Functional host system

Monitoring bus Management bus (1) System backplane Monitoring bus Management bus (1) Monitoring bus Management bus
Monitoring unit Management unit POS/Ethernet Physical interface unit LPU Forwarding unit
Monitoring bus Management bus
System monitoring unit Management bus switching unit MPU MPU (Active)
Serial link group
System monitoring unit Management bus switching unit MPU MPU (Slave)
Monitoring unit Management unit POS/Ethernet Physical interface unit LPU Forwarding unit
Monitoring bus Management bus
Switching network monitoring unit Switching network control unit Switching network
Serial link group
Serial link group SFU module
(1): The link connects to management bus switching unit of another MPU
2.2 Logical System Architecture

As shown in Figure 2-3, the CX600 is logically divided into:
l l l
Data plane Control and management plane Monitoring plane
Issue 03 (2009-03-10)
Page 21 of 200
Figure 2-3 Logical architecture

LPU Monitoring unit System monitoring unit MPU LPU Monitoring unit
Monitoring plane
Monitoring unit
Monitoring unit
Control & management plane
Management unit
Management
System control unit

Switching network
unit
Management unit
Management
unit
control unit
Data plane
Forwarding unit
Switching network SFU
Forwarding unit Forwarding unit LPU
Forwarding unit LPU
The data plane is responsible for high speed processing and non-blocking switching of data packets. It encapsulates or decapsulates packets, forwards IPv4/IPv6/MPLS packets, performs QoS and scheduling, completes inner high-speed switching, and collects statistics. The control and management plane is the core of the entire system. It controls and manages the system. The control and management unit processes protocols and signals, configures and maintains the system status, reports and controls the system status. The monitoring plane monitors the system environment. It detects the voltage, controls power-on and power-off of the system, monitors the temperature and controls the fan. In this way, the security and stability of the system are ensured. It can isolate the fault promptly in the case of a unit failure to guarantee the operation of the other parts.
2.3 Software Architecture

Figure 2-4 shows the software architecture of the CX600.
Issue 03 (2009-03-10)
Page 22 of 200
Figure 2-4 Software architecture

Fan monitoring
Power monitoring
RPS SNMP Active
RPS Standby
IPC
FSU
FSU
FSU
EFU LPU
EFU LPU
EFU LPU
In terms of the software, the CX600 consists of the Routing Process System (RPS), power monitoring module, fan monitoring module, LCD control module, Forwarding Support Unit (FSU), and Express Forwarding Unit (EFU).
l
The RPS is the control and management module that runs on the SRU/MPU. The RPSs of the active SRU/MPU and the standby SRU/MPU back up each other. They support IPv4/IPv6, MPLS, LDP, and routing protocols, calculate routes, set up LSPs and multicast distribution trees, generate unicast, multicast, and MPLS forwarding tables, and deliver routing information to the LPU. The FSU implements the functions of the link layer and IP protocol stacks on an interface. The EFU performs hardware-based IPv4/IPv6 forwarding, multicast forwarding, MPLS forwarding, and statistics.
l l
2.4 VRPv5 Architecture

The VRPv5 consists of the following parts: system service plane, versatile control plane, data forwarding plane, service control plane, and system management plane.
l
System service plane It provides such functions as task and memory management, timer, software loading and patching based on the operating system. It enhances the modular technology to facilitate system upgrade and customization.
Versatile control plane
Issue 03 (2009-03-10)
Page 23 of 200
It is the core of the VRP data communication platform. It supports link management, IPv4/v6 protocol stack, and routing protocol processing, MPLS, MPLS VPN, and MPLS TE. It serves as the basis of security and QoS. It is used to control the data forwarding plane and carry out various functions of the device.
l
Data forwarding plane It forwards data under the control of the versatile control plane to carry out data transmission. The VRPv5 supports data forwarding based on software and hardware. The data forwarding plane is the task executor of the CX600.
Service control plane It controls and manages the system as required, including authentication, authorization, and accounting.
System management plane It manages user interfaces and input/output interfaces. It is the basis of the network management and maintenance.
The VRPv5 has the following characteristics:

l l l l l
The system structure adopts the modular design. The components can be upgraded independently, without affecting the running of other components. The system is easy to maintain and supports smooth service expansion. In-service patching offers flexible methods of enhancing service features and correcting defects. Network reliability is thus guaranteed. The system supports the hardware-based structure. Various modules run on different Central Processing Units (CPUs). The security and reliability are thus ensured.
Issue 03 (2009-03-10)
Page 24 of 200
3 Hardware Architecture
About This Chapter
The following table lists the contents of this chapter. Section 3.1 Chassis 3.2 Fans 3.3 Power Modules 3.4 LCD 3.5 Board Cage 3.6 Boards Describes This section describes the chassis of the CX600. This section describes the fans of the CX600. This section describes the power supplies of the CX600. This section describes the board cage of the CX600. This section describes the boards of the CX600. This section describes the chassis of the CX600.
Issue 03 (2009-03-10)
Page 25 of 200
3.1 Chassis
The CX600 consists of the components: integrated chassis, including the backplane; power modules; ventilation and heat dissipation system and board cage.
l
The chassis of the CX600-16 is 36 U high with the dimensions of 442 mm x 669 mm x 1600 mm (width x depth x height). The CX600-16 can be mounted in a standard 19-inch cabinet or an N68E-22 cabinet. Figure 3-1 shows the appearance of the CX600-16. The chassis of the CX600-8 is 20 U high with the dimensions of 442 mm x 669 mm x 886.2 mm (width x depth x height). The CX600-8 can be mounted in a standard 19-inch cabinet or an N68E-22/N68E-18 cabinet. Figure 3-2 shows the appearance of the CX600-8. The chassis of the CX600-4 is 10 U high with the dimensions of 442 mm x 669 mm x 442 mm (width x depth x height). The CX600-4 can be mounted in a standard 19-inch cabinet or an N68E-22/N68E-18 cabinet. Figure 3-3 shows the appearance of the CX600-4. The dimensions of the CX600-X3 vary with the types of power modules.
The CX600-X3 with DC power modules is 4 U high and the dimensions are 442 mm x 650 mm x 175 mm (width x depth x height). The CX600-X3 can be mounted in a standard 19-inch cabinet or an N68E-22 cabinet. Figure 3-4 shows the appearance of the CX600-X3. The CX600-X3 with AC power modules is 5 U high and the dimensions are 442 mm x 650 mm x 220 mm (width x depth x height). The CX600-X3 can be mounted in a standard 19-inch cabinet or an N68-22E cabinet. Figure 3-4 and Figure 3-5 show the appearance of the CX600-X3.
Issue 03 (2009-03-10)
Page 26 of 200
Figure 3-1 Appearance of the CX600-16

1
2 10
9 5
8 7
1. LCD 4. Board cage 8. Power module
2. Fan module 6. Air intake frame 9. Rack-mounting ear
3, 5. Cabling trough 7. Plastic panel of the power module 10. Handle
Issue 03 (2009-03-10)
Page 27 of 200
1. Panel of the fan frame 6. Power module
2. Fan frame 7. Handle
3. Board cage 8. Rack-mounting ear
4. Air intake frame 9. Cabling trough
5. Plastic panel of the power module
Issue 03 (2009-03-10)
Page 28 of 200
1. Air intake frame 5. Fan module
2. Mouting ear 6. MPU
3. LPU 7.Fan module
4. Power supply module 8. Air filter
Issue 03 (2009-03-10)
Page 29 of 200
Figure 3-4 Appearance of the CX600-X3 (DC power modules)
3. LPU 7.Fan module
Issue 03 (2009-03-10)
Page 30 of 200
Figure 3-5 Appearance of the CX600-X3 (AC power modules)
3. LPU 7.Fan module
3.2 Fans
3.2.1 Ventilation and Heat Dissipation System
Ventilation and heat dissipation are performed from bottom up on the board cage of the CX600-16 and CX600-8. Ventilation and heat dissipation are performed from left to right on the board cages of the CX600-4. Ventilation and heat dissipation are performed from left to back on the board cages of the CX600-X3.
l l l
The fans integrated on the power module are located at the bottom of the chassis. The air channels of the power module and the board cage are separated from each other. The air flows from the front of the power module to the back for ventilation and heat dissipation.
Issue 03 (2009-03-10)
Page 31 of 200
3.2.2 Fan Module

The CX600-16 has two fan modules, in either of which there are two centrifugal fans; the CX600-8 has one fan module, in which there are nine fans; the CX600-4 has one fan module, in which there are six fans; the CX600-X3 has one fan module, in which there are ten fans.
l l
The fan module helps in the air ventilation and heat dissipation of the boards. The main Monitorbus module on the SRU/MPU can control the speed of the fans based on the temperature in the board cage.
Figure 3-6, Figure 3-8, and Figure 3-9 show the appearances of the CX600-16, CX600-8, CX600-4 and CX600-X3 fan modules respectively. Figure 3-6 Appearance of the CX600-16 fan module
Figure 3-7 Appearance of the CX600-8 fan module
Issue 03 (2009-03-10)
Page 32 of 200
Figure 3-8 Appearance of the CX600-4 fan module
Figure 3-9 Appearance of the CX600-X3 fan module
3.3 Power Modules

The maximum power consumption of the CX600-16, CX600-8, CX600-4, and CX600-X3 is 4700 W, 2200 W, 1400 W, and 900 W respectively. The CX600 provides two types of power supply:
l l
DC-input power supply AC-input power supply
Issue 03 (2009-03-10)
Page 33 of 200
3.3.1 DC-Input Power Supply

The DC power module of the CX600-16 supports 1+1 backup of the power. The power module behind the plastic panel inputs DC power and distributes the power. The power module inputs three channels of the power and adopts the switched-mode power supply (SMPS). Each of the power modules inputs three channels of the 48 V DC power at the same time. The three channels of the DC power supply power for different modules. The DC power modules of the CX600-8, CX600-4 and CX600-X3 work in 1+1 backup mode. The power module behind the plastic panel inputs DC power and distributes the power. The48 V DC power module of CX600-16, CX600-8 and CX600-4 is designed with the 3 U high structure. Figure 3-11 and Figure 3-11 show the appearance of the DC power module on CX600-16, CX600-8 and CX600-4. Figure 3-10 Appearance of the DC power module on CX600-16
Figure 3-11 Appearance of the DC power module on CX600-8 and CX600-4
Issue 03 (2009-03-10)
Page 34 of 200
The48 V DC power module of CX600-X3 is designed with the 1 U high structure. Figure 3-12 shows the appearance of the DC power module. Figure 3-12 Appearance of the DC power module on CX600-X3
The 48 V DC power module outputs:

l l
Primary straight-through power Secondary 48 V DC regulated voltage
The DC power module provides protections against the following:

l l l l
Short circuit Over-current Over-voltage Short circuit
It also supports the alarm function.
3.3.2 AC-Input Power Supply

The AC power modules of the CX600 work in 1+1 backup mode. The power module behind the plastic panel inputs AC power and distributes the power. The AC power module of CX600-16, CX600-8 and CX600-4 is designed with the 3 U high structure. Figure 3-13 and Figure 3-14 show the appearance of the AC power module on CX600-16, CX600-8 and CX600-4.
Issue 03 (2009-03-10)
Page 35 of 200
Figure 3-13 Appearance of the AC power module on CX600-16
Figure 3-14 Appearance of the AC power module on CX600-8 and CX600-4
The AC power module of CX600-X3 is designed with the 1 U high structure. Figure 3-15 shows the appearance of the AC power module on CX600-X3. Figure 3-15 Appearance of the AC power module on CX600-X3
The AC power module provides protections against the following:

l l
Output over-current Output over-voltage
Issue 03 (2009-03-10)
Page 36 of 200

l l l l l
Output under-voltage Input over-voltage Input under-voltage Over-temperature Short circuit
It also supports the alarm function.
3.4 LCD
The CX600-16 has LCD.
3.4.1 Introduction
The LCD is used to display the information and status of the board, environment, fan module, and power module. LCD supports two display modes:
l l
Idle mode: the default mode. It is used to display the normal status of the system. Menu query mode: It can support 3-class menus at most.
3.4.2 Appearance
Figure 3-16 shows the appearance of the LCD. Figure 3-16 Appearance of the LCD
1. FAN1 indicator
2. FAN2 indicator
3. Push buttons
4. Liquid crystal display
Issue 03 (2009-03-10)
Page 37 of 200
3.5 Board Cage

3.5.1 Board Cage
The CX600-16 has two board cages, each of which has 11 slots. The slots can hold 16 LPUs or NetStream SPUs, 4 SFUs, and 2 MPUs. Figure 3-17 is the schematic diagram. Figure 3-17 Board cage of the CX600-16
1 2 3 4 17 18 5 6 7 8 9
L L L L M M L L L L L P P P P P P P P P P P U U U U U U U U U U U
L L L L S S S S L L L P P P P F F F F P P P U U U U U U U U U U U
1 0 11 12 13 19 20 21 22 14 15 16
The CX600-8 has one board cage, which has 12 slots. The slots can hold 8 LPUs, 2 SFUs (sharing one slot), and 2 SRUs. Figure 3-18 is the schematic diagram. Figure 3-18 Board cage of the CX600-8
1 2 3 4 9 11 10 5 6 7 8 S F L L L L S U S L L L L P P P P R R P P P P U U U U U S U U U U U F U 1 2 3 4 9 1210 5 6 7 8
The CX600-4 has one board cage, which has 8 slots. The slots can hold 4 LPUs, 2 SFUs (sharing one slot), and 2 SRUs.
Issue 03 (2009-03-10)
Page 38 of 200
Figure 3-19 is the schematic diagram. Figure 3-19 Board cage of the CX600-4
SRU SFU SRU LPU LPU LPU LPU SFU 6 7 8 5 4 3 2 1
The CX600-X3 has one board cage, which has 5 slots. The slots can hold 3 LPUs and 2 MPUs. Figure 3-20 is the schematic diagram. Figure 3-20 Board cage of the CX600-X3
MPU LPU LPU LPU MPU 45 3 2 1
3.5.2 Board Distribution in the Board Cage

Table 3-1 Board distribution of the CX600-16 Slot Number 116 17 and 18 1922 Quantity 16 2 4 Slot Width 41 mm (1.6 inch) 30 mm (1.3 inch) 36 mm (1.4 inch) Remark LPUs MPUs in 1:1 hot backup SFUs in 3+1 hot backup
Table 3-2 Board distribution of the CX600-8 Slot Number 18 9 and 10 Quantity 8 2 Slot Width 41 mm (1.6 inch) 36 mm (1.4 inch) Remark LPUs SRUs
Issue 03 (2009-03-10)
Page 39 of 200
Slot Number 11 and 12
Quantity 2
Slot Width 36 mm (1.4 inch)
Remark SFUs in 3+1 backup
Table 3-3 Board distribution of the CX600-4 Slot Number 14 5 and 6 7 and 8 Quantity 4 2 2 Slot Width 41 mm (1.6 inch) 36 mm (1.4 inch) 36 mm (1.4 inch) Remark LPUs SRUs SFUs in 3+1 backup
Table 3-4 Board distribution of the CX600-X3 Slot Number 13 4 and 5 Quantity 3 2 Slot Width 41 mm (1.6 inch) 36 mm (1.4 inch) Remark LPUs MPUs in 1:1 hot backup
3.6 Boards
The CX600-8 and CX600-4 support SRU.
3.6.1 SRU
The Switch and Route Processing Unit (SRU) is an integrated unit of multiple functional modules. The SRU provides the functions as described below by integrating such units as the system control and management unit, the switching unit, the system clock source, and the maintenance and management unit. The functions and hardware implementation of each module is independent.
Core Unit for System Control and Management

l l
Carrying out routing protocols: The SRU is used for packet broadcast, packet filtering, and download of routing policies from the policy server. Managing and communicating the boards: The LAN switch module integrated on the SRU can carry out the outer band communications among boards. Through the outer band management bus, it can manage the LPU, the SFU and the standby SRU, and implement their communications. Configuring data: The SRU carries out system data configuration and startup files, charging, software upgrade and running logs storage. The CF card on the SRU panel is used to store logs of the system and is hot swappable. The CF card inside the SRU is used to store system files and is not hot swappable.
Issue 03 (2009-03-10)
Page 40 of 200

l
Managing and maintaining the system: The management interfaces (serial or network interfaces) on the SRU carry out management and maintenance of the system
Part of the SFU

The two SFUs and two switching units on the SRU constitute four forwarding planes that work in 3+1 load balancing mode. The SRU, functioning as the synchronization clock unit, ensures clock synchronization between the SFUs and LPUs.
System Clock Unit

The SRU/MPU provides LPUs with reliable synchronous SDH interface clock signals. It can provide the downstream devices with 2.048 MHz synchronous clock signals, and can receive 2.048 MHz or 2.048 Mbit/s external reference clock signals. The SRU supports IEEE 1588v2.
System Maintenance Unit

The SRU periodically collects the running data of system units through the Monitorbus, and generates control information based on the running state. For example, the SRU periodically detects whether each board is in position and adjusts the rotating speed of the fan module. In addition, the SRU can perform local or remote test or online upgrade of system units through the JTAG bus.
The main control module, clock module, and LAN switch module work in 1+1 hot backup mode, and thus improving the reliability of the system.
3.6.2 MPU
The CX600-16 and CX600-X3 support MPU.
The MPU integrates multiple functional modules such as the clock module, LAN switch module, and Compact Flash (CF) module. As the system clock source and the management and maintenance unit, the MPU runs as the core of system control and management. It provides the functions of the control plane and the maintenance plane. The MPU supports the clock board defined in IEEE 1588v2. The MPU controls and manages the system. It is designed in 1:1 backup mode. The MPU is composed of the main control unit, the system monitoring unit, the management bus switching unit, and the clock unit.
l
The main control unit processes network protocols and manages the whole system. The main control unit of each MPU is connected with the management bus switching unit of both the master and the slave MPUs. It controls and manages all the functional units such as MPUs, SFUs, and LPUs. The main control unit also communicates with the system monitoring unit. The system monitoring unit reports the status and environment information about the monitoring plane to the management control plane. And then the management control plane sends control signals to the monitoring plane.
Issue 03 (2009-03-10)
Page 41 of 200

l
The system monitoring unit collects the system monitoring information and interacts with the main control unit. In addition, it monitors the status and environment of its MPU. It communicates with the monitoring units in the system or other boards or subsystems through the Monitorbus.
The management bus switching unit carries out the switching of the management bus. It connects to the control units of two MPUs, all LPUs, and SFUs. Thus, there are two sets of management buses in the system to perform the master/slave backup protection no matter which Main_Control_Board is in master mode.
3.6.3 SFU
As the switching network unit of the CX600-16, CX600-8 and CX600-4, the SFU switches data for the entire system. On the CX600-16, the four SFUs operate in 3+1 load balancing and backup mode. They share data processing. The whole system can thus support line-rate switching of 640 Gbit/s Gbit/s traffic. On the CX600-8 and CX600-4, the two SFUs and the two switching units on the SRU work in 3+1 load balancing mode. The entire system can thus switch the traffic at wire speed of 640 Gbit/s. There is a control channel on the SFU to provide the following functions:
l l
Detecting voltage, current, and temperature. Providing protections against over-voltage, over-current, and over-heat.
3.6.4 LPU
The CX600 provides multiple types of physical interfaces, including GE, POS, CPOS, ATM, and RPR, and CE1/CT1/E3/T3/CE3/CT3 interfaces. These interfaces can interconnect various network devices as required.
Function
The LPU consists of the Physical Interface Card (PIC), LPU module, and Fabric Adaptor (FAD). These components work together to implement fast processing and forwarding of the service data, and the maintenance and management of the link protocol and service forwarding table. The main functions of each module are described in Table 3-5. Table 3-5 Functions of each module on the LPU Module Name LPU module Function
l
Processes and encapsulates link layer protocols such as Ethernet_II and Point-to-Point Protocol (PPP). Classifies data packets to monitor traffic and filters packets based on ACLs. Manages and schedules data cache. Forwards data based on the forwarding table. Identifies control protocol packets and forwards packets to the active CPU through the non-line-rate interface.
l l l
Issue 03 (2009-03-10)
Page 42 of 200
Module Name FAD module
Function
l
Traffic management. According to traffic classification, the FAD carries out queuing, buffer, and scheduling based on the traffic congestion on the SFU. Adaptation of the interface on the SFU. It supports the switching from the SDH physical interface (SPI4.2) to the high-speed serial interface on the SFU. A part of the SFU. The FAD controls traffic according to the queuing status to ensure that no data is lost in the SFU.
PIC
Performs the function of physical interfaces including electrical/optical conversion and physical layer processing.
The CX600 provides Common LPUs and flexible cards. CX600-X3 only provides motherboard LPUF-10, motherboard LPUF-21 and their flexible cards.
Fixed Interface LPUs
Only CX600-16, CX600-8 and CX600-4 provide the fixed interface LPUs.
l
Ethernet LPU Table 3-6 lists the Ethernet LPUs supported by the CX600.
Table 3-6 Ethernet LPUs LPU Name 1-port 10G Ethernet optical interface LAN LPU (XFP optical module) 1-port 10G Ethernet optical interface WAN LPU (XFP optical module) 24-port 10M/100M/1000M Ethernet electrical interface LPU 24-port 100M/1000M LPU (SFP optical module) 5/10-port Gigabit Ethernet optical interface LPU (SFP optical module) Remarks
The Small Form-Factor Pluggable (SFP) and 10-Gigabit Small Form-Factor Pluggable transceiver (XFP) are pluggable optical modules.
The 10G Ethernet optical interface LPUs can be classified into WAN LPUs and LAN LPUs. The differences between the WAN LPUs and LAN LPUs are as follows:
WAN LPUs need to encapsulate Ethernet frames in SDH/SONET frames before transmitting them over optical fibers. Interfaces on a WAN LPU can be connected to interfaces on other WAN LPUs or connected to SDH/SONET transmission devices. WAN LPUs are mainly used for the Ethernet WAN interconnection.
Issue 03 (2009-03-10)
Page 43 of 200
LAN LPUs implement electro-optic conversions in transmitting Ethernet frames over optical fibers. Interfaces on a LAN LPU, however, can be connected to only the interfaces on other LAN LPUs. LAN LPUs are mainly used for the Ethernet LAN interconnection. The packets sent by interfaces on WAN LPUs or LAN LPUs can be transmitted through Dense Wavelength Division Multiplexing (DWDM) lines.
POS LPU POS LPUs are used to connect the CX600 with SDH transmission devices or other devices. Table 3-7 lists the POS LPUs provided by the CX600.
Table 3-7 POS LPUs LPU Name 1-port OC-192c/STM-64c POS optical interface LPU (XFP optical module) 1/2/4-port OC-48c/STM-16c POS optical interface LPU (SFP optical module) 4-port OC-12c/STM-4c POS optical interface LPU (SFP optical module) 4/8-port OC-3c/STM-1 POS optical interface LPU (SFP optical module) Remarks
RPR optical interface LPU The RPR optical interface LPU can realize the access function of the RPR ring network, and provides efficient and reliable RPR networking solutions.
Table 3-8 RPR LPUs LPU Name 1-port OC-192c/STM-64c RPR Interface LPU (XFP optical module) 2/4-port OC-48c/STM-16c RPR Interface LPU (SFP optical module) Remark
Flexible Plug-in Cards

The CX600 provides flexible plug-in cards, which enhances networking flexibility and provides low-cost and customized solutions as required. In this manner, the needs of mid-range-and-low-end users can be satisfied. The flexible plug-in motherboard (hereinafter referred to as motherboard) works with the flexible plug-in card to provide the flexible plug-in feature; thus, the hardware configuration is flexible. The CX600 supports two types of motherboards and their flexible plug-in cards.
l
Motherboard LPUF-10 and its flexible plug-in cards The LPUF-10 provides four slots, in which four half-height flexible plug-in cards and two full-height flexible plug-in cards (requiring two slots) can be inserted. The LPUF-10 supports a maximum of 10 Gbit/s bandwidth.
Issue 03 (2009-03-10)
Page 44 of 200
The flexible plug-in cards supported by the LPUF-10 are hot swappable. They support automatic configuration restoration and card intermixing. Table 3-9 Flexible plug-in cards supported by the LPUF-10 Flexible Plug-in Card Name 1-port OC-192c/STM-64c POS-XFP Flexible Card 1/2/4-port OC-48c/STM-16c POS-SFP Flexible Card 8-port 100/1000Base-X-SFP Flexible Card Remarks It is a full-height card. It is a half-height card. It is a half-height card. The card supports Ethernet clock synchronization. In addition, ports 0 or 1 support synchronization of sending and receiving clock signals simultaneously; other ports support only synchronization of sending clock signals. It is a half-height card. It is a half-height card. It is a half-height card. It is a half-height card. It is a half-height card. It is a half-height card. It is a half-height card.
2-port OC-12c/STM-4c ATM-SFP Flexible Card 4-port OC-3c/STM-1c ATM-SFP Flexible Card 4/8-port OC-12c/STM-4c POS-SFP Flexible Card 4/8-port OC-3c/STM-1c POS-SFP Flexible Card 2-port OC-3c/STM-1c CPOS-SFP Flexible Card 24-port CE1/CT1-100DB Flexible Card 4-port E3/CT3-SMB Flexible Card
Motherboard LPUF-21 and its flexible plug-in cards The motherboard LPUF-21 provides two slots, each of which can hold a flexible plug-in card of the LPUF-21. The LPUF-21 supports a maximum of 20 Gbit/s bandwidth. The motherboard LPUF-21 has two models: LPUF-21-A and LPUF-21-B.

The LPUF-21-A provides all the software features of the CX600. The LPUF-21-B provides all the software features of the CX600, except L3VPN, Multicast VPN (MVPN), and IPv6, but LPUF-21B can be upgraded through licenses to support such features..
Table 3-10 lists the flexible plug-in cards supported by the LPUF-21.
Issue 03 (2009-03-10)
Page 45 of 200
Table 3-10 Flexible plug-in cards supported by the LPUF-21 Flexible Plug-in Card Name 1-port 10GBase WAN/LAN-XFP Flexible Card Remarks It is a full-height card. You can configure the interface to run in LAN or WAN mode through commands. The interface supports the synchronization Ethernet of sending and receiving clock signals. 12-port 100/1000Base-SFP Optical Interface Flexible Card It is a full-height card. The card supports Ethernet clock synchronization. In addition, ports 0 or 1 support the synchronization of sending and receiving clock signals; other ports support only the synchronization of sending clock signals. It is a full-height card. The card supports Ethernet clock synchronization and IEEE 1588v2. It is a full-height card. Occupy two sub-slots Occupy two sub-slots Occupy two sub-slots It is a full-height card. It is a full-height card.
12-port 100/1000Base-SFP Optical Interface Flexible Card A
12-port 10/100/1000Base-RJ45 Electrical Interface Flexible Card 40-Port 100/1000Base-SFP Flexible Card 40-Port 10/100/1000Base-RJ45 Flexible Card 4-Port 10GBase WAN/LAN-XFP Flexible Card 1-port OC-192c/STM-64c POS-XFP Flexible Card 48-port 10/100Base-TX-Delander Flexible Card
Table 3-11 Flexible plug-in cards supported by the LPUF-40 Flexible Plug-in Card Name 2-port 10GBase WAN/LAN-XFP Flexible Card Remarks It is a full-height card. You can configure the interface to run in LAN or WAN mode through commands. The interface supports the synchronization Ethernet of sending and receiving clock signals.
Issue 03 (2009-03-10)
Page 46 of 200
Flexible Plug-in Card Name 20-port 100/1000Base-SFP Optical Interface Flexible Card
Remarks It is a full-height card. The card supports Ethernet clock synchronization. In addition, ports 0 or 1 support the synchronization of sending and receiving clock signals; other ports support only the synchronization of sending clock signals.
3.6.5 SPU
The SPU provides no interfaces and performs only integrated processing for specific services. The CX600 provides multiple SPUs for load balancing. The SPU provides the following functions:
l
Integrated NetStream: The system samples packets on the LPU, and collects the traffic statistics on the SPU. In this manner, the processing performance is high, without affecting the forwarding capability. When initiating integrated NetStream on the SPU, the system must be configured with a NetStream license. Integrated MVPN: When proving the integrated MVPN, the system must be configured with a certain number of SPUs. The number of SPUs is determined by the requirements of the MVPN performance. In addition, the system must be configured with a MVPN License for SPU according to the number of SPUs. Integrated tunnel: includes the functions of lawful interception, GRE tunnels, and IPv6 Provider Edge (6PE) tunnels. When starting the integrated tunnel on the SPU, the system must be configured with the tunnel licenses the number of which equals that of the SPUs. For example, if the system is mounted with three SPUs, three tunnel licenses must be configured to enable the integrated tunnel.
Issue 03 (2009-03-10)
Page 47 of 200
4 Link Features
About This Chapter
The following table shows the contents of this chapter. Section 4.1 Ethernet Link Features 4.2 FR Link Features 4.3 POS Link Features 4.4 CPOS Link Features 4.5 ATM Link Features 4.6 CE1/CT1/E3/T3/CT3 Link Features Description This section describes the features supported by Ethernet links. This section describes the features supported by FR links. This section describes the features supported by POS links. This section describes the features supported by CPOS links. This section describes the features supported by ATM links. This section describes the features supported by CE1/CT1/E3/T3/CE3/CT3 links.
Issue 03 (2009-03-10)
Page 49 of 200
4.1 Ethernet Link Features

4.1.1 Basic Features
The Ethernet link provided by the CX600 features the following:
l l l l l l l
VLAN trunk VLANIF interfaces VLAN aggregation. Inter-VLAN interface isolation Ethernet sub-interfaces Super-VLAN sub-interfaces Ethernet clock synchronization
4.1.2 Ethernet Bundling

Ethernet bundling is a technology that bundles multiple physical Ethernet interfaces into a logical interface (Eth-Trunk) to increase bandwidth. Eth-Trunks of the CX600 function as follows:
l l l
Supports the bundling of up to 16 physical Ethernet interfaces. Eth-Trunks function the same as normal Ethernet interfaces. Supports the bundling of interfaces with different rates. Supports active/standby mode and performs active/standby switching automatically in accordance with the link status of interfaces.
The CX600 supports the adding or deleting of member interfaces to or from an Eth-Trunk. The CX600 can also sense the Up or Down state of member interfaces, thus dynamically modifying the bandwidth of the Eth-Trunk.
Layer 2 Ethernet Bundling

When running the portswitch command on an Eth-Trunk, you can switch the Eth-Trunk to the Layer 2 mode. The Eth-Trunk then provides the following features of the switched Ethernet link:
l l l l l l l
VLANIF interfaces Inter-VLAN interface isolation VLAN aggregation VLAN trunk VLAN mapping QinQ and VLAN stacking Layer 2 features such as MSTP and RRPP
Layer 3 Ethernet Bundling

By default, an Eth-Trunk is a Layer 3 Ethernet bundling interface. The Eth-Trunk then provides the following features of the routed Ethernet link:
Issue 03 (2009-03-10)
Page 50 of 200

l l l l l
IPv4/IPv6 forwarding MPLS forwarding Multicast forwarding L3VPN L2VPN
The Layer 3 Eth-Trunk can support the creation of subinterfaces. Each Layer 3 Eth-Trunk can support a maximum of 4000 subinterfaces.
LACP (802.3ad)
The CX600 supports link aggregation in Link Aggregation Control Protocol (LACP) static mode. Link aggregation in static LACP mode is in contrast with port bundling in manual mode. Port bundling in manual mode requires neither LACP nor exchange of protocol packets. The ISP alone decides the binding of ports. Link aggregation in LACP static mode resorts to LACP and automatically maintains the port status by exchanging protocol packets. The ISP, however, needs to set up the aggregation group and add member links. LACP cannot change the configuration information. The CX600 supports LACP that conforms to IEEE 802.3ad. Administrators can create an Eth-Trunk, add member ports to the Eth-Trunk, and enable LACP on the Eth-Trunk. The CX600 negotiates with the peer device to determine the interfaces for data forwarding by exchanging LACP protocol packets. That is, they negotiate to determine whether the outbound interfaces are in the selected or standby state. LACP maintains the link status based on the port status. LACP adjusts or disables link aggregation in the case of the aggregation changes.
4.1.3 Virtual Ethernet Interface

The CX600 supports virtual Ethernet (VE) interfaces. By mapping the ATM PVC to the manually-created VE interfaces, Ethernet packets can be transmitted over the ATM Adaptation Layer (AAL5). The VE interfaces thus provide Layer 2 switched and Layer 3 IP services.
4.2 FR Link Features

Frame Relay (FR) is a fast packet switching technology used to forward and switch data in a simple manner on the link layer. FR carries out only functions of the physical layer and data link layer in the Open Systems Interconnection (OSI) reference model. Flow control and error correction are implemented by the intelligent terminal. This shortens the period of packet processing, increases the network throughput, and reduces the delay of transmission. FR uses virtual circuits (VCs) to make full use of network resources. Therefore, FR features large throughput and short delay. It is applicable to burst services. The CX600 provides the following FR features:
l l l
Data Link Control Identifier (DLCI) VC: Permanent Virtual Circuit (PVC) and Switching Virtual Circuit (SVC) FR address mapping
Issue 03 (2009-03-10)
Page 51 of 200

l l l l l
FR Local Management Interface (LMI) FR sub-interfaces FR switch PVC backup FR compression Multilink Frame Relay (MFR)
4.3 POS Link Features

4.3.1 SDH/SONENT Encapsulation
The physical layer of the Packet Over SDH/SONET (POS) link adopts Synchronous Optical Network (SONET) defined by the American National Standards Institute (ANSI) or Synchronous Digital Hierarchy (SDH) defined by the International Telecommunication Union-Telecommunication Standardization Sector (ITU-T). POS interfaces provide alarms for the physical layer.
4.3.2 POS Interfaces

The CX600 provides POS interfaces at a rate of 155 Mbit/s, 622 Mbit/s, 2.5 Gbit/s, or 10 Gbit/s. POS interfaces support the following protocols on the data link layer:
l l l
Point-to-Point Protocol (PPP) High-level Data Link Control (HDLC) FR
PPP on POS interfaces supports the following:

l l l l l l
Link Control Protocol (LCP) Internet Protocol Control Protocol (IPCP) Multi-Protocol Label Switching Control Protocol (MPLSCP) Multilink Protocol (MP) Password Authentication Protocol (PAP) Challenge Handshake Authentication Protocol (CHAP)
4.3.3 POS Sub-interfaces

On the CX600, you can manually create POS sub-interfaces to provide multiple logical links over a POS link. Then, you need to configure FR on the link layer of POS sub-interfaces to interwork with the network-layer devices that support POS FR or with FR switches that support POS interfaces. POS sub-interfaces support point-to-point (P2P) and point-to-multipoint (P2MP).
4.3.4 POS Bundling

When HDLC is adopted on the link layer of POS interfaces, you can bundle multiple POS interfaces into a logical interface, that is, an IP-Trunk. You can configure IP-Trunks to implement routing protocols and carry MPLS and VPN services. The physical POS interfaces that are bundled into an IP-Trunk are called member interfaces. All configurations on an IP-Trunk also take effect on the member interfaces. The member interfaces use the IP address of the IP-Trunk.
Issue 03 (2009-03-10)
Page 52 of 200
IP bundling features the following:

l l l
Increased bandwidth: The bandwidth of an IP-Trunk is the total bandwidth of all member interfaces. Improved reliability: When a link fails, traffic is automatically switched to other links. This ensures the reliability of the connection. Load balancing: Load balancing is implemented between different flows. Flows with different source and destination IP addresses are carried over different links. The same flow is carried over a same link.
Figure 4-1 IP trunk
Trunk
The CX600 supports:

l l l l
Inter-board IP trunk IP trunk of channels with different rates Dynamic establishment and removing of IP-trunk interfaces Binding a physical channel to a trunk through the command line on a physical interface
4.4 CPOS Link Features

In a network, a great number of access devices are connected to the upstream convergence devices through the low-speed E1/T1 interfaces. In this case, the convergence devices need to possess the capability of converging a large amount of low-speed E1/T1 or POS interfaces. The CPOS interfaces of various rates supported on the CX600 can answer the preceding requirements.
4.4.1 Channelization
A CPOS interface is a channelized POS interface. In channelization, multiple independent channels of data are transmitted over an optical fiber by using low speed tributary STM-N signals. During the transmission, each channel has its own bandwidth, start and end points, and follows its own monitoring policy. Channelization can make full use of bandwidth in transmitting multiple channels of low speed signals. The channelization granularity of CPOS interfaces is as follows:
l l
A 155-Mbit/s CPOS interface can be channalized into 63 E1 channels, 84 T1 channels, or 1023 N x 64K channels. A 155-Mbit/s CPOS interface can be channelized into 3 E3/T3 channels.
The CX600 supports the bundling of E1/T1 channels. Up to 84 channels can be bundled into a channel-set. A 155-Mbit/s CPOS interface supports up to 168 channel-sets.
Issue 03 (2009-03-10)
Page 53 of 200
4.4.2 PPP/HDLC
The CX600 provides CPOS interfaces at a rate of 155 Mbit/s. On the link layer, CPOS supports the following protocols:
l l
PPP HDLC
PPP on CPOS interfaces supports the following:

l l l l l l
LCP IPCP MPLSCP MP PAP CHAP
4.5 ATM Link Features

4.5.1 SDH/SONENT Encapsulation
ATM interfaces on the CX600 support SONET/SDH encapsulation and the SONET/SDH overhead configuration and physical layer alarms.
4.5.2 PVP/PVC
ATM interfaces support PVP/PVC in the following aspects:
l l l l l l l l l l
VP/VC-based traffic shaping User-to-Network Interface (UNI) signaling RFC 1483: Multiprotocol Encapsulation over ATM Adaptation Layer 5 RFC 1577: Classical IP and ARP over ATM F4 or F5 End to End Loopback OAM AAL5 Nonreal-time Variable Bit Rate (nrt_VBR) Unspecified Bit Rate (UBR) Real-time Variable Bit Rate (rt_VBR) Constant Bit Rate (CBR)
4.5.3 IPoA
IP over ATM (IPoA) is a technology that bears IP services over the ATM network. It inherits the fundamentals of TCP/IP and regards the ATM network as a physical subnet. For IP protocols, the ATM network is equivalent to the physical subnet such as the Ethernet. With IPoA applied, users can directly run IP-based network protocols and applications on the ATM network. The CX600 supports the following modes in setting up the mapping between PVCs and the IP address of the peer device:
Issue 03 (2009-03-10)
Page 54 of 200

l l
Static mapping Inverse Address Resolution Protocol (InARP)
4.5.4 ATM Sub-interfaces

The CX600 supports ATM sub-interfaces. ATM interfaces support multiple virtual connections of which the peer networks are in different network segments. In this manner, ATM sub-interfaces should be created so that the CX600 can communicate with different peers. Multiple PVCs can be created on an ATM sub-interface.
4.5.5 ATM OAM

ATM OAM provides a mechanism to detect and locate faults, and verify network performance without interrupting services. OAM provides the network with specific information by inserting OAM cells with the standard structure into user cell flows. The CX600 supports the F4 and F5 OAM. OAM functions to detect the Up and Down status of PVP or PVC links.
4.5.6 1483B
RFC 1483 defines the technological standards of transmitting multi-protocol data units over the ATM network. The standards are as follows:
l
1484 Bridged It is applied to the bridged Protocol Data Units (PDUs). 1483 Routed It is applied to the routed PDUs.
It imitates the bridge function of the Ethernet network, so that the terminal devices on the user side and the bridge devices on the network side are connected. Figure 4-2 shows the stack protocol of 1483B.
Issue 03 (2009-03-10)
Page 55 of 200
Figure 4-2 Stack protocol of 1483B

TCP/UDP IP Ethernet 1483B TCP/UDP IP Ethernet AAL5 ATM
Access router
CX-A ATM network
The IPoE Ethernet protocol stack is applied to a device on the user side. After 1483B is configured on the ingress Router A on the ATM network, Router A can encapsulate Ethernet packets into ATM cells, so that the received IPoE packets can be transmitted transparently on the ATM network. IP over Ethernet over ATM (IPoEoA) is the main application of 1483B supported by the CX600. IPoEoA indicates that AAL5 bears Ethernet packets and Ethernet bears IP packets. In this manner, the layer 2 forwarding of IPoEoA packets is implemented between the Ethernet and PVC. IPoEoA converges the ATM backbone network and the IP network. IPoEoA supports various Ethernet and IP services.
4.5.7 ATM Cell Relay

The objective of PWE3 is to connect the traditional network resources such as ATM, FR, and Local Area Network (LAN) through a PSN, and emulates the traditional services over the PSN. The emulation of the original services to the utmost on the PSN keeps the end user from feeling differences. In this manner, it protects the settled investment of users and operators in the network consolidation and establishment. The Layer 2 emulation service on a PSN passes through the public or private PSN by setting up P2P tunnels and bearing data packets, cells, and bits flow. PWE3 tries to emulate the original services between the two PEs that are connected through a PW. Figure 4-3 shows the encapsulation type of the label for ATM transparent cell transport through a PSN.
Issue 03 (2009-03-10)
Page 56 of 200
Figure 4-3 Network diagram for ATM encapsulation over a PSN

ATM Encapsulation over PSN PSN Transport Header Pseudo-wire Header MPLS PSN tunnel identified by outer label ATM Control Word ATM Service Payload ATM Service MPLS Network PSN Tunnel L2 Network PE Pseudo-wire PE ATM Service L2 Network Pseudo-wire identified by inner label
Outer MPLS Label Inner MPLS Label
The outer PSN label identifies the PSN tunnel, while the inner label, namely, PW Header identifies a PW. In ATM cell transport, the following two kinds of services are transmitted on the PSN:
l l
The services whose PW payload is ATM cells The services whose PW payload is AAL5 SDU/PDU
ATM cell transport can help transfer the earlier ATM or ISP network through the PSN network without adding new ATM devices and changing the ATM CE configurations. ATM CE routers consider the ATM cell transport service as the TDM leased line. The CX600 support ATM cell transport over Permanent Virtual Circuit (PVC) and Permanent Virtual Path (PVP). Generally, the CX600 support the following ATM cell transport modes:
l l l l l l
ATM whole port cell transport 1-to-1 VCC cell transport N-to-1 VCC cell transport 1-to-1 VPC cell transport N-to-1 VPC cell transport ATM AAL5-SDU VCC transport
4.6 CE1/CT1/E3/T3/CT3 Link Features

The CX600 provides CE1, CT1, E3, T3, and CT3 interfaces. Serial interfaces are channelized from CE1/CT1/E3/T3/CT3 interfaces and support the following link protocols:
Issue 03 (2009-03-10)
Page 57 of 200

l l l
PPP HDLC FR supported on CE1/CT1 interfaces
PPP on serial interfaces supports the following:

l l l l l l
LCP IPCP MPLSCP MP PAP CHAP
Issue 03 (2009-03-10)
Page 58 of 200
5 Primary Service Features

About This Chapter
The following table shows the contents of this chapter. Section 5.1 Ethernet Features 5.2 IP Features 5.3 Routing Protocols 5.4 MPLS Features 5.5 VPN Features 5.6 IPTN Features 5.7 QoS Features 5.8 Load Balancing 5.9 Traffic Statistics 5.10 IP Compression 5.11 MSE Features 5.12 Network Security 5.13 Network Reliability Description This section describes the Ethernet features supported by the CX600. This section describes the IP features supported by the CX600. This section describes the routing protocols supported by the CX600. This section describes the MPLS features supported by the CX600. This section describes the VPN features supported by the CX600. This section describes the IPTN features supported by the CX600. This section describes the QoS features supported by the CX600. This section describes the load balancing features supported by the CX600. This section describes the traffic statistics features supported by the CX600. This section describes the IP compression features supported by the CX600. This section describes the MSE features supported by the CX600. This section describes the security features supported by the CX600. This section describes the high reliability features supported by the CX600.
Issue 03 (2009-03-10)
Page 59 of 200
Issue 03 (2009-03-10)
Page 60 of 200
5.1 Ethernet Features

5.1.1 Switched Ethernet Features
The Ethernet interfaces on the CX600 can run as switched interfaces to provide VLAN, VPLS, and QoS services. They can also run on the User Network Interface (UNI) side to support MPLS VPN.
VLAN Trunk
A trunk is a P2P link between two routers. The interfaces on the connected routers are called trunk interfaces. One VLAN trunk can transmit data flows from different VLANs and allow the VLANs to contain the interfaces of many routers. The CX600 can dynamically add, delete, or modify the VLANs of a VLAN trunk to maintain the consistency of VLAN configurations in the entire network. The CX600 can also work with non-Huawei devices for interworking.
VLANIF Interfaces
The CX600 supports VLANIF interfaces. You can assign IP addresses to VLANIF interfaces and bind VLANIF interfaces to VPNs. This implements the Layer 3 access of VLANIF interfaces. You can also bind VSIs to VLANIF interfaces to implement the VPLS access.
VLAN Aggregation
Inter-VLAN routing is involved in the communication between VLANs. If each VLANIF interface is assigned an IP address, IP address resources will be used up. You can aggregate a group of VLANs to a super-VLAN. The VLANs in the super-VLAN are called branch VLANs. A super VLAN is associated with an interface at the IP layer. In addition, all branch VLANs in the super-VLAN use IP addresses in the same network segment to improve the utilization of IP addresses.
Interface Isolation in a VLAN

You can configure an interface in a VLAN as an isolated interface. Layer 2 forwarding is prohibited between isolated interfaces. Layer 2 forwarding, however, is allowed between an isolated interface and a non-isolated interface in a VLAN. On the CX600, you can add the interfaces that need to be isolated in a VLAN to different interface groups. Any two interfaces of different interface groups are isolated from each other. The interfaces outside the groups are not isolated.
Ethernet Sub-interfaces
The CX600 supports the configuration of sub-interfaces for a switched Ethernet interface. You can configure Layer 3 services on the sub-interfaces and Layer 2 services on the main interface. In this manner, the switched Ethernet interfaces can support both Layer 2 and Layer 3 services.
Issue 03 (2009-03-10)
Page 61 of 200
5.1.2 Routed Ethernet Features

The Ethernet interfaces on the CX600 can run as routed interfaces to provide IPv4/IPv6, MPLS, QoS, and multicast services. Routed Ethernet interfaces can be configured with sub-interfaces. The sub-interfaces support VLAN encapsulation used to terminate a VLAN.
Ethernet Sub-interfaces
A common Ethernet sub-interface, which can belong to a VLAN only, functions as follows:
l l l
Terminates enterprise services. Supports complete routing protocols. Supports MPLS forwarding.
Super-VLAN Sub-interfaces
A super-VLAN sub-interface, which can belong to multiple VLANs, functions to terminate the individual users' services. It supports the following features to ensure security:
l l l l
DHCP relay DHCP binding URPF ACLs
5.1.3 Ethernet Clock Synchronization

Clock synchronization is a technique that limits the difference in terms of clock frequency or phase between the network elements (NEs) in digital networks within a certain range. If the clock frequency deviation and phase deviation exceed the allowed error range, error codes and jitter may occur. This degrades the transmission performance. The LPUF-10 and LPUF-21 on the CX600 provide Ethernet clock synchronization. The clock quality and stratum can thus be guaranteed.
Issue 03 (2009-03-10)
Page 62 of 200
Figure 5-1 Ethernet clock synchronization

MSCSERVER NC RNC IP Node B Iu-PS Iur IP SS7/TDM IP SS7/IP HLR SCP MGW Iu-CS Mc IP Mc PSTN MSCSERVER
Nb MGW
PS IP Node B RNC Iu-PS SGSN IP Gi GGSN

t I n ter e rne
In a wireless network, Ethernet links have high requirements for clocks. As shown in Figure 5-1, in the future IP-RAN solution, the IP network runs as the bearer layer between Node B and the RNC. With Ethernet clock synchronization, clock transmission in the IP network can be guaranteed. In addition, Ethernet clock synchronization supports the backup of the clock reference source to enhance the reliability of links. When an Ethernet link becomes Down, the system automatically selects the backup Ethernet interface to extract clock information.
5.1.4 PBB-TE
Provider Backbone Bridging-Traffic Engineering (PBB-TE) is a connection-oriented Ethernet technology that combines the features of telecom networks. Through PBB-TE, MANs adopt the Ethernet technology to transmit Ethernet services. PBB-TE is based on Provider Backbone Bridge (PBB) defined in IEEE 802.1ah, that is, the MAC-in-MAC technology. In compliance with IEEE 802.1ah, the CX600 supports the MAC-in-MAC technology. P2P and MP2MP transmission of services can be carried out based on the architecture of Ethernet. This implements the Ethernet technology in the MAN, even the WAN from the access layer, convergence layer, to the core layer. MAC-in-MAC is a tunneling technique based on MAC stacking. In MAC-in-MAC, the MAC address of an ISP is encapsulated outside the MAC address of a user Ethernet frame. Then, the user Ethernet frame is transparently transmitted across the public network. Deployed between two MANs, the MAC-in-MAC tunnel functions over the backbone network of the ISP. For the ISP network, the MAC address of a user is isolated, which enhances the security of services. In addition, double MAC addresses are applied, which expands the space of MAC addresses.
Issue 03 (2009-03-10)
Page 63 of 200
The MAC-in-MAC tunnel can be set up between the CX600s. It supports fault detection, fault location, and Automatic Protection Switching (APS). APS controls the protection switching of tunnels. The CX600 supports 1+1 and 1:1 protection for the MAC-in-MAC tunnels. The CX600 also supports the revertive mode, hold-off time, and APS configuration mismatch test. This guarantees the fast recovery of services. Figure 5-2 Leased line service PBB-TE
Bridge nodes are configured with static forwarding entries
In the P2P application, end nodes ignore the user DA
PBB-TE UPE CE Metro(+Core) CE
Figure 5-3 Convergence service PBB-TE

Bridge nodes are configured with static forwarding entries
PBB-TE Metro CE NPE
Core
Issue 03 (2009-03-10)
Page 64 of 200
Figure 5-4 Leased line service PBB-TE trunk

PBB-TE Trunk UPE CE Metro(+Core) CE
Figure 5-5 Convergence service PBB-TE trunk

PBB-TE Trunk NPE CE Metro
Core
Issue 03 (2009-03-10)
Page 65 of 200
Figure 5-6 Multipoint-to-multipoint PBB-TE
CE
PE
Metro(+Core) CE
PE CE PE
PE
CE
5.1.5 QinQ
The QinQ protocol is a Layer 2 tunneling protocol based on the IEEE 802.1Q technology. The QinQ technology expands the VLAN space by adding a new tag to a packet that is already tagged through IEEE 802.1Q. The private VLAN packets are thus transparently transmitted across the ISP network. This functions the same as a Layer 2 VPN. The packets transmitted in the public network carry double 802.1Q tags, one for the public network and the other for the private network. This is called 802.1Q-in-802.1Q, or QinQ for short. The ISP network only provides one VLAN ID for different VLANs from the same user network. This saves VLAN IDs of an ISP. Meanwhile, QinQ provides a Layer 2 VPN solution that is easy to implement for LANs or small-scale MANs. The QinQ technology can be applied to multiple services in Metro Ethernet solutions. QinQ features the following:
l l l
Packets from different users in the same VLAN are not transmitted transparently. Private networks are separated from the public network. The ISP's VLAN IDs are saved to the maximum.
Without being a formal protocol, QinQ is widely applied among carriers because it is easy to implement. The introduction to selective QinQ (VLAN stacking) makes QinQ more popular among carriers. With the development of the Metro Ethernet, all device vendors have put forward their Metro Ethernet solutions. The QinQ technology plays an important role in the solutions because of its simplicity and flexibility.
Issue 03 (2009-03-10)
Page 66 of 200
The CX600 provides rich QinQ features, which satisfies diverse networking requirements.
Interface-based QinQ
Figure 5-7 shows the networking diagram of applying interface-based QinQ. A user configures interface-based QinQ on the router. When the user's packets, carrying the user's VLAN tag, arrive at the router, the router takes the user's packets as untagged packets and adds a VLAN tag of the ISP outside the existing VLAN tag. The user's packets then go through the VLAN tunnel of the ISP and reach the remote user. The VLAN tag of the ISP is stripped from the packets. Figure 5-7 Typical networking diagram of the interface-based QinQ application
VLAN100
100
100
300 ISP Network
200
200
300
VLAN200
Interface-based QinQ provides the following functions:

l l
Access to the VPLS to transparently transmit private VLAN packets Access to the L2VPN and PWE3 to transparently transmit private VLAN packets
VLAN-based QinQ
VLAN-based QinQ is also called selective QinQ. Figure 5-8 shows the networking diagram of applying selective QinQ. With the development of services such as broadband access, VoIP, and IPTV services, ISPs may want to assign inner VLAN tags to different services. For example:
l l l
VLANs 10001999: broadband access services VLANs 20002999: VoIP services VLANs 30003999: IPTV services
Issue 03 (2009-03-10)
Page 67 of 200
Figure 5-8 Typical networking diagram of the VLAN-based QinQ application
iManager N2000 IP backbone/MAN

VLAN200 Broadband access VLAN100 VLAN2001 VLAN3001 VLAN1001 VLAN1xxx VLAN300 VOIP access VLAN3xxx IPTV access VLAN2xxx VLAN2002 VLAN3002 VLAN1002
Service gateway
LAN Switch
PVC1001 PVC2001 PVC3001
PC
IPTV Videophone
PC
IPTV Videophone
Users access the DSLAM through multiple PVCs. The DSLAM transfers PVC IDs to VLAN IDs. You can enable selective QinQ on the gateway to apply an outer VLAN tag with the VLAN ID as 100 to broadband access services, an outer VLAN tag with the VLAN ID as 200 to VoIP services, and an outer VLAN tag with the VLAN ID as 300 to IPTV services. This breaks the limit of 4094 VLAN IDs for one ISP network. In addition, services are distributed, which facilitates the ISP's service management. Services are distributed in one of the following ways:
l
Adds different outer VLAN tags based on VLAN ranges, that is, changes packets with a single tag to packets with double tags. In this manner, services from different terminals are distributed. Adds different outer VLAN tags based on different protocol numbers, that is, adds a tag to protocol packets. In this manner, services from different terminals are distributed. Changes outer VLAN tags based on the range of inner VLAN tags, that is, replacing a single tag with another tag. In this manner, services of different use types are distributed. This is also called VLAN mapping.
VLAN-based QinQ may serve as one of the VPLS modes to allow packets of private VLANs to be transmitted transparently through the backbone network. It may also serve as one of the L2VPN or PWE3 modes to allow packets of private VLANs to be transmitted transparently through the backbone network. Such a QinQ mode is implemented on switched interfaces. The differences between VLAN-based QinQ and interface-based QinQ are as follows:
l
In interface-based QinQ mode, user packets from the same user side are added with the same outer VLAN tag on the PE.
Issue 03 (2009-03-10)
Page 68 of 200

l
In VLAN-based QinQ mode, user packets from the same user side are added with different outer VLAN tags according to user's VLAN tags.
Therefore, VLAN-based QinQ is more flexible than interface-based QinQ. VLAN-based QinQ is thus called selective QinQ.
VLAN Stacking
The early QinQ technology is used on switches on Layer 2 networks. With VLAN stacking, packets are forwarded at Layer 2 by means of the outer VLAN tag. The outer VLAN usually refers to the VLAN to which an ISP network belongs. VLAN stacking is usually applied on switched interfaces. The sub-interfaces for VLAN stacking are deployed on PEs. A sub-interface identifies a user VLAN and then performs VLAN stacking to user's Layer 2 packets. After that, packets are forwarded at Layer 2 by means of the outer VLAN tag. With a sub-interface for VLAN stacking, packets from a batch of user VLANs can be transparently transmitted. Packets enter an L2VPN based on their outer VLAN tag after VLAN stacking is implemented. The outer VLAN tag is transparent to the ISP. User packets from different VLANs can thus be transparently transmitted. VLAN stacking support the following:
l l
Access to the VPLS through the sub-interfaces for VLAN stacking Access to the VLL/PWE3 through the sub-interfaces for VLAN stacking
QinQ Termination
Sub-interfaces for QinQ VLAN tag termination refer to the sub-interfaces that terminate the double VLAN tags of users. The difference between the sub-interfaces for QinQ VLAN tag termination and the sub-interfaces for VLAN stacking is as follows: For the sub-interfaces for QinQ VLAN tag termination, a PE removes the double VLAN tags of user packets when they enter the ISP network. Double VLAN tags for users have specific meanings. For example, the outer VLAN tag specifies a service and the inner VLAN tag specifies a user. Sub-interfaces for QinQ VLAN tag termination access the user and identify the service by terminating double VLAN tags. Sub-interfaces for QinQ VLAN tag termination are similar to common VLAN sub-interfaces. In addition, sub-interfaces for QinQ VLAN tag termination are used to terminate double VLAN tags and provide the following functions:
l l l l l l
IP forwarding L3VPN/PWE3/VLL/VPLS access Proxy ARP Unicast routing protocols VRRP DHCP server and DHCP relay
Sub-interfaces for QinQ VLAN tag termination terminate double VLAN tags in the following ways:
l
Exact termination Double VLAN tags of specified VLAN IDs are terminated.
Issue 03 (2009-03-10)
Page 69 of 200

l
Fuzzy termination Double VLAN tags of VLAN IDs in a specified range are terminated.
Compatibility of QinQ EType in the Outer Tag

As defined in 802.1Q, the value of the EType field in the Tag Protocol Identifier (TPID) is fixed to 0x8100. In QinQ encapsulation, the value of the EType field in the TPID in the inner tag is 0x8100, irrespective of manufacturers. The value of the EType field in the TPID in the outer tag, however, varies with the manufactures. To connect devices of different manufacturers, the value of the Etype field in the TPID in the outer tag must be set to the same. Thus, the devices should be able to identify and encapsulate such QinQ packets.
In IEEE 802.1ad, the value of the EType field in the TPID is defined as 0x88a8.
Figure 5-9 Compatibility of the Etype of QinQ outer TPIDs

0x 9 1 00
IP/MPLS Core Router A
0x9100
0x 81
Switch A CX
00
Router C
As shown in Figure 5-9, the inbound interface on the router needs to identify the EType value 0x9100 in the outer TPID. The Etype values, such as 0x9100 and 0x8100, of different outer TPIDs can be set for devices of different manufacturers so that devices of different manufacturers can be set with the same Etype value in the outer TPID. This ensures communication between devices of different manufacturers.
Application of Multicast QinQ

Figure 5-10 shows the networking diagram of applying multicast QinQ. The multicast router PE1 and the access device PE2 are connected through interfaces enabled with QinQ. Users from different VLANs are connected to PE2.
Issue 03 (2009-03-10)
Page 70 of 200
Figure 5-10 Typical networking diagram of multicast QinQ application
Internet /Intranet Multicast source
PE1 QinQ(VLAN1) PE2
VLAN2
VLAN3
No matter whether multicast data packets or multicast protocol packets are received, they are not encapsulated by QinQ. Instead, their packets are transmitted according to the outer P-VLAN IDs. In IGMP snooping, only the P-VLAN ID mapping to the user host is maintained. In forwarding, the system searches the member host of the mapped multicast group according to the P-VLAN ID and replaces the P-VLAN tag with the C-VLAN tag in the packet for forwarding.
5.1.6 RRPP Link Features

The Rapid Ring Protection Protocol (RRPP) is a link protocol exclusively used by Ethernet rings. When the Ethernet ring is in the normal state, RRPP can avoid broadcast storm caused by loop. When a link on the Ethernet link is disconnected, RRPP can promptly enable the standby link to restore the connection.
Issue 03 (2009-03-10)
Page 71 of 200
Figure 5-11 Networking of RRPP tangent ring application to the MAN
RRPP Domain Master Node SwitchA CX-B
Edge Node
RRPP Sub-Ring 1 RouterA RRPP Major-Ring
Master Node
Master Node Assistant Node Transit Node RRPP Sub-Ring 2
SwitchB
CX-C
Traditionally, an RRPP domain consists of a group of interconnected switches with the same domain ID and control VLAN. An RRPP domain includes the following parts:
l l l l l
Major ring and sub-ring Control VLAN Master node and transit node Common port and edge port Primary port and secondary port
Polling Mechanism
Polling is a mechanism used by the master node on the RRPP ring to detect the network status. The master node sends Hello packets periodically from its primary port. The packets are transmitted by the transit nodes on the ring. If the master node can receive the packets from its secondary interface, it indicates that the link of the ring is in the normal state; otherwise, the master node considers that a link fault occurs to the ring. When the master node that is in the Failed state receives the Hello packets from its secondary interface, it changes into the Complete state, blocks its secondary interface, and refreshes the Forwarding Database (FDB). The master node also sends packets from its primary interface to inform all transit nodes to release the temporary blocked interface and refresh the FDB.
Issue 03 (2009-03-10)
Page 72 of 200
Link Status Notification Mechanism

If a link fault occurs to the ring, the directly connected interface of the link becomes Down. The transit node informs the master node of the fault by sending Link-Down packets. When the master node receives the Link-Down packets, it considers that the ring is in the abnormal state, enables its secondary interface, and sends packets to inform other transit nodes to refresh the FDB at the same time. After other transit nodes refresh the FDB, the traffic is switched back to the normal link. After link fault recovery, the interface of the transit node becomes Up. The transit node temporarily blocks the interface that becomes Up. Hello packets sent by the master node can pass through the blocked interface. When the secondary interface of the master node receives the Hello packets sent by itself, it considers that the link becomes normal again. The master node blocks the secondary interface, sends packets to inform other transit nodes to enable the blocked interface, and refreshes the FDB.
Channel Status Detection of Sub-Ring Protocol Packets on the Major Ring

Channel status detection of sub-ring protocol packets on the major ring is applied to the networking in which multiple sub-rings are intersectant with the major ring. When a fault occurs to the major ring and the master nodes on all the sub-rings enable the secondary interfaces, a broadcast storm is caused. To avoid this, channel status detection mechanism of sub-ring protocol packets on the major ring is introduced. The mechanism requires the cooperation between edge nodes and assistant edge nodes. Before the master nodes on the sub-rings enable the secondary interfaces, loop between the sub-rings can be avoided by blocking the interfaces of the edge nodes. The edge nodes initiate the mechanism. The assistant edge nodes monitor the channel status and inform the edge nodes of the channel status change on time.
5.1.7 RSTP/MSTP
The Rapid Spanning Tree Protocol (RSTP) is an enhancement of the Spanning Tree Protocol (STP). RSTP simplifies the processing of the state machine, blocks some redundant paths with specific algorithms, and reconstructs the networks with loops to a loop-free network. In this way, the packets are prevented from increasing and infinitely looping. Compared with STP, RSTP speeds up the Layer 2 loop convergence. In a Layer 2 network, only one Shortest Path Tree (SPT) is generated. The Multiple Spanning Tree Protocol (MSTP) is the multi-instance RSTP. MSTP supports the running of STP based on one or more VLAN. In a Layer 2 network, MSTP can be generated.
5.1.8 BPDU Tunnel

BPDUs are Layer 2 protocol messages and are transparently transmitted through a Layer 2 protocol tunnel or a BPDU tunnel across an ISP network. To transmit BPDUs transparently across an ISP network, ensure that the following requirements are met:
l l
All branches of the same user network are able to receive their own BPDUs. BPDUs of a user network cannot be processed by the CPU of the ISP network.
Issue 03 (2009-03-10)
Page 73 of 200

l
BPDUs of different customers must be segregated to prevent them from mutual access.
The CX600 supports the following types of transparent transmission of BPDUs:

l l l l
Transparent transmission of interface-based BPDUs of the same user network Transparent transmission of interface-based BPDUs of different user networks Transparent transmission of VLAN-based BPDUs Transparent transmission of QinQ-based BPDUs
5.2 IP Features
5.2.1 IPv4/IPv6 Dual-Protocol Stacks
Figure 5-12 shows the structure of the IPv4/IPv6 dual-protocol stacks. Figure 5-12 Dual-protocol stacks structure
IPv4/IPv6 Application
TCP
UDP
IPv4
IPv6
Link Layer
5.2.2 IPv4 Features

The CX600 supports the following IPv4 features:
l l l l l
TCP/IP protocol suite, including ICMP, IP, TCP, UDP, socket (TCP/UDP/Raw IP), and ARP Static DNS and DNS server FTP server/client and TFTP client DHCP relay agent and DHCP server Ping, tracert, and NQA NQA can probe the status of ICMP, TCP, UDP, DHCP, FTP, HTTP, and SNMP services and test the response time of the services. The system supports NQA in UDP jitter and ICMP jitter tests by transmitting and receiving packets on LPUs. The minimum frequency for transmitting packets can be 10 ms. Each LPU supports up to 100 concurrent jitter tests. The entire system supports up to 1000 concurrent jitter tests.
Issue 03 (2009-03-10)
Page 74 of 200

l
IP policy-based routing to specify the next hop based on the attribute of packets without searching routes in the routing table
5.2.3 IPv6 Features

The CX600 supports the following IPv6 features:
l l l l l l
IPv6 neighbor discovery (ND) Path MTU (PMTU) discovery TCP6, ping IPv6, tracert IPv6, and socket IPv6 Static IPv6 DNS and specified IPv6 DNS server TFTP IPv6 client IPv6 policy-based routing
5.2.4 GRE
Generic Routing Encapsulation (GRE) is used to encapsulate packets of certain network layer protocols (such as IPX or IP) so that the encapsulated packets can be transmitted over the network on which another network layer protocol (such as IP) is applied. As a Layer 3 tunnel protocol for VPNs, GRE uses the tunneling technology. A tunnel can be taken as a virtual interface that supports only P2P connections. The tunnel interface provides a tunnel for datagram forwarding and the packets are encapsulated and decapsulated at both ends of the tunnel. GRE is applied to in the following situations.
Multi-Protocol Local Network Transmission Through Single-Protocol Backbone Network

Figure 5-13 Multi-protocol local network transmission through the single-protocol backbone network
Novell IPX group 1
CX-A Internet Tunnel
CX-B
Novell IPX group 2
IP term 1
IP term 2
In Figure 5-13, Group 1 and Group 2 are the local networks running Novell IPX. Team 1 and Team 2 are the local networks running the IP protocol. The tunnel between CX A and CX B adopts the GRE protocol; therefore, Group 1 communicates with Group 2 without affecting the communication between Team 1 and Team 2.
Issue 03 (2009-03-10)
Page 75 of 200
Enlarging Operation Scope of the Network with Limited Hops

Figure 5-14 Enlarging the network operation scope
IP network IP network IP network
Tunnel
PC
PC
In Figure 5-14, the IP protocol is run on the network. Assume that the IP protocol limits the hop count to 255. If the hop count between two PCs is greater than 255, they cannot communicate. When the tunnel is used in the network, a few hops are hidden. This enlarges the scope of the network operation.
Connecting Some Discontinuous Sub-Networks to Establish a VPN

GRE tunnels can be used to connect discontinuous sub-networks to implement the VPN across the WAN. For example, two VPN sub-networks, Site 1 and Site 2 are in two cities. By setting up a GRE tunnel between the devices at the network edge, you can connect the two sub-networks to a continuous VPN network. GRE can be applied both in L2VPN and L3VPN in two modes as follows:
l
As shown in Figure 5-15, the two ends of the GRE tunnel reside on the CE router in the CPE-based VPN.
Figure 5-15 GRE in the CPE-based VPN
GRE tunnel VPN site1 CE PE VPN backbone VPN site2 PE CE
As shown in Figure 5-16, the two ends of the GRE tunnel reside on the PE router in the network-based VPN.
Issue 03 (2009-03-10)
Page 76 of 200
Figure 5-16 GRE in the network-based VPN

VPN backbone VPN site1 CE PE GRE tunnel PE CE VPN site2
Usually, the MPLS VPN backbone network uses label switched paths (LSPs) as the public network tunnel. If the core router P in the backbone network, however, provides only the IP function without the MPLS function while the PE router at the network edge has the MPLS function, the LSP cannot be used as the public network tunnel. Then, you can use the GRE tunnel in place of the LSP to provide Layer 3 or Layer 2 VPN solutions at the core network.
Accessing of CEs to an MPLS VPN Through GRE Tunnels

The VPN services based on the MPLS backbone network are better than the traditional IP VPN services. Therefore, most ISPs tend to choose the MPLS VPN technology. The Internet, however, is based on the IP technology and a great number of backbone networks based on the IP technology still exist. In the MPLS VPN, to access a CE to the VPN, a physical link is needed to directly connect the CE to the PE in the MPLS backbone network, that is, the CE and the PE must be in the same network. In this networking, you must associate the VPN with the PE physical interface that is connected to the CE. In actual networking, not all the CEs and PEs can be directly connected through physical links. For example, for multiple institutions that are connected to the Internet or the IP backbone network, their CEs and PEs are geographically dispersed. In this case, the CEs cannot directly access the PEs in the MPLS backbone network. These institutions cannot directly access the sites inside the MPLS VPN through the Internet or the IP backbone network. Figure 5-17 CEs accessing the MPLS VPN backbone network through the backbone network based on the IP technology
VPN Site CE
IP network PE
MPLS network PE CE
VPN Site
To connect a CE to the MPLS VPN, you can create a logically direct connection between the CE and the PE. That is, you can connect the CE and the PE by using the public network or private network, and create a GRE tunnel between the CE and the PE. Then, the CE and the PE can be regarded as being directly connected. When associating the VPN with the PE interface that is connected to the CE, you can regard the GRE tunnel as a physical interface.
Issue 03 (2009-03-10)
Page 77 of 200
5.2.5 IPv4/IPv6 Transition Technologies

IPv6 over IPv4 Tunnel
As shown in Figure 5-18, the IPv6 over IPv4 tunnel technology is used for the transition from the IPv4 network to the IPv6 network. Figure 5-18 IPv6 tunnel
Dual Stack Router IPv6 IPv6 host
IPv6 Header IPv6 Data IPv4 Header IPv6 Header IPv6 Data
Dual Stack Router IPv4

Tunnel
IPv6 IPv6 host

IPv6 Header IPv6 Data
The CX600 supports the following IPv6 over IPv4 tunnels:

l
Manually configured IPv6 tunnel In this mode, the IPv6 tunnel is manually configured on the two edge routers at both ends of the tunnel. The source and destination IPv4 addresses of the tunnel are configured manually. The tunnel is equivalent to a permanent link between two IPv6 domains over an IPv4 backbone network. The tunnel is used for regular and secure communication between two edge routers on isolated IPv6 sites.
IPv6 over IPv4 GRE tunnel The IPv6 traffic can be carried over IPv4 GRE tunnels. When carrying the IPv6 traffic, the IPv4 GRE tunnels are called IPv6 over IPv4 GRE tunnels (GRE tunnels for short). The same as the manually configured IPv6 over IPv4 tunnel, a GRE tunnel is a link between two nodes, with a separate tunnel for each link. The tunnels carry IPv6 as the passenger protocol and GRE as the carrier protocol.
Automatically configured IPv4-compatible IPv6 tunnel (automatic tunnel for short) An IPv4-campatible IPv6 address is needed when an IPv6 over IPv4 automatic tunnel is created. The low order 32 bits of an IPV4-compatible IPv6 address are an IPv4 address. It is used to identify the destination address of the automatic tunnel. To create an automatic tunnel, you need to specify only the source address of the tunnel on an edge router or a host. The destination address of the tunnel can be automatically identified based on the next hop address (an IPv4-compatible IPv6 address) of IPv6 packets.
6 to 4 tunnel A 6 to 4 tunnel connects isolated IPv6 islands to the IPv6 Internet over an IPv4 network. The difference between the 6 to 4 tunnel and the manually configured tunnel is that the former can be a point-to-multipoint (P2MP) connection, whereas the latter is a P2P connection. Therefore, routers of the 6 to 4 tunnel are not configured in pairs. Similar to the automatic tunnel, the 6 to 4 tunnel can automatically search the other end of the tunnel. It need not be configured with an
Issue 03 (2009-03-10)
Page 78 of 200
IPv4-compatible IPv6 address. The 6 to 4 tunnel uses a type of special IPv6 address, that is, 6 to 4 address.

In the post-phase of the transition from the IPv4 network to the IPv6 network, a great number of IPv6 networks are constructed. Then the isolated IPv4 site may emerge. It is not economic to connect the isolated sites through the dedicated lines. With the tunneling technology, tunnels can be created in the IPv6 network; thus the isolated IPv4 sites can be interconnected. This is similar to the VPN deployment in the IP network with tunneling. The tunnels that are used to connect the isolated IPv4 sites, in the IPv6 network, are called IPv4 over IPv6 tunnels. To set up IPv4 over IPv6 tunnels, IPv4/IPv6 dual stack needs to be enabled on the router at the edge of the IPv6 network and the IPv4 network. Figure 5-19 Networking diagram of the IPv4 over IPv6 tunnel
Dual Stack Router IPv4 network IPv4 Host IPv6 network
Dual Stack Router IPv4 network IPv4 Host
IPv6 Header IPv4 Header IPv4 Header IPv4 Payload IPv4 Payload IPv4 Payload IPv4 Header
6PE
The IPv6 Provider Edge (6PE) router allows communication between the IPv6 isolated CE routers over the IPv4 network. See Figure 5-20. With 6PE routers, ISPs can provide access services to the IPv6 network of isolated customers over the existing IPv4 backbone network.
Issue 03 (2009-03-10)
Page 79 of 200
Figure 5-20 6PE topology
IPv4/MPLS Cloud IBGP
CE IPv6 Cloud Customer site
CE IPv6 Cloud Customer site
The 6PE router labels IPv6 routing information and floods them onto ISPs IPv4 backbone network through Internal Border Gateway Protocol (IBGP) sessions. The IPv6 packets are labeled before flowing into tunnels such as the GRE tunnel and MPLS LSP on the backbone network. The IGP protocol used on the ISP network can be OSPF or IS-IS, and the protocol used between CE routers and 6PE routers can be a static routing protocol, IGP or EBGP. When ISPs want to extend their IPv4/MPLS networks with IPv6 traffic exchange capability, they can just update the PE router. Therefore, using the 6PE feature as an IPv6 transition mechanism is a cost-effective solution for ISPs.
5.3 Routing Protocols

The CX600 supports various unicast and multicast routing protocols; thus different networking requirements are satisfied.
5.3.1 Unicast Routing

The CX600 supports the following unicast routing features:
l l l l l
IPv4 routing protocols: RIP, OSPF, IS-IS, and BGPv4 IPv6 routing protocols: RIPng, OSPFv3, IS-ISv6, and BGP4+ Static routes to simplify network configuration and improve network performance Large-capacity routing table to support MAN operation effectively Determining the optimal route through the routing policy
5.3.2 Multicast Routing

To save network bandwidth and reduce network load, the CX600 supports multicast.
Basic Multicast Functions

The CX600 provides the following multicast functions:
Issue 03 (2009-03-10)
Page 80 of 200

l
Multicast protocols: Internet Group Management Protocol (IGMP), Protocol Independent Multicast-Dense Mode (PIM-DM) and Protocol Independent Multicast-Sparse Mode (PIM-SM), Multicast Source Discovery Protocol (MSDP), and Multi-protocol Border Gateway Protocol (MBGP). RPF check: When a router creates and maintains multicast routing entries, it performs Reverse Path Forwarding (RPF) check to ensure that the multicast data is transferred along the correct path. PIM-SSM: If the multicast source is specified, a host can join the multicast source directly, without registering with the Rendezvous Point (RP). Anycast RP: Multiple RPs can exist in a domain and they are configured as MSDP peers. A multicast source can choose the nearest RP for registration, and the receiver can also choose the nearest RP to join its shared tree. In this manner, load balancing is carried out among the RPs. When a certain RP fails, its previous registered sources and receivers choose another nearest RP instead. This implements the backup of RPs. IPv6 multicast routing protocols: PIM-IPv6-DM, PIM-IPv6-SM, and PIM-IPv6-SSM. MLD: MLD is used to set up and maintain the member relationship of groups between hosts and their directly connected multicast routers. The functions and principles of MLD are the same as those of the IGMP. MLD has the follow versions:
l l
l l
MLDv1 MLDv1 is defined in RFC 2710 and derived from IGMPv2. MLDv1 supports the Any-Source Multicast (ASM) model. With the help of SSM mapping, MLDv1 can support the Source-Specific Multicast (SSM) model.
MLDv2 MLDv2 is defined in RFC 3810 and derived from IGMPv3. MLDv2 supports the ASM and SSM models.
l l l
Multicast static routes. Configuration of multicast protocols on physical interfaces such as Ethernet and POS interfaces, and IP-Trunk and Eth-Trunk interfaces. When receiving, importing, and advertising multicast routes or forwarding IP packets, the multicast routing module can filter routes or packets based on routing policies. Multicast VPN: The CX600 adopts the Multicast Domains (MD) scheme to implement centralized processing. Addition and deletion of dummy entries.
l l
IGMP Snooping
The CX600 supports IGMP snooping for Layer 2, Layer 3, and QinQ interfaces, VPLS PW, STP, and RRPP. IGMP snooping listens to the IGMP messages between routers and hosts and sets up the Layer 2 forwarding table for multicast data packets. In this manner, IGMP snooping controls and manages the forwarding of multicast data packets to carry out Layer 2 multicast. IGMP snooping aims to control the flooding of multicast flows, forward packets as required, and save network resources. For the interface that joins a multicast group
Issue 03 (2009-03-10)
Page 81 of 200
without transmitting IGMP Report messages for application, the device does not send the multicast flow to the interface.
Flow Control of Multicast Traffic

Unknown multicast packets refer to those packets for which no forwarding entries are found in the multicast forwarding table. The CX600 supports the following measures to process the unknown multicast packets:
l l
Discards the packets directly after receiving them. Broadcasts the packets in the VLAN to which the receiving interface belongs.
To control multicast traffic, the CX600 also supports the limit to the maximum percentage of multicast traffic on Ethernet interfaces.
Multicast VLAN
Multicast VLAN refers to the VLAN that converges multicast flows. When users need certain multicast flows, they send a request to the multicast VLAN. Then, the multicast VLAN replicates the multicast packets to different user VLANs. This implements the function of multicast across VLANs. The CX600 forwards multicast packets through the multicast VLAN and replicates the packets based on the multicast routing entries. Then, the CX600 sends these packets to the VLANs of different users. Using the multicast VLAN, the CX600 can converge the multicast flows of different user VLANs to one or several specified VLANs. Multicast across VLANs enables the CX600 to send unicast and multicast packets across different VLANs. This facilitates the management and control of multicast flows. This can also save bandwidth resources and improve the network security.
1+1 Protection of Multicast Traffic

1+1 protection of multicast traffic is implemented through the multicast across the VLANs. The Internet Context Provider (ICP) replicates and sends the multicast packets to two multicast VLANs. The multicast packets and Continuity Check Messages (CCMs) for detecting the link status in those two multicast VLANs are then forwarded to the CX600 on the user side. The CX600 on the user side determines the link status based on the CCMs received and specifies a multicast VLAN in the good link state to receive multicast packets. At present, the CX600 supports only 1+1 protection of multicast traffic in VLANs.
Multicast VPN
With wide applications of Virtual Private Network (VPN), the requirements of users for operating multicast services over VPNs are increasingly stringent. The CX600 adopts the MD solution to implement multicast transmission over VPNs. For details, see Section 5.5 VPN Features."
Issue 03 (2009-03-10)
Page 82 of 200
Multicast CAC
The CX600 supports multicast Call Admission Control (CAC). When multicast CAC rules are configured, the number of multicast groups and bandwidth are restricted for IGMP snooping on interfaces or the entire system. Multicast CAC is part of the IPTV multicast solutions. With the development of the IPTV, the number of program channels is bursting. The bandwidth of the access and convergence network no longer satisfies the bandwidth requirements of users. The previous static management is thus outdated. In this manner, the number of users allowed to access each link must be set on the convergence network. Multicast CAC restrains the generation of multicast forwarding entries. When the set threshold is reached, no more forwarding entries are generated. This ensures the processing capacity of the device and controls link bandwidth.
5.4 MPLS Features

5.4.1 Basic Functions
The CX600 supports MPLS and static and dynamic LSPs. Static LSPs require that the administrator configure the Label Switch Routers (LSRs) along the LSPs and set up LSPs manually. Dynamic LSPs are set up dynamically in accordance with the routing information through Label Distribution Protocol (LDP) and Resource Reservation Protocol (RSVP-TE). The CX600 supports the following MPLS functions:
l
Basic MPLS functions, service forwarding, and LDP LDP distributes labels, sets up LSPs, and transfers parameters used for setting up LSPs.
LDP

DU and DoD label distribution modes Independent label distribution control and sequential label control modes Liberal retention and conservative retention modes Maximum number of hops and path vector
MPLS ping and tracert MPLS Echo Request packets and MPLS Echo Reply packets are transmitted to detect the availability of an LSP.
l l l l l
Traffic statistics for LSPs LSP loop detection mechanism MPLS QoS, mapping of the ToS field in IP packets to the EXP field in MPLS packets, and MPLS uniform, pipe, and short pipe modes Static configuration of LSPs and label forwarding based on traffic classification MPLS trap
The CX600 can serve as a Label Edge Router (LER) or an LSR.

l
An LER is an edge device on the MPLS network to connect other networks. It classifies services, distributes labels, encapsulates or removes multi-layer labels.
Issue 03 (2009-03-10)
Page 83 of 200

l
An LSR is a core router on the MPLS network. It switches and distributes labels.
5.4.2 MPLS TE
Network congestion lowers the performance of the backbone network. The congestion may be caused by insufficient resources or unbalanced load of network resources. Traffic Engineering (TE) is introduced to address the congestion caused by unbalanced load of network resources. The MPLS TE technology integrates the MPLS technology with traffic engineering. It can reserve resources by setting up the LSP tunnels to a specified path in an attempt to avoid network congestion and balance network traffic. In the case of resource scarcity, MPLS TE can preempt bandwidth resources of the LSPs with low priorities. This meets the demands of the LSPs with large bandwidth or for important services. In addition, when an LSP fails or a node is congested, the MPLS TE can protect the network communication through the backup path and the fast reroute (FRR) function. MPLS TE provides the following functions:
l
Processing of static LSPs MPLS TE creates and deletes static LSPs, which require bandwidth but are manually configured.
Processing of Constrained Route-Label Switched Path (CR-LSP) MPLS TE processes various types of CR-LSPs.
The processing of static LSPs is easier. CR-LSPs are classified into the types described in the following sections.
RSVP-TE
RSVP is designed for the Integrated Service (IntServ) model and used on each node of a path for resource reservation. To put it simply, RSVP has the following characteristics:
l l l
Unidirectional. Receiver-oriented: The receiver initiates a request for resource reservation and maintains the resource reservation information. It uses a soft state mechanism to maintain the resource reservation information.
RSVP, after being extended, can support MPLS label distribution. It carries resource reservation information when transmitting label-binding message. The extended RSVP is called RSVP-TE, used as a signaling protocol to establish LSPs in MPLS TE.
Auto Route
In auto routes, LSPs participate in IGP route calculation as logical links. The tunnel interface is taken as the outbound interface of packets. In this manner, LSPs are considered as P2P links. The following describes two types of auto routes:
l l
IGP shortcut: The LSP is not advertised to the neighboring router. So, other routers cannot use this LSP. Forwarding adjacency: The LSP is advertised to the neighboring router. So, other routers can use this LSP.
Issue 03 (2009-03-10)
Page 84 of 200
Fast Reroute
FRR is a technology in MPLS TE to implement the partial protection of the network. The switching speed of FRR can reach 50 milliseconds. This minimizes data loss when the network fails. FRR is only a temporary protection method. When the protected LSP becomes normal or a new LSP is established, the traffic is switched back to the original LSP or the newly established LSP. After an LSP is configured with FRR, traffic is switched to its protection link and the ingress node of the LSP attempts to establish a new LSP when a link or a node on the LSP fails.
Auto FRR
The FRR technology requires that when configuring a protected tunnel, you must configure a bypass tunnel to bind to it. When a link or a node is Down, the data flow can be automatically switched to the bypass tunnel. In the FRR protection, the bypass LSP must be configured manually. If it is not configured, the protected LSP cannot be protected. The Auto FRR can solve the preceding problem. Auto FRR is an extension of MPLS TE FRR. Bypass LSPs can be automatically set up along the LSP after you configure the attributes of bypass LSPs, global Auto FRR attributes, and Auto FRR attributes of the interface. In addition, when the primary LSP changes, the original bypass LSPs can be automatically deleted and new bypass LSPs are set up.
CR-LSP Backup
The LSP that is used to protect the primary LSP in the same tunnel is called the backup LSP. When the ingress detects that the primary LSP is unavailable, it switches traffic to the backup path. After the primary LSP recovers, traffic is switched back to the backup LSP. In this manner, the traffic on the primary LSP is protected. The CX600 supports the following methods of backup:
l
Hot backup: The backup CR-LSP is established immediately after the primary CR-LSP is established. When the primary CR-LSP fails, MPLS TE switches traffic immediately to the backup CR-LSP. Ordinary backup: The backup CR-LSP is established when the primary CR-LSP fails.
LDP over TE
In existing networks, not all devices support MPLS TE. Only the devices in the core of the network support TE and the devices at the network edge use LDP. The application of LDP over TE is then put forward. The TE tunnel is considered as a hop of the entire LDP LSP. LDP is widely used in MPLS VPNs. To prevent the congestion of VPN traffic on certain nodes, you can configure LDP over TE.
Issue 03 (2009-03-10)
Page 85 of 200
Figure 5-21 Typical application of LDP over TE
10
R3
10
CX1
R2 20 R4 10
R5
CX6
Figure 5-21 shows the MPLS VPN networking. Here, LDP is used as the signaling protocol. As the PE router, CX 1 and CX 6 discover that the links between Router 2 and Router 3 are rather congested after a large amount of user access. This also happens because the traffic between Router 1 and Router 6 must pass through this link. The link between Router 2 and Router 4 is free. The LSP, however, cannot use the link between Router 2 and Router 4 for the influence of the IGP cost value. Establish the TE tunnel passing through Router 4 between R2 and R5, and adjust the metric value of the IGP shortcut. Thus, the two routes of R2 implement load balancing:
l l
The physical interface between R2 and R3 The TE tunnel interface from R2 to R5
LDP establishes the LSP for load balancing to let traffic go along the idle link.
5.4.3 MPLS OAM

MPLS supports multiple Layer 2 and Layer 3 protocols such as IP, FR, ATM, and Ethernet. It supports an OAM mechanism that is independent of the upper and lower layers. MPLS OAM provides the following functions:
l l l l
Detecting the LSP connectivity Measuring the network utility and performance Performing the protection switching in the case of a link failure. Providing services based on the Service Level Agreement (SLA) signed with the customers.
With MPLS OAM, you can detect, identify, and locate failures in an MPLS network. The failure is reported and removed in time. In addition, MPLS OAM provides a mechanism for triggering protection switching. MPLS OAM provides the following functions:
l
MPLS OAM detection MPLS OAM sends CV/FFD and BDI packets along the LSPs to be detected and the reverse channels between the LSP ingress and egress to detect the connectivity.
Issue 03 (2009-03-10)
Page 86 of 200
Figure 5-22 MPLS OAM
F V/
FD
CV
/F
FD
Ingress LSR
BD
Egress LSR
I
BD
l l
OAM auto protocol function Protection switch 1:1, 1+1, sharing protection, and packet-level protection are supported.
5.5 VPN Features

5.5.1 Tunnel Policy
A tunnel policy is used to select a tunnel based on the destination IP address. An application selects tunnels according to the tunnel policy. If no tunnel policy is configured, the tunnel management module selects tunnels according to the default policy. The CX600 supports the following types of tunnel policies:
l
With the tunnel policy in select-sequence mode, you can specify the sequence in which the tunnel types are used and the number of tunnels carrying out load balancing. For a tunnel policy in select-sequence mode, tunnels are selected in sequence. If a tunnel listed earlier is Up, it is selected regardless of whether other services have selected it. The tunnels listed later are not selected except in cases of load balancing or when the preceding tunnels are Down. VPN tunnel binding refers to the binding of the peer PE on a VPN to an MPLS TE tunnel on the PE of the VPN backbone network. The VPN data to the peer PE is always transmitted through the bound TE tunnel. It carries only specified VPN services rather than other VPN services. This guarantees the QoS of the specified VPN services.
5.5.2 VPN Tunnel

The CX600 supports the following types of VPN tunnels:
l
LSP When a label is distributed to an FEC on the LSP ingress, traffic is transparently forwarded along the transit nodes of the LSP according to the label. In this manner, an LSP can be considered as an LSP tunnel.
Issue 03 (2009-03-10)
Page 87 of 200

l
GRE tunnel If the PE router at the edge of the ISP network supports MPLS, whereas the P router supports only IP, an LSP cannot be used as the public tunnel. In this case, a GRE tunnel can be used on the VPN backbone network.
TE tunnel When reroute is configured or traffic is forwarded through multiple paths, multiple LSPs may be needed. In TE, this set of LSPs is called a TE tunnel. The TE tunnel is identified by the tunnel ID and LSP ID. The tunnel ID is used to uniquely define a TE tunnel.
5.5.3 MPLS L2VPN

The CX600 provides Layer 2 VPN (L2VPN) services on an MPLS network. This allows the ISP to provide L2VPNs over different media.
VLL
Figure 5-23 shows the networking of a VLL supported by the CX600. Figure 5-23 MPLS L2VPN
Support dynamic Martini/Kompella L2VPN Support static CCC/SVC L2VPN VPN2 site3 VPN1 site1 VPN2 site2 MPLS network VPN1 site2 VPN2 site2 PE-ASBR PE Support inter-AS solutions: VRF-to-VRF MP-Multihop EBGP PE-ASBR Support MPLS VPN over GRE and MPLS VPN over TE tunnel PE Support access to the MPLS L2VPN through PPP, HDLC, ATM, Eth/VLAN, and Q-in-Q
PE
Support internetworking VPN1 site3
PE
VPN3 site1
VPN3 site2
Provide the VPN manager to manage VPNs among devices of different vendors
Issue 03 (2009-03-10)
Page 88 of 200

l
VLL in Martini mode The Martini mode uses double labels. The inner label uses the extended LDP as the signaling protocol to transmit information. The Martini mode conforms to the draft of draft-martini-l2circuit-trans-mpls. In the Martini draft, LDP is extended by adding an FEC type (VC FEC) for exchanging VC labels. In addition, if the two PEs that exchange VC labels are not directly connected, a remote LDP session must be created on which the VC FEC and the VC label are transmitted. The PE assigns a VC label to each connection between CEs. The VLL information that carries the VC is forwarded to the peer PE of the remote session through the LSP set up through LDP. In this manner, a VC LSP is set up on the ordinary LSP.
VLL in Kompella mode The VLL in Kompella mode is similar to the Layer 3 BGP/MPLS VPN defined in RFC 2547. They adopt BGP as the switching signaling. Similar to the MPLS L3VPN, the VLL adopts BGP as the signaling protocol to transmit Layer 2 information and VC labels. It implements VLL in end-to-end (CE-to-CE) mode in the MPLS network. In the VLL, PEs automatically discover the VLL nodes by creating BGP sessions. Similar to the BGP/MPLS VPN, the VLL in Kompella mode also uses VPN targets to control the sending and receiving of the VPN route, which makes the networking flexible. The VLL in Kompella mode can support inter-AS VPN solutions.
VLL in CCC mode Circuit Cross Connect (CCC) is a technique to implement VLL through static configurations. Different from the common VLL, a CCC VLL adopts one label to transmit user data. Thus, CCC can use LSPs exclusively. The CCC LSP can be used to transmit the data of only this CCC rather than other VLL links. The LSP also cannot be used in the BGP/MPLS VPN or to bear common IP packets. For CCC connections, static LSPs need not be configured for PE routers. If two PE routers are not directly connected, however, a static LSP must be configured on the transit routers.
VLL in SVC mode An SVC VLL is similar to a Martini VLL. But it does not use LDP as the signaling protocol for transmitting Layer 2 VC labels and link information. VC labels are configured manually.
VLL IP-interworking If two CEs access the same VLL through different types of links, the VLL IP-interwoking feature is required. draft-kompella-ppvpn-l2vpn-03 recommends that when an VLL is set up, the VLL interface is encapsulated with ip-interworking on the PE to transparently transmit Layer 3 data, that is, IP packets, in the MPLS network. When the VLL interworking feature is adopted:

VLL interfaces of PEs at both ends must be encapsulated with IP-interworking. The PEs begin to establish an VLL connection after VC interfaces become Up. The PEs allow VLL forwarding when an VLL connection is established. In this case, the system considers the physical link for transparent transmission available, irrespective of whether the status of the link layer protocol is Up or Down.
Issue 03 (2009-03-10)
Page 89 of 200
After both the AC and VLL tunnel become Up, the CEs on both ends can transmit and receive IP packets. After receiving an IP packet from the CE, the PE decapsulates the link layer encapsulation and transmits the IP packet across the MPLS network. The IP packet is transparently transmitted to the peer PE across the MPLS network. The peer PE re-encapsulates the IP packet according to its link layer protocol and transmits the packet to its directly connected CE. The link control packet sent by the CE is processed by the PE without entering the MPLS network. All non-IP packets such as MPLS and IPX packets are discarded.
After an VLL connection is established, the IP packets are processed as follows:

l
Inter-AS VLL The implementation of an inter-AS VLL depends on the actual environment. In CCC mode, the label is of a single layer. Therefore, the inter-AS can be implemented after a static LSP is set up between ASBRs. The following describes the implementation of an inter-AS VLL in comparison with the three methods of implementing an L3VPN.
The SVC, Martini, and Kompella modes can implement the inter-AS VLL Option A (VRF-to-VRF). In an inter-AS VLL network, the link type between the ASBRs must be the same as the VC type. In inter-AS Option A, each ASBR must reserve a sub-interface for each inter-AS VC. If the number of inter-AS VCs is small, Option A can be used. Compared with the L3VPN, the inter-AS Option A of the VLL consumes more resources and requires more configuration workload, which is not recommended. Option B requires the exchange of both the inner label and the outer label on the ASBR. Therefore, Option B is not suitable for the VLL.
Option C is a better solution. The devices on the ISP network only need to set up the outer tunnel on PEs in different ASs. The ASBR does not need to maintain information about the inter-AS VLL or provide interfaces for the inter-AS VLL. The VLL information is exchanged only between PEs. Thus, the resources consumption and the configuration workload decrease.
VPLS
Figure 5-24 shows the networking of VPLS. Several virtual switches (VSs) can be created on a PE router. VSs on different PE routers form an L2VPN. LANs at the user end can access the L2VPN through VSs. In this manner, users can expand their own LAN over the WAN. VPLS can be taken as the VS across public networks. Like L3VPN, it establishes LSPs on public networks for traffic transmission.
Issue 03 (2009-03-10)
Page 90 of 200
Figure 5-24 VPLS network structure
CE VLAN1 VSI 1 PE VSI 2 VSI 2 VSI 1 PE
CE VLAN1
CE VLAN2
VSI 1
VSI 2
CE VLAN2
PE
CE VLAN1
CE VLAN2
VPLS requires that users access the network through Ethernet links. It forwards packets according to the VLAN ID. For communication with remote users, a Virtual Channel (VC) that can traverse the public network is established between PE routers, and the VC is associated with the VLAN ID. Users communicate with each other over the Layer 2 tunnel through the VC. The VLAN ID is used to identify the users' VPN. When establishing a VC, the PE router allocates double labels to the VC. The outer label is the MPLS LSP label of the public network and is allocated by LDP or RSVP-TE. The inner label is the VC label and is allocated after the negotiation between the remote LDP sessions on loopback interfaces. The CX600 supports the following networking models:
l
QinQ VPLS QinQ is a tunnel protocol based on IEEE 802.1Q. In QinQ, the VLAN tag of private networks is encapsulated in the VLAN tag of public networks. The packets carry double tags when being transmitted across the ISP's backbone network. This saves VC resources and provides users with an L2VPN tunnel easy to implement.
HVPLS VPLS requires that PE routers forward Ethernet frames through the full-mesh Ethernet emulation circuit or Pseudo-Wire (PW). Therefore, all PE routers must be connected to each other in the same VPLS. If there are N PEs in a VPLS network, the VPLS has N x (N 1)/2 connections. When the number of PEs increases, the number of VPLS connections increases by N2. Hierarchical Virtual Private LAN Service (HVPLS) is thus introduced to address the full-mesh VPLS. Figure 5-25 shows the HVPLS model.
Issue 03 (2009-03-10)
Page 91 of 200
Figure 5-25 HVPLS model
CE basic VPLS full mesh SPE SPE UPE

PW PW PW
AC
PW AC
SPE
CE
UPE The device directly connected with CE routers is called Underlayer PE (UPE). The UPE only needs to be connected with one of PE routers in the basic VPLS. The UPE supports routing and MPLS encapsulation. If one UPE is connected with many CE routers and provides bridging functions, only the UPE needs to forward the data frame to reduce the burden on the SPE.
SPE The device connected with the UPE and located in the core of the full-mesh VPLS is called Superstratum PE (SPE). The SPE is connected with all other devices in the VPLS. The SPE takes the UPE connected as a CE router. The PW established between the UPE and the SPE is taken as the AC of the SPE. The SPE needs to learn the MAC addresses of sites at the UPE side and the MAC addresses of the UPE interfaces connected with the SPE.
IGMP snooping VPLS can isolate users. Each VPN needs to support IGMP snooping, that is, the multi-instance IGMP snooping. VPLS learns MAC addresses in the following modes:
Unqualified The Unqualified mode refers to allowing numerous VLANs in a VSI to share a MAC address space and a broadcast area. VLANs need be learned.
Qualified The Qualified mode refers to allowing a VLAN in a VSI to have an independent MAC address space and broadcast area. VLANs need not be learned.
mVPLS mVPLS refers to a management VPLS. The VSIs associated with the mVPLS are called management VSIs (mVSIs). The prerequisite to the Up state of an mVSI differs from that to a common VSI (service VSI) as follows:

Common VSI: has two or more Up AC interfaces, or has both one Up AC interface and one Up PW. mVSI: has one Up PW or AC interface.
Issue 03 (2009-03-10)
Page 92 of 200
An mVSI can be bound to a common VSI. When an mVSI receives a gratuitous ARP packet or a BFD Down packet, the mVSI notifies all the common VSIs bound to it to clear MAC address entries and re-learn MAC addresses.
l
Ethernet loop detection Virtual Private LAN Service (VPLS) is a significant technology for the Metropolitan Area Network (MAN). To avoid the impact of single point failures on services, user networks are connected to the VPLS network of a carrier through redundant links. The redundant links, however, lead to loops, which further causes the broadcast storm. In networking applications, you can deploy the Spanning Tree Protocol (STP) or common loopback detection technologies to avoid the preceding problems. In practice, however, STP should be deployed at the user side, and the common loopback detection technology requires the devices at the user side to allow special Layer 2 loopback detection packets to pass through. When user networks cannot be controlled, you can deploy Ethernet loop detection supported by the CX600 over the carrier network. Ethernet loop detection need not be deployed at the user side. This also avoids the broadcast storm caused by loops formed in a VPLS network.
VPLS/HVPLS equal-cost load balancing In VPLS/HVPLS services, when there are multiple public tunnels of equal cost from the local PE to remote PE, the VPLS PW performs the HASH algorithm and then select one tunnel to forward data flows. Different data flows over the same PW may be forwarded through different public tunnels.
Fast switching of multicast traffic If the VSI in VPLS/HVPLS transmits multicast traffic and when the master TE tunnel in the public network is faulty, the TE HSB switchover is performed within 500 ms.
PWE3
Pseudo-Wire Emulation Edge to Edge (PWE3) is a technology used to carry end-to-end Layer 2 services. In the Packet Switched Network (PSN), PWE3 simulates ATM, Frame Relay (FR), Ethernet, low-speed TDM, and SONET/SDH.
l
Classifications of PW PW can be classified into:

Static PW and dynamic PW in terms of implementation Single-hop PW and multi-hop PW in terms of networking LDP-PW and RSVP-PW in terms of signaling
Control Word The CW is negotiated at the control plane, and is used for packet sequence detection, packet fragmentation, and packet reassembly at the forwarding plane. In the PWE3 protocols, ATM Adaptation Layer Type 5 (AAL5) and FR require the support for the CW. The negotiation of the CW at the control plane is simple. If the CW is supported after the negotiation, the negotiation result needs to be delivered to the forwarding module, which detects the packet sequence and reassembles the packet. The CW has the following functions:
Carries the sequence number for forwarding packets
Issue 03 (2009-03-10)
Page 93 of 200
If the control plane supports the CW, a 32-bit CW is added before the data packet to indicate the packet sequence. When the load balancing is supported, the packets may be out of sequence. The CW can be used to number the packets so that the peer can reassemble the packets.
Fills the packet to prevent the packet from being too short. For example, if Ethernet is between PEs and PPP is between PEs and CEs, the size of the PPP control packet is smaller than the smallest MTU supported by the Ethernet. Then the PPP negotiation fails. You can avoid this by adding the CW, that is, by adding the fill bit.
Carries the control information of the Layer 2 frame header. In certain cases, the frame does not need to be transmitted completely in the L2VPN packets on the network. The frame header is stripped at the ingress and added at the egress. This method, however, cannot be used if the information in the frame header needs to be carried. You can use the CW to solve this problem. The CW can carry the negotiated information between the ingress PE and the egress PE. At the control plane, the negotiation succeeds only when both ends or neither end supports the CW. At the forwarding plane, the negotiation result at the control plane determines whether the CW is added to the packet.
VCCV Ping VCCV ping is a tool that is used to manually test the connectivity of the virtual circuit. Similar to ICMP ping and LSP ping, it is realized through the extended LSP ping. The VCCV defines a series of messages transmitted between PEs to verify the connectivity of PWs. To ensure that the path of VCCV packets is consistent with the path of data packets in PWs, the encapsulation type and the passed tunnel of VCCV packets must be the same as those of PW packets. For details, refer to draft-ietf-pwe3-vccv and draft-ietf-mpls-lsp-ping. The CX600 supports the manual detection on the connectivity of LDP PWs on the U-PE, that is, the VCCV ping, including the detection on the connectivity of static PWs, dynamic PWs, single-hop PWs, and multi-hop PWs. Figure 5-26 shows the reference model of the PWE3 VCCV.
Figure 5-26 Reference model of the PWE3 VCCV

Emulate Service PW1 AC CE1 U-PE1 PW2 U-PE2 AC CE2
VCCV
The VCCV can be used as a fault detection and diagnostic tool for PWs. The VCCV can be a combination of one type of CCs and one type of connectivity verifications (CVs), because the lower layer PSNs are different, such as LSP ping, L2TPv3, or Internet Control Message Protocol (ICMP) ping.
l
PW Template A PW template is a set of public attributes abstracted from PWs. A PW template is shared by different PWs. For convenience of expansion, the command mode of
Issue 03 (2009-03-10)
Page 94 of 200
the PW template is added to set some public attributes of PWs. When creating a PW in interface mode, you can use this template. In the CX600, the PW can be bound with the PW template and can be reset.
l
Interconnectivity of heterogeneous media PWE3 can support:

Interconnectivity of homogenous media and heterogeneous media Cell relay of data with different encapsulations ATM AAL5 SDU VCC transport Ethernet HDLC ATM n-to-one VCC cell transport IP Layer 2 transport ATM one-to-one VCC cell mode
At present, the CX600 supports the following data transport by using PWE3:
l
ATM cell relay ATM cell relay is a technology to carry ATM cells on the PWE3 virtual circuit. Label encapsulation for ATM relay through PSN is shown in Figure 5-27.
Figure 5-27 Diagram of ATM relay through PSN

MPLS Label Stack PSN Transport Header MPLS PSN tunnel identified by outer label Pseudo-wire Header Control Word (sequencing & protocol info) Layer 1/2 Payload Layer 2 connection e.g ATM VCC/VPC MPLS PSN Tunnel L2 PE Pseudo-wire PE L2 Pseudo-wire identified by inner label Outer Label Inner Label
Connection or 'port' carried On pseudo-wire
A PSN label of the exterior layer identifies a PSN tunnel, while the PW header of interior layer identifies a PW. ATM cell relay is used to load the following services on a PSN:

The services whose PW payload is ATM cell The services whose PW payload is AAL5 SDU
ATM cell relay can also be used to upgrade the former ATM network through a PSN, with no new ATM devices and no change of the ATM CE configuration. ATM CE takes ATM cell relay as TDM leased line, and relays cells through a PSN for ATM interconnection.
Issue 03 (2009-03-10)
Page 95 of 200
ATM IWF
The ATM Inter-Working Function (ATM IWF) provides interoperation function between the ATM link that is accessed through 1483B and the Ethernet link. With the implementation of L2VPN, you can transparently transmit the ATM packets that are accessed through 1483B to the Ethernet link. To keep the access information of ATM (VPI and VCI accessed to a packet), VPI is mapped to be the external VLAN and VCI is mapped to be the internal VLAN. By adding two layers of VLANs to the frame header of the data link layer, the router can transmit the ATM packets with VPI/VCI information to the Ethernet link through the two VLANs. ATM IWF runs on L2VPN and has two implementation methods according to the actual networking: the CCC local connection and PW.
l
CCC local connection The CCC is implemented between sub-interfaces of ATM and Ethernet on the same router. As shown in Figure 5-28, in the CCC local connection, the CX600 cross transmits the flow that is based on 1483 encapsulation out of the ATM flow accessed from devices like DSLAM to the Ethernet link. VPI is mapped to be the external VLAN, and VCI is mapped to be the internal VLAN. Then, the packets are forwarded from the Ethernet interface to the access device such as BRAS. The BRAS distinguishes different DSLAM users based on the labels on the two-layer of VLAN of a packet.
Figure 5-28 ATM IWF diagram in the CCC local connection

CCC ATM GE
DSLAM
CX-A
BRAS
PW Through the LSP tunnel of L2VPN, layer 2 transparent transmissions of data packets of the ATM link and the Ethernet link can be carried out between peer PE routers. As shown in Figure 5-29, the ATM flow based on 1483B encapsulation can be transparently transmitted to the remote Ethernet link through PW (such as configuring Martini or Kompella L2VPN). In the process, VPI is mapped to be the external VLAN and VCI is mapped to be the internal VLAN. The ATM packets are then transparently transmitted to the remote BRAS. The BRAS distinguishes different DSLAM users based on the labels on the two-layer VLAN of a packet.
Issue 03 (2009-03-10)
Page 96 of 200
Figure 5-29 Diagram of ATM IWF in PW

CX-A PW CX-B
ATM
GE
ATM
ATM Switch
BRAS
5.5.4 BGP/MPLS IP VPN

The CX600 implements BGP/MPLS IP VPN, thus providing carriers with end-to-end VPN solutions. Carriers can provide VPN service for users as a new value-added service. A BGP/MPLS IP VPN is a type of VPN that is implemented based on the extended Border Gateway Protocol (BGP) and MPLS. A BGP/MPLS IP VPN consists of the backbone network of carriers and sites of users. The sites, as the VPN user sites, are isolated from each other and can be interconnected only through the backbone network. A VPN can be regarded as the division of sites based on policies. These policies are used to control the connections between sites. As shown in Figure 5-30, Site 1, Site 2, and Site 3 constitute VPN A, and Site 4, Site 5, and Site 6 constitute VPN B.
Issue 03 (2009-03-10)
Page 97 of 200
Figure 5-30 Networking diagram of a BGP/MPLS IP VPN
VPNA site1 CE4 PE1 CE1
VPN B site4 P1 Core layer
VPN B site5 CE5 Edge layer CPE layer CE2
P2
PE3
VPN A site3
CE3
P3 CE6
PE2 VPN A site2
VPN B site6
Table 5-1 Functions of each device in a BGP/MPLS IP VPN Device P PE Full Name Provider router Provider Edge router Custom Edge router Description It is a core router on a backbone network to implement MPLS forwarding. It is an edge router on a backbone network. It processes VPN routes and mainly implements MPLS L3VPN. It is an edge router on a user network to advertise routes of the user network.
CE
Figure 5-31 shows the networking of a BGP/MPLS IP VPN that the CX600 supports.
Issue 03 (2009-03-10)
Page 98 of 200
Figure 5-31 Networking diagram of a BGP/MPLS IP VPN

Support access to MPLS VPN through PPP, HDLC, ATM, Eth/ VLAN, and remote dial-in/tunnel access Support routing protocols between PEs and CEs, such as static routing, BGP, RIP, OSPF, and ISIS VPN1 site3
VPN2 site3 VPN1 site1 VPN2 site2 MP-BGP MPLS network VPN1 site2 VPN2 site2 PE-ASBR UPE Hierarchical PE SPE PE UPE MPLS network
PE
Support HoVPN to extend the VPN
Support inter-AS solutions: VRF-to-VRF MP-EBGP MP-Multihop EBGP
PE-ASBR Support MPLS VPN over GRE and MPLS VPN over TE tunnel
VPN3 site1
VPN3 site2
Provide the VPN manager to manage VPNs among devices of different vendors
l l l
As a PE router, it supports access of CE routers through kinds of interfaces such as Ethernet, POS, and VLAN interfaces. It supports static routes and dynamic routing protocols such as BGP, RIP, OSPF, and IS-IS, between CE routers and PE routers. It supports various inter-AS VPN solutions.
Carrier's Carrier
The customer of the BGP/MPLS IP VPN service provider can serve as a service provider, which is called the networking mode for the carrier's carrier. In this mode, the BGP/MPLS IP VPN service provider is called the provider carrier or the first carrier. The customer is called the customer carrier or the second carrier, which serves as a CE router for the first carrier. To keep good extensibility, the second carrier adopts the operating mode similar to the stub VPN. That is, the CE router of the second carrier only advertises the routes (internal routes) of the VPN where it resides to the PE router of the first carrier. The CE router does not advertise its customers' routes (external routes). PE routers of the second carrier exchange external routes through BGP. This greatly reduces the number of routes maintained on the first carrier network.
Issue 03 (2009-03-10)
Page 99 of 200
Inter-AS VPN
The CX600 supports the following three inter-AS VPN solutions represented in RFC 2547bis:
l l
VPN instance to VPN instance: ASBRs manage VPN routes in between by using sub-interfaces, which is also called Inter-Provider Backbones Option A. EBGP redistribution of labeled VPN-IPv4 routes: ASBRs advertise labeled VPN-IPv4 routes to each other through MP-EBGP, which is also called Inter-Provider Backbones Option B. Multihop EBGP redistribution of labeled VPN-IPv4 routes: PE routers advertise labeled VPN-IPv4 routes to each other through Multihop MP-EBGP, which is also called Inter-Provider Backbones Option C.
Multicast VPN
The CX600 supports multicast BGP/MPLS IP VPN. Multicast services are deployed in the network shown in Figure 5-32. VPN users in various sites receive multicast traffic from the local VPN. The PE in the public network supports multi-instance. As shown in Figure 5-32, the public network instances on each PE and the P router implement public network multicast. VPN multicast data is multicast in the public network. Figure 5-32 Networking diagram of applying public network multicast
PE1_public-instance
P1 P2
PE3_public-instance
P3
PE2_public-instance
As shown in Figure 5-33, the VPN A instances on each PE and the sites that belong to the VPN A implement VPN A multicast.
Issue 03 (2009-03-10)
Page 100 of 200
Figure 5-33 Networking diagram of applying VPN A multicast
VPNA site1 CE1
PE1_vpnA-instance
PE3_vpnA-instance
MD A
CE2
VPN A site3
CE3
PE2_vpnA-instance
VPN A site2
As shown in Figure 5-34, the VPN B instances on PEs and the sites that belong to the VPN Bs implement VPN B multicast. Figure 5-34 Networking diagram of applying VPN B multicast
CE4
PE1_vpnB-instance
VPN B site4 CE5 VPN B site5
MD B
PE2_vpnB-instance
CE6
VPN B site6
Take VPN A instances as an example. Multicast VPN can be summarized as follows:

l l
The multicast source S1 belongs to VPN A. S1 sends multicast data to G, a multicast group. Among all possible data receivers, only members of VPN A can receive multicast data from S1.
Issue 03 (2009-03-10)
Page 101 of 200

l
Multicast data is multicast in various sites and the public network.
To implement multicast VPN, the following network conditions are required:

l l l
Each site that supports multicast based on VPN instance A public network that supports the multicast based on public instance A PE device that supports the following multi-instance multicast:

Connecting sites through VPN instance to support multicast based on VPN instances Connecting the public network by using public network instances and supporting multicast based on public network instances Supporting data switching between public network instances and VPN instances
IPv6 VPN
The next-generation network protocol IPv6 is an enhancement of IPv4. IPv6 improves the address space, configuration, maintenance, and security and supports access of more users and devices to the Internet. The VPN is an extension of the private network constructed by the shared link or the public network such as the Internet. The VPN enables the computers across two areas of a client to transmit data through the shared link or the public network; thus the function of the P2P private link is realized. When each site of a VPN supports IPv6, all the sites can be connected to the PE router of the Service Provider (SP) through an interface or sub-interface with the IPv6 address. In this way, the sites are connected to the backbone network of the SP and the VPN is called an IPv6 VPN. Simply speaking, IPv6 VPN indicates that a PE router receives IPv6 packets from a CE router, which is different from the IPv4 VPN. Currently, the IPv6 VPN services are carried over the IPv4 network of the SP. In this case, the backbone network runs IPv4 while the user sites use IPv6 addresses. PE routers need to support the IPv4/IPv6 dual stack, as shown in Figure 5-35. Any network protocol that bears IPv6 traffic CE routers and PE routers can run between PE routers and CE routers. The PE routers run IPv6 on the interfaces connecting clients and IPv4 on the interfaces connecting the public network.
Issue 03 (2009-03-10)
Page 102 of 200
Figure 5-35 Networking diagram of the IPv6 VPN over the IPv4 backbone network
IPv6 VPN site2 IPv4 VPN backbone P PE P PE CE CE IPv6 VPN site2 IPv6 VPN site1 CE PE CE IPv6 VPN site1
CE IPv6 VPN site1
The implementation principle of the IPv6 VPN is similar to that of BGP/MPLS IP VPN. The IPv6 VPN advertises VPN-IPv6 routing information through Multiprotocol Extensions for BGP-4 (MP-BGP) on the backbone network. The IPv6 VPN triggers MPLS to allocate labels to identify IPv6 packets, and then transmits data of the private network across the backbone network through LSP, MPLS TE, or GRE tunnels. IPv6 VPN networking schemes that the CX600 supports are:
l l l l l
Intranet VPN Extranet VPN Hub&Spoke Inter-AS or multi-AS backbones VPN Carriers' carrier
HoVPN
In BGP/MPLS VPN solutions, the key device, PE router, functions in the following aspects:
l l
Provides access functions for users. To achieve this, a PE router needs a great number of interfaces. Manages and advertises VPN routes and processes user packets. This requires that a PE router have large-capacity memory and high forwarding capabilities.
This causes the PE to becomes a bottleneck. To solve this problem, Huawei launches the Hierarchy of VPN (HoVPN) solution. In HoVPN, functions of a PE router are distributed to multiple PEs. Playing different roles in a hierarchical architecture, the PEs implement functions of a centralized PE router together.
Issue 03 (2009-03-10)
Page 103 of 200
The basic architecture of HoVPN is shown in Figure. The device that is directly connected to users is called the Underlayer PE or User-end PE (hereafter referred to as the UPE). The device that is connected to the UPE in the internal network is called the Superstratum PE or Service Provider-end PE (hereafter referred to as the SPE). Multiple UPEs and a SPE form a hierarchical PE, functioning together as a traditional PE router. Figure 5-36 Basic architecture of HoVPN
VPN1 site
HoVPN PE VPN2 site VPN1 site
UPE1 VPN1 site UPE2
SPE
MPLS network
PE
VPN2 site
VPN2 site
In the networking of HoVPN, functions of PE routers are implemented hierarchically. Therefore, the solution is also called Hierarchy of PE (HoPE).
The UPE and SPE provide the following functions:

l
The UPE implements user access. It maintains the routes of VPN sites that are directly connected with it. It does not maintain the routes of other remote sites in the VPN, or only maintains their summary routes only. The UPE assigns interior layer labels to the routes of the directly connected sites, and advertises the labels to the SPE through VPN routes with MP-BGP. The SPE manages and advertises VPN routes. It maintains the routes of all the VPNs that are connected through UPEs, including the routes of local and remote sites. The SPE does not advertise routes of remote sites to UPEs. It advertises only the default routes of VPN-instances or summary routes to UPEs with the label.
Different roles result in different requirements for the SPE and UPE:
l l
SPE: large capacity of routing table, high forwarding performance, few interface resources UPE: small capacity of routing table, low forwarding performance, high access capacity
Issue 03 (2009-03-10)
Page 104 of 200
The HoVPN takes advantage of the performance of SPEs and access capability of UPEs. The HoPE is the same as the traditional PE in appearance. It can exist together with common PEs in an MPLS network. HoVPN supports the embedding of HoPE:
l l l
A HoPE can act as a UPE, and compose a new HoPE with another SPE. A HoPE can act as an SPE, and compose a new HoPE with multiple UPEs. Multiple embedding processes are supported.
The embedding of HoPE can infinitely extend a VPN network in theory.
RRVPN
Resource Reserved VPN (RRVPN) is a tunnel-multiplexing technology. It can provide end-to-end QoS guarantee for VPN users. To reserve and isolate resources for a VPN, RSVP-TE tunnels must be used. When RRVPN is implemented, different VPNs use different tunnels. The resources of different tunnels with the same tunnel interface, however, are isolated and reserved. Note that the total bandwidth of the tunnels must not exceed the total bandwidth reserved for the physical links.
Multi-role Hosts
In a BGP/MPLS IP VPN, the VPN attributes of the packets received by PEs from CEs are decided by the VPN instance of the incoming interfaces on the PEs. Thus, all the packets that are forwarded by the same PE interface belong to the same VPN. In practice, however, a server or terminal is generally required to access multiple VPNs. For example, a server in a financial system in VPN 1 and a server in an accounting system in VPN 2 need to communicate. The server is called a multi-role host. In a multi-role host model, only the multi-role host can access multiple VPNs; the non-multi-role hosts can access only the VPN to which the hosts belong. The implementation principle of a multi-role host is simple. A multi-role host generally fulfils the following functions:
l l
Ensures the data stream of the multi-role host can reach the destination VPN network. Ensures the data stream from the destination VPN network can reach the multi-role host.
As shown in Figure 5-37, the VPN to which the multi-role host PC belongs is VPN1. If the VPN1 routes and VPN2 routes on PE1 do not import each other, the PC can access only VPN1 instead of VPN2. The data stream from the PC to VPN2 can be transmitted only by searching the VPN1 routing table of PE1. If the destination address of a packet does not exist in the VPN1 routing table, PE1 discards the packet. To ensure that the data stream of the PC can reach VPN2, configure PBR on PE1 interfaces through which CE1 accesses PE1. After the configuration, if the destination address of a packet from CE1 does not exist in the VPN1 routing table, the VPN2
Issue 03 (2009-03-10)
Page 105 of 200
routing table is searched. The PBR here is generally based on IP addresses and can guide data streams to access different VPNs. Figure 5-37 Implementation of a multi-role host
VPN1 PC Static-Route PE2 VPN1 CE1 PE1 Policy-Based Routing PE3 VPN2 CE3 Backbone CE2
To ensure that the data streams from the destination VPN network can return to the PC, PE1 must be able to search the routes in the VPN1 routing table for the data streams from VPN2. This is implemented through injecting the static route to the PC into the VPN2 routing table on PE1. The outgoing interface of the static route is the PE1 interface that connects CE1. The functions of a multi-role host are realized mainly on the PE that the CE accesses. (The multi-role host accesses the CE.)
l l
Through the PBR on a PE, the data streams from the same VPN can be transmitted by searching routing tables of different VPNs at the same time. Static routes are installed to the routing table of the destination VPN on the PE. The outgoing interfaces of the static routes are the interfaces that connect the multi-role host and the VPN.
Note that the IP addresses of the VPN where a multi-role host resides and the VPN that the host accesses cannot be the same.
5.5.5 L2VPN Accessing L3VPN

At the border between the traditional access network and the bearer network, one UPE and one NPE are required to work together to implement the access.
l l
The UPE terminates and accesses the L2VPN (VLL and VPLS). The NPE terminates and accesses the L3VPN.
Issue 03 (2009-03-10)
Page 106 of 200
Figure 5-38 Traditional access network
DSLAM
The UPE terminates the L2VPN and accesses the L3VPN
The UPE and the NPE run as the CE for each other
The NPE accesses the L3VPN and sets up the L3VPN tunnel
DSLAM
Users access the L2VPN through ACs User Switch
UPE
UPE
NPE
NPE
UPE MPLS L2VPN
UPE
MPLS L2VPN
MPLS L3VPN
User switch UPE UPE NPE NPE UPE UPE
The UPE accesses the L2VPN and sets up the L2VPN tunnel
AC for user access Users access the L3VPN through the L2VPN L2VPN tunnel L3VPN tunnel
MPLS is widely applied on the access network of the ISP because it features high reliability and security and sound IP-based operating and maintenance capabilities, and supports QoS. MPLS L2VPN provides MPLS-based VPN services and transparently transmits Layer 2 data of users on the MPLS network. It thus provides a channelized path for user services and reduces the LSPs maintained by transit nodes. MPLS L3VPN services are a kind of common services provided by the ISP over the bearer network. MPLS L2VPN tunnels enable users to access the MPLS L3VPN of the bearer network. Users can access MPLS L3VPNs through low-end devices such as the CXs. In this manner, networking cost is reduced and secure and stable MPLS L3VPN services are provided for users. To access L3VPNs through MPLS L2VPN tunnels, two devices that are a PE-AGG and an NPE need to be deployed at the border between the access network and the bearer network. In addition, the PE-AGG is used to terminate the L2VPN and the NPE is used to terminate the L3VPN. The PE-AGG and the NPE run as the CE router for each other. In this case, if an NPE combines the capability of the PE-AGG, networking cost can be saved and networking is simplified. The VE interface, which is supported by the CX600 to access multiple services, can be bound to the L2VPN and L3VPN at the same time. That is, the VE interface can access and terminate the L2VPN and L3VPN. In this manner, the CX600 can run as the NPE and PE-AGG at the same time.
Issue 03 (2009-03-10)
Page 107 of 200
Figure 5-39 L2VPN access to the L3VPN

The UNPE terminates the L2VPN, accesses the L3VPN, and sets up the L2VPN and L3VPN tunnels DSLAM UPE DSLAM
Users access the L2VPN through the AC User Switch
UPE
UNPE
UNPE
MPLS L3VPN L2VPN L2VPN User switch UPE
UPE The UPE accesses the L2VPN and sets up the L2VPN tunnel
UNPE
UNPE
AC for user access Users access the L3VPN through the L2VPN L2VPN tunnel L3VPN tunnel
Without a dedicated board, the CX600 can associate Layer 2 with Layer 3 VE interfaces by using a VE group. The CX600 terminates the VLL and the VPLS through Layer 2 VE interfaces and accesses the L3VPN through Layer 3 VE interfaces. The UNPE function is thus implemented.
5.5.6 VPN QoS

The ISP provides L2VPN or L3VPN access services for a VPN user and signs the SLA with the user. The SLA includes the following:
l l
Total bandwidth used by the user to access the MPLS VPN Priority of the user service in the MPLS network
The preceding two points determine the volume of user traffic that can access the ISP network. After the user's access to the ISP network, a problem, to be faced with, lies in the type of QoS to be provided for the user.
l l
The bandwidth for the user traffic to a specified peer PE router is guaranteed. Types of services to a specific peer PE router, such as voice, video, important data, and common network services, require guaranteed bandwidth and delay.
VPN QoS provides a relatively complete L2VPN or L3VPN QoS solution. It resorts to various QoS features to answer the diversified and delicate QoS demands of VPN users. The VPN QoS provides QoS in the MPLS DiffServ network and end-to-end QoS in the MPLS TE network. In the application, you can select the QoS policy as required.
Issue 03 (2009-03-10)
Page 108 of 200
L3VPN with QPPB

The Qos Policy Propagation Through the Border Gateway Protocol (QPPB) propagates the QoS policy through BGP. The receiver of BGP routes can do as follows:
l l l
Sets QoS parameters for BGP routes based on the attributes of BGP routes. Classifies traffic by matching QoS parameters and sets the QoS policy for the classified traffic. Forwards packets in accordance with the locally-set QoS policy to propagate the QoS policy through BGP.
In an L3VPN, you can set the QPPB policy for private routes to classify L3VPN traffic, re-mark the traffic class, and limit the traffic volume.
L2VPN/L3VPN with MPLS DiffServ

In this case, VPN QoS has the following functions:
l
On the ingress PE router, VPN QoS classifies VPN traffic according to simple traffic classification or complex traffic classification. The classified traffic is limited, re-marked, and scheduled based on the priority level. Traffic classification and scheduling support uniform and pipe/short pipe modes. VPN QoS performs differentiated queue scheduling according to the MPLS EXP field on the P router. On the egress PE router, VPN QoS performs differentiated queue scheduling based on the EXP field and limit and shape traffic on the outbound interface.
l l
The inherent defect lies in this scheme. That is, the transit nodes perform the QoS action only according to the predefined PHB. This fails to guarantee the end-to-end QoS and eradicate network congestion.
L2VPN/L3VPN with MPLS TE

The characteristic of this solution is that the P and PE routers on the MPLS network reserve bandwidth through the TE signaling protocol. In this manner, the network is free from blocking, providing end-to-end bandwidth guarantee. But the P routers do not distinguish service marks inside the tunnel and uniformly process the packets of various marks. QoS mapping between MPLS packets and IP packets or Layer 2 packets on the PE router supports the pipe/short pipe model. In this solution, the ingress PE router binds the VPN to a TE tunnel.
l
At the network side, the PE router performs queue scheduling based on VPNs, ensures the bandwidth of VPN services to access the TE tunnel, and guarantees the total bandwidth of the TE tunnel. The P router guarantees the bandwidth of the TE tunnel.
The ingress nodes do not distinguish the priorities of services transmitted on the TE tunnel. Therefore, services of various priority levels need to be allocated to different VPNs in the network planning.
Issue 03 (2009-03-10)
Page 109 of 200
Figure 5-40 L2VPN/L3VPN with MPLS TE
Backbone network
PE2
VPNA site 3
PE1
VPNA site 1
PE3
VPNA site 2 Only one type of services in VPNA
L2VPN/L3VPN with MPLS DS-TE

The characteristic of this scheme is that the P router and PE routers on the MPLS network reserve bandwidth through the DS-TE signaling protocol for various types of services. In this manner, the network is free from blocking, providing end-to-end bandwidth guarantee. Besides, services inside the tunnel are differentiated. In this scheme, the ingress PE router binds the VPN to the DS-TE tunnel. At the network side, the PE router schedules queues based on VPNs, ensures the bandwidth of the VPN services to access the DS-TE tunnel, and ensures the total bandwidth of the DS-TE tunnel. The P router guarantees the bandwidth of the DS-TE tunnel.
Issue 03 (2009-03-10)
Page 110 of 200
Figure 5-41 L2VPN/L3VPN with MPLS DS-TE
Backbone network
VPNA site 3 PE2
PE1
VPNA site 1
PE3
VPNA site 2 VPNA carries three types of services, ensuring the QoS for each service in the same VPN
5.6 IPTN Features

How to provide services with end-to-end QoS guarantee on an IP bearer network has become an urgent demand for carriers. Therefore, the current Internet needs to be reconstructed in order to provide better data services. Huawei puts forward the IP telecommunication network (IPTN) solution to meet the demand. The IPTN solution aims to provide end-to-end QoS by reconstructing the current IP network. In this solution, the concept of bearer control layer is addressed between the service control layer and the bearer layer; resources are applied, kept and released respectively before, during, and after they are used to improve the transmission efficiency of the bearer network. Figure 5-42 shows the scenario in which the CX600 serves as a service router (SR) in an IPTN network.
Issue 03 (2009-03-10)
Page 111 of 200
Figure 5-42 Application scenario of the IPTN

COPS
SR ISP DSLAM
User
DHCP Server
An IP packet of the user is encapsulated in a QinQ packet with double VLAN tags through the DSLAM and then accesses the SR. The outer VLAN ID specifies the DSLAM; the inner VLAN ID specifies the user. With the DHCP relay function, the SR forwards a DHCP request packet to the DHCP server when receiving an access request from the user. After the DHCP server returns an assigned IP address to the user, the SR reports information about the online user to the COPS server. The information includes the following:
l l l l
Location of the user, that is, CircuitId in the DHCP Option 82 field VPN to which the user belongs IP address of the user MAC address of the user
In addition, the CX600 provides the following functions:

l l l l
Supports the three-level limit to the number of users. Provides the detection of online users and the processing of the user getting offline. Checks the validity of IPTN users. Displays information about online users and forcibly cuts off online users.
5.7 QoS Features

The CX600 provides the QoS features of integrated services including real-time services. In particular, the CX600 supports DiffServ as follows:
l l l l l
Traffic classification Traffic policing Traffic shaping Congestion management Queue scheduling
Issue 03 (2009-03-10)
Page 112 of 200
The CX600 can implement all the eight PHB behaviors of Expedited Forwarding (EF), Assured Forwarding 1 (AF1), AF2, AF3, AF4, Best-Effort (BE), Class Selector 6 (CS6), and CS7. With the CX600, network operators can provide users with differentiated QoS guarantee, and make the Internet an integrated network that can carry data, voice, and video services at the same time. Figure 5-43 shows the hierarchical QoS (HQoS) of the CX600. Figure 5-43 Multi-level scheduling of QoS
Inbound interface L1 L2 CAR L3 L4 Receive packets Classify and mark packets RED WRED
Outbound interface
Congestion Priority avoidance scheduling PQ detection CQ CBWFQ ...... ......
RED WRED SARED
L1 L2 L3 L4
...... VOQ switch Prevent the head packet from blocking multicast switch
......
......
Forward packets
Priority Schedule scheduling/ traffic traffic LLS shaping NLS PQ PBS CBWFQ
Mark Congestion avoidance packets detection according to the class
The following describes the QoS features of the CX600.
5.7.1 DiffServ Model

In the DiffServ model, service traffic is classified into different classes that can be processed differently. When the network is congested, different classes of traffic are processed with different priorities. This results in different packet loss ratio, delay, and jitter. In the DiffServ model, the following nodes can service as the edge nodes when DiffServ is implemented:
l l l
Nodes at the convergence layer Nodes at the core layer to directly connect the Internet Data Center (IDC) Gateway nodes at the core layer
Other nodes at the core layer serve as the core nodes.
Issue 03 (2009-03-10)
Page 113 of 200

l
On the ingress edge node, the router classifies traffic based on Multi-field (MF) and then performs traffic policing, Differentiated Services Code Point (DSCP) mark or re-mark, queue scheduling and management, and traffic shaping based on user traffic. On the egress edge node, the router performs traffic classification, DSCP re-mark or ToS mark, traffic shaping, queue scheduling and management based on DSCP. If the downstream domain is a DiffServ domain, service traffic may be re-marked with the DSCP priority based on the SLA signed between the provider and customers. If the downstream domain is a CoS domain, service traffic should be marked with a ToS flag. The traffic shaping performed on the egress allows the traffic sent to the downstream domain to enjoy the bandwidth and CBS conforming to the SLA. The SLA is an agreement reached between the service subscriber and service provider. The service provider provides services for service subscribers. The SLA contains the parameters such as the Committed Information Rate (CIR), Peak Information Rate (PIR), Committed Burst Size (CBS), and Peak Burst Size (PBS) to monitor and control the incoming traffic. The router performs such behaviors as Pass, Drop, or Markdown for the traffic exceeding the promised limit. Markdown means that packets are marked with high drop priority. Markdown packets are first dropped when network congestion occurs. This ensures that the packets conforming to the SLA can enjoy the services specified in the SLA.
On the core node, the router performs traffic classification, queue scheduling and management based on DSCP.
5.7.2 Traffic Classification

raffic classification consists of the following steps:
l l l
Classifies the traffic based on certain rules. Associates the traffic of the same type with certain actions. Forms a certain policy.
Then, the policy is applied in the implementation of traffic policing, traffic shaping, and congestion management, all of which are based on classes of the traffic. In the following situations, the packets are processed by best effort delivery:
l l l
No QoS needs to be ensured. No traffic classification is carried out. No rules in the traffic classification are matched by the packets.
The CX600 supports simple and complex traffic classifications. Complex traffic classification is usually configured on the router at the network edge; simple traffic classification is configured on the core router.
Simple Traffic Classification

Simple traffic classification means that packets are divided into several priorities or service classes according to the IP precedence or DSCP field value in IP packets, EXP field value in MPLS packets, or 802.1p priority in VLAN packets. Traffic policies based on simple traffic classification are used to map the priority of traffic on one type of network to another type. This allows traffic to be transmitted in another network based on the previous priority.
Issue 03 (2009-03-10)
Page 114 of 200
At present, the CX600 supports traffic classification on the following interfaces:

l l
Physical interfaces and sub-interfaces Logical interfaces including VLANIF, Ring-If, and trunk interfaces
Complex Traffic Classification

Complex traffic classification means that packets are classified based on the quintuple of the source and destination addresses, source and destination port numbers, and protocol type. It is usually applied on the edge of a network. Complex traffic classification must be associated with specific traffic control or resource allocation actions. Thus, it can provide differentiated services. At present, the CX600 supports:
l
Classifications based on the source MAC address and destination MAC address in the Ethernet frame header, protocol number carried over the link layer, and 802.1p priority of tagged packets Classifications based on the IP precedence, DSCP, or ToS value of IPv4 packets, source IP address prefix, destination IP address prefix, protocol number carried in IP packets, fragmentation flag, TCP SYN flag, TCP/UDP source port number or range, and TCP/UDP destination port number or range.
The CX600 supports complex traffic classification on:

l l
Physical interfaces Logical interfaces including sub-interfaces, Ring-If interfaces, and trunk interfaces
5.7.3 Traffic Policing

In traffic policing, the committed access rate (CAR) is used to control traffic. Packets are classified according to a preset matching rule. If conforming to the rule, the packets are forwarded by the router. If exceeding the limit specified by the rule, the packets are then either discarded or forward after their precedence is re-marked. To control traffic, the token bucket (TB) is introduced to the CAR technology. Figure 5-44 shows the procedure of traffic policing with CAR. Figure 5-44 Flowchart of traffic policing with CAR
...
Filling the bucket with tokens at a specified rate Tokens
Classifying Incoming packets
Outgoing packets Passed Token bucket
Dropped
Issue 03 (2009-03-10)
Page 115 of 200

l
The tokens are put into the TB at the rate preset by the user. The capacity of the TB is also preset by users. When the number of tokens reaches the capacity of the TB, the number does not increase any more. On arrival, the packets are classified according to the information such as the IP precedence, source address, or destination address. The packets that conform to the preset feature go into the TB for further processing. If the TB has enough tokens for sending packets, packets are forwarded. Meanwhile, the number of tokens is reduced by the packet length. If the TB contains insufficient tokens or is empty, the packets that are not assigned with tokens or not assigned with enough tokens are discarded; or the information about the IP precedence, DSCP, or EXP values are re-marked and the packets are forward. At this time, the number of tokens in the TB remains unchanged.
The preceding process shows that the CAR technology enables a router to control traffic, and to mark or re-mark packets. To limit the traffic rate is the main function of CAR. With the CAR technology, a TB is used to measure the data traffic that flows through the interfaces of a router so that in the specified time only the packets that are assigned with tokens go through the router. In this way, the traffic rate is limited. CAR limits the maximum traffic rates of both incoming packets at the ingress and outgoing packets at the egress. Meanwhile, the rate of certain types of traffic can be controlled according to such information as the IP address, port number, and precedence. These characteristics include the IP address, port number, and precedence. The traffic not conforming to the present conditions is not limited in rate; such traffic is forwarded at the original rate. The CAR technology is used at the network edge to ensure that the core device can process data normally. The CX600 supports CAR in both the inbound and outbound directions.
5.7.4 Queue Scheduling

In computerized data communications, communication channels are shared by many computers. In addition, the bandwidth of a WAN is usually less than that of a Local Area Network (LAN). As a result, when a computer in one LAN sends data to a computer in another LAN, data cannot be transmitted over a WAN as fast as over a LAN because the WAN bottlenecks the data transmission. At this time, some packets cannot be sent by the router between the LAN and the WAN, that is, the network is congested. As shown in Figure 5-45, when LAN 1 sends packets to LAN 2 at the rate of 10 Mbit/s, traffic congestion occurs on the interface Serial 1 of CX-A.
Issue 03 (2009-03-10)
Page 116 of 200
Figure 5-45 Network congestion

Frame Relay/X.25/DDN CX-B Serial 1 PC2
2 Mbit/s PC1 Serial 1 10 Mbit/s
Ethernet
CX-A Ethernet 10 Mbit/s LAN 1
LAN 2 Server2
Server1
Congestion management provides means to manage and control traffic when traffic congestion occurs. The queue scheduling technology is used to handle traffic congestion. Packets sent from one interface are placed into many queues which are identified with different priorities. Packets are then sent according to the priorities. A proper queue scheduling mechanism can provide packets of different types with reasonable QoS features such as the bandwidth, latency, and jitter. The queue here refers to the outgoing packet queue. Packets are buffered into queues before the interface is able to send them. Therefore, the queue scheduling mechanism works only when an outbound interface is congested. The queue scheduling mechanism can re-arrange the order of packets except those in First In First Out (FIFO) queues. Commonly used queue scheduling mechanisms are:
l l l l l
FIFO PQ Custom Queuing (CQ) WFQ Class-based WFQ (CBWFQ)
The CX600 supports FIFO, PQ, and WFQ to realize the queue scheduling on the interface.
5.7.5 Congestion Management

The CX600 adopts the Weighted Random Early Detection (WRED) congestion control mechanism.
l l l
The congestion control mechanism can be configured on each port based on the priority of the queue. The CX600 uses a microsecond-level timer to trace the occupation of the shared memory with the first-order weighted iteration method. Consequently, the CX600 can sense the congestion in a timely manner and avoid network flapping. It drops the packets of different drop preferences at different
Issue 03 (2009-03-10)
Page 117 of 200
probabilities within the same traffic stream. This can effectively avoid and control network congestion.
5.7.6 Traffic Shaping

When the network congestion occurs, the traffic policing (CAR technology) is used to control the traffic features of the packets and restrain the traffic, so that the packets that do not conform to the traffic features are dropped. Sometimes, to decrease the lost packets, the packets that do not conform to the traffic specifications are cached and then sent at a uniform rate under the control of the token bucket. This is traffic shaping. Traffic shaping both decreases the lost packets and satisfies the traffic features of the packets. A typical application of traffic shaping is to control the flow and burst of outgoing traffic based on the network connection. Thus, the packets can be sent at a uniform rate. The traffic shaping adopts the Generic Traffic Shaping (GTS) to shape the traffic that is irregular or does not conform to the preset traffic features, which is convenient for the bandwidth match between the network upstream and downstream.
5.7.7 HQoS
Hierarchical QoS (HQoS) is a kind of QoS technology that can control user traffic and schedule service queues according to the priority level. The HQoS of the CX600 has the following functions:
l l
The system provides abundant services with the five-level QoS scheduling mechanism. The system supports PQ and Confirmed Bandwidth Priority Queue (CBPQ).
PQ is based on the absolute priority level. After you configure PQ, the packets with the highest priority level are permitted; the packets with low priority levels are discarded, once the network is congested. PQ is unable to configure bandwidth for packets of all priority levels. CBPQ is based on bandwidth guarantee. CBPQ makes full use of bandwidth resources in the case of bandwidth guarantee.
The system supports the configuration of the parameters of a queue, such as the maximum queue length, WRED, low delay, SP/WRR weight, committed burst size (CBS), PBS, and statistics enabling. The system supports the configuration of parameters such as the CIR, PIR, number of queues, and scheduling algorithms between queues for each user. The system supports traffic statistics. It enables carriers to view the status of bandwidth use of each service. The users can thus analyze traffic and properly allocate bandwidth for services. The system supports the HQoS of VPLS, L3VPN, VLL, and TE.
l l
5.7.8 QPPB
QoS policy propagation through the Border Gateway Protocol (QPPB) is a kind of technology to propagate the QoS policy through BGP. On the BGP receiver, you can:
l
Set QoS parameters for BGP routes, such as IP precedence and traffic behavior, based on the attributes of the route.
Issue 03 (2009-03-10)
Page 118 of 200

l l
Set the receiver to classify traffic based on QoS parameters, and set a QoS policy for the classified traffic. Set the receiver to forward packets based on the QoS policy to realize QPPB.
On the BGP receiver, you can set QoS parameters, such as IP precedence and traffic behavior, according to the following attributes of BGP routes:
l l l l l
ACL AS path list Community attribute list Route cost Address prefix list
Figure 5-46 QPPB
Configure a QoS policy
Advertise routing information AS200 Packets filtered by the QoS policy
AS100
In the complex network environment, the policy for route classification needs to be changed from time to time. QPPB can simplify the change of the policy on the BGP receiver. Using QPPB, you can change the routing policy on the BGP receiver by changing that on the BGP sender.
5.7.9 Ethernet QoS

L2 Simple Traffic Classification
The CX600 supports simple traffic classification in accordance with the 802.1p value in VLAN packets. On the ingress PE router, the 802.1p value in a Layer 2 packet can be mapped to the precedence field of the upper layer protocol such as the IP DSCP value or the MPLS EXP value. In this manner, the DiffServ is provided for the packet in the backbone network. On the egress PE router, the precedence field of the upper layer protocol is mapped back to the 802.1p value to keep the original Ethernet precedence.
QinQ Simple Traffic Classification

After QinQ encapsulation, the 802.1p priority in the inner VLAN tag cannot be sensed. The system adds an outer VLAN tag rather than sense the 802.1p priority in the inner VLAN tag after QinQ encapsulation. The classes of services are thus not distinguishd.
Issue 03 (2009-03-10)
Page 119 of 200
In the process of QinQ implementation, the 802.1p value in the inner VLAN tag needs to be sensed. You can set the following rules through commands o sense the 802.1p value:
l l l
Ignore the 802.1p value in the inner VLAN tag and set a new 802.1p value in the outer VLAN tag. Automatically set the 802.1p value in the inner VLAN tag as the 802.1p value in the outer VLAN tag. Set the 802.1p value in the outer VLAN tag according to the 802.1p value in the inner VLAN tag.
As shown in Figure 5-47, QinQ supports 802.1p remark in the following three modes:
l l l
Setting a value (Pipe mode). Using the 802.1p value in the inner VLAN tag (Uniform mode). Mapping the 802.1p priority in the inner VLAN tag to a value in the outer VLAN tag. Multiple values in multiple inner VLAN tags can be mapped to the same value in the outer VLAN tag, but a value in an inner VLAN tag cannot be mapped to values in multiple outer VLAN tags.
Figure 5-47 Typical networking diagram of 802.1p Remark supported by QinQ

Q-in-Q Supports 802.1p Remark
ISP Network
CE PE
5.7.10 ATM QoS

At the edge of the ATM network, the router is responsible for access to the IP network. Data is encapsulated in AAL5 frames such as IPoA and IPoEoA. Such frames are decapsulated by the router and are forwarded to other types of interfaces, or are forwarded to the Ethernet interface as Layer 2 Ethernet frames. The IP network and the ATM network communicate through the IPoA technology. IPoA, however, cannot effectively use all ATM functions. In addition, the scalability of ATM applications is limited because of the use of the fully connected PVCs. As a result, the IP network with Ethernet interfaces over 10 Gbit/s cannot communicate with the ATM network; otherwise, traffic congestion may occur and QoS cannot be ensured. Threfore, to ensure proper traffic planning and traffic policing for the interconnection between the IP backbone network and the ATM backbone network, ATM QoS is introduced. The ATM network possesses the QoS capability. With the transition from the ATM network to the IP/MPLS network, the QoS capability of the ATM network needs to be kept. ATM QoS enables ATM cells with higher precedence to transfer with the same precedence in the IP network. Similarly, it enables IP packets with higher precedence to transfer with the same precedence in the ATM network.
Issue 03 (2009-03-10)
Page 120 of 200
Simple ATM Traffic Classification

When the ATM network is taken as the bearer layer of the IP network, however, the QoS mechanisms of the ATM network and the IP network must be combined to obtain end-to-end QoS. By enabling ATM simple traffic classification on the interface, PVC, or PVP, you can map the CoS and the CLP value to the internal priority of the router for upstream ATM cells, and map the internal priority to the CoS and CLP value for downstream ATM cells. Thus, various QoS services can be transmitted in different ATM networks. ATM simple traffic classification supports:
l l l
ATM transparent cell transport 1483R 1483B
The 1483R protocol is used to encapsulate IP packets to carry out IPoA service. The 1483B protocol is used to encapsulate Ethernet packets to carry out IPoEoA service.
Forced ATM Traffic Classification

Although ATM cells in the ATM network hold information about precedence, it is very difficult to carry out IPoA, transparent cell transport, and IWF simple traffic classification based on the precedence information. You can adopt forced traffic classification on the upstream interface. That is, you can use command lines to set the precedence and color manually for a specific PVC, interface (including the sub-interface), or PVP, and carry information about the precedence and color to the downstream interface. As shown in Figure 5-48, on the upstream ATM interface of Router A, the precedence and color for a specific flow can be set through command lines. Then the downstream interface can carry out ATM QoS based on the value of the set precedence and color. Figure 5-48 Forced ATM traffic classification
The downstream ATM interface specifies the outgoing queue for the flow according to the precedence and color of the flow
Set the packet precedence and mark the packet on the upstream ATM interface
BE
AF1 ... EF CX-A CS6 CX-B CS7
Issue 03 (2009-03-10)
Page 121 of 200
ATM physical interfaces, ATM sub-interfaces, ATM PVCs, and ATM PVPs all support forcible traffic classification.
5.7.11 FR QoS
FR has its own QoS that can be configured with PVCs to provide flexible services for customers.
FRTS
Frame Relay Traffic Shaping (FRTS) is used on the outbound interface of the router to limit the ratio of the packet sent from the VC.
FRTP
Frame Relay Traffic Policing (FRTP) is used on the inbound interface of the router to monitor traffic received from the VC. If the traffic exceeds the specific value, the packets are discarded. FRTP can be used only on the Data Circuit-terminating Equipment (DCE) interface to monitor traffic from the Data Terminal Equipment (DTE).
FR Congestion Management
The FR packet includes bits used for congestion management:
l
Forward Explicit Congestion Notification (FECN) If it is 1, congestion occurs on the forwarding direction. Backward Explicit Congestion Notification (BECN) If it is 1, congestion occurs on the backward direction. If no backward packet is forwarded during a period, the router automatically sends Q.922A Test Response whose BECN tag is 1 to the DTE.
DE It specifies whether to discard the packet or not. If it is 1, the packet is discarded in the case of congestion.
Figure 5-49 Diagram of FR congestion management

Data direction BECN DTE NNI FECN Frame Relay Network
DCE
CX-A
CX-B
The system determines congestion based on the proportion of the current queue length of the FR interface or the VC to the total length of the interface or the queue. If the proportion exceeds the threshold, it is taken that congestion occurs. The packets whose DE is 1 are discarded; otherwise, the FECN and BECN are set to 1.
Issue 03 (2009-03-10)
Page 122 of 200
You can set the congestion threshold in the following two ways:
l l
Set the congestion threshold of the interface in the interface view. Set the congestion threshold of the FR VC in the FR class view.
FR Queue Management
Normally, an FR interface has a queue while an FR VC has no queue. When the FR interface is enabled with FR traffic shaping, all the VCs on the interface have their own queues and the packets sent on the VC join in the queue first. Figure 5-50 shows the relationship between the VC queue and the interface queue. Figure 5-50 Diagram of FR queues
Virtual circuit queues Interface queue
The FR interface supports the following queues:

l l l l l l l
First In First Out (FIFO) Queuing Priority Queuing (PQ) Custom Queuing (CQ) Weighted Fair Queuing (WFQ) Class-Based Queuing (CBQ) Realtime Transport Protocol Priority Queuing (RTPQ) PVC Interface Priority Queuing (PVC PQ)
FR Fragmentation
In the process of transmitting voice with data, a large packet takes up the bandwidth for a long period. As a result, the voice packet may be delayed or discarded and voice quality is degraded. FR fragmentation is used to shorten the delay to ensure the real-time voice. After FR fragmentation configuration, a large data packet is disassembled into fragments and the voice packet and the fragments can be transmitted alternately. In this way, the voice packet can be processed on time and delay is shortened.
5.8 Load Balancing

In a scenario where there are multiple equal-cost routes to a same destination, the CX600 can perform load balancing on traffic among these routes. The CX600 provides equal-cost load balancing and unequal-cost load balancing, which can be selected as required. In equal-cost load balancing mode, traffic is evenly balanced
Issue 03 (2009-03-10)
Page 123 of 200
among different routes. In unequal-cost load balancing mode, traffic is balanced among different routes based on the proportion of bandwidth of each interface.
5.8.1 Equal-Cost Load Balancing

The CX600 can implement even load balancing on the traffic transmitted through the member links of an IP-Trunk or an Eth-Trunk. When there are multiple equal-cost routes to a same destination, the CX600 can implement balanced load balancing on traffic among these routes. The load balancing mode can be either session-by-session load balancing or packet-by-packet load balancing. By default, the session-by-session load balancing is adopted. The packet-by-packet load balancing can be configured as required.
5.8.2 Unequal-Cost Load Balancing

The CX600 supports the following unequal-cost load balancing modes:
l l l
Load balancing based on routes: When the costs of different direct routes are the same, you can configure a weight for each route for load balancing. Load balancing based on interfaces: For an IP-Trunk or an Eth-Trunk, you can configure a weight for each member link for load balancing. Load balancing based on link bandwidth for IGP: In this mode, unequal-cost session-by-session load balancing is performed on the outbound interfaces of paths. The proportion of traffic transmitted along each path is approximate to or equal to the proportion of bandwidth of each link. This mode fully considers the link bandwidth. In this manner, the case when links with low bandwidth are overloaded whereas links with high bandwidth are idle does not exist.
The CX600 can balance traffic between physical interfaces or between physical interfaces and logical interfaces. In addition, the system can sense the changes of bandwidth of logical interfaces due to manual configuration or the status changes of member links. When the bandwidth of logical interfaces changes, traffic is automatically balanced based on the new bandwidth proportion.
5.9 Traffic Statistics

The CX600 provides types of traffic statistics functions. It can collect statistics on access traffic of different users. Traffic statistics have the following functions:
l l l
Helping carriers to analyze the traffic model of the network Providing reference data for carriers to deploy and maintain DiffServ TE Supporting traffic-based accounting for the users that are not monthly-free
5.9.1 URPF Traffic Statistics

The CX600 collects statistics either on the overall traffic that complies with URPF or on the discarded traffic that does not comply with URPF.
Issue 03 (2009-03-10)
Page 124 of 200
Figure 5-51 URPF traffic statistics

Packets Statistics
Classifier
The default action for unmatched packets is Pass
Packets that match rules Statistics
Perform the action
Allow the packets complying with URPF to pass through
Discard the packets without complying with URPF Statistics
5.9.2 ACL Traffic Statistics

The CX600 supports the ACL traffic statistics function. When the created ACLs are applied to QoS and policy-based routing, the CX600 can collect statistics based on ACLs after the ACL traffic statistics function is enabled. The system also provides commands to query the number of matched ACL rules and bytes.
5.9.3 CAR Traffic Statistics

The CX600 provides numerous QoS features such as traffic classification, traffic policing CAR, and queue scheduling. Directed at these QoS features, the CX600 provides the relevant QoS traffic statistics function.
l
In traffic classification, the system can collect statistics on the traffic that matches rules and fails to match rules.
Issue 03 (2009-03-10)
Page 125 of 200
Figure 5-52 Traffic statistics in traffic classification

Packets Statistics
Classifier The default action for unmatched packets is Pass Packets that match rules Statistics Filter, CAR, mirror, redirect, re-mark, sample, URPF, TTL check
Perform the action
In traffic policing, the system supports statistics on the following traffic:

Total traffic that matches the CAR rule. Traffic that is permitted or discarded by the CAR rule.
Figure 5-53 CAR traffic statistics

Packets Statistics Allow the packets marked green to pass through
Bucket C Tokens in bucket C are not enough
Tokens in bucket C are enough
Statistics
Process packets according to the color marked
Re-mark the packets marked yellow
Bucket E Tokens in bucket E are not enough
Tokens in bucket E are enough Statistics
Discard the packets marked red
Tokens in bucket E are not enough
The system supports interface-based traffic statistics.
Issue 03 (2009-03-10)
Page 126 of 200

l
When the same traffic policy is applied on various interfaces, the CAR traffic statistics in the traffic policy is based on the interface.
5.9.4 HQoS Traffic Statistics

The system supports the following statistics on traffic queues:
l l l
Statistics on the number of forwarded packets, bytes, and discarded packets of the queues of eight priority levels Statistics on the number of forwarded packets, bytes, and discarded packets of the user group queue Statistics on the number of forwarded packets, bytes, and discarded packets of eight class queues on an interface
5.9.5 Interface-based Traffic Statistics

The system supports traffic statistics on an interface or a sub-interface.
5.9.6 VPN Traffic Statistics

The CX600 supports the following VPN statistics:
l l
In a VPLS network, the CX600 can collect statistics on incoming and outgoing traffic of the access L2VPN user when it runs as a PE router. In an L3VPN, the CX600 can collect statistics on incoming and outgoing traffic of access users of various types when it runs as a PE router. The access users include:

Users that access the network through interfaces including logical interfaces Multi-role hosts Users that access the network through the VPLS/VLL
5.9.7 TE Tunnel Traffic Statistics

When the CX600 runs as a PE router in the MPLS TE network, it supports statistics on incoming and outgoing traffic of the tunnel. When the VPN is statically bound to the TE tunnel, the system can collect statistics on traffic of each resource-isolated VPN over the TE tunnel and the total traffic over the TE tunnel. DS-TE supports the traffic statistics about each CT in a tunnel.
5.10 IP Compression
In the NGN bearer network, some carriers lack transmission resources. The RTP/UDP/IP packet header, however, contains about 40 bytes in the IP NGN service. For voice compression algorithms that work well, the voice data in each packet occupies less than 30 bytes. In this case, the packet header costs much, with low transmission efficiency. The CX600 provides types of compression algorithms. The transmission efficiency of the network can thus be improved and the lack of transmission resources can be solved.
Issue 03 (2009-03-10)
Page 127 of 200
CRTP
The Compressed Real-Time Protocol (CRTP) defined in RFC 2508 can compress the 40 byte RTP header including the UDP and IP headers into a header of 24 bytes. In this manner, the lack of transmission resources is solved. In the traditional network, voice over IP is supported through RTP, as shown in Figure 5-54. Figure 5-54 Format of RTP packets
8 bytes PPP 20 bytes IP 8 bytes UDP 12 bytes RTP 15-30 bytes Voice data
Header encapsulation
In the figure given above, the voice data occupies tens of bytes; the IP, UDP, and RTP headers contain more than 40 bytes. In a session, half bytes of the header, such as the source and destination IP addresses and the source and destination port numbers, remain unchanged. Besides, the length field in the IP/UDP header is unnecessary because the length can be obtained by calculating the length of the link layer header. Differential coding can be performed although some fields change. After these redundant fields are compressed, only 2-4 bytes need to be reserved (normally, two bytes are kept; four bytes contain the UDP checksum), as shown in Figure 5-55. Figure 5-55 Format of cRTP packets
8 bytes PPP 2-4 bytes cRTP 15-30 bytes Voice data
Header encapsulation
ECRTP
ECRTP is short for Enhanced Compression Real-Time Transport Protocol. CRTP has to send FULL_HEADER packets frequently over the links with high ratio of packet loss, packet disordering, and long delays. This greatly affects the efficiency of compression. RFC3545 defines ECRTP to strengthen the CRTP functions and reduce the impact of link quality on the efficiency of compression. ECRTP changes the mode in which the compressor requests the decompressor to update the context. In this manner, CRTP becomes more adaptable to the changes in link quality in the following aspects: The compressor regularly sends extended COMPRESSED_UDP packets to update the context of the decompressor, so the context of the two ends can be synchronized. The format of the packet is extended to carry more information about the changes in the header.
Issue 03 (2009-03-10)
Page 128 of 200
If no UDP checksum is carried, the field of CRTP head checksum is added. According to the CRTP head checksum, the decompressor determines whether errors occur during decompression and makes a second try. This can reduce the packets lost owing to the asynchronous state between two ends. The compressor sends N+1 synchronization packets continuously. In this manner, if a synchronization packet is lost, the context of two ends can remain synchronous. The value of N can be determined according to the link quality. CRTP applies to reliable point-to-point links with short delays. ECRTP applies to low-rate links of poor quality with long delays, high ratio of packet ratio, and packet disordering. ECRTP is recommended for MPLS networks.
5.11 MSE Features

As a services router, the CX600 provides the Multi Service Edge (MSE) feature to implement access management and control over DHCP, IPOE, or dedicated line users. MSE supports dynamic user access, user management, user-based authentication and accounting, and user-based QoS. Meanwhile, MSE provides the BOD service for enterprise users and DHCP users.
AAA
AAA is short for Authentication, Authorization, and Accounting. AAA provides authentication, authorization, and accounting, which are performed in a domain. AAA supports the following authentication modes:
l l l
Non-authentication Local authentication Remote Authentication Dial-In User Service (RADIUS) In this mode, access users are authenticated by the RADIUS server. The RADIUS server can work in active/standby mode.
Huawei Terminal Access Controller Access Control System (HWTACACS) In this mode, access users are authenticated by the HWTACACS server.
AAA supports the following authorization modes:

l l l l
Direct authorization: completely trusts users and directly authorizes them to pass through. Local authorization: authorizes users according to the configured attributes of user accounts. HWTACACS authorization: authorizes users through the HWTACACS server. If-authenticated authorization: authorizes users to pass through if they pass the authentication and the authentication mode is not non-authentication.
AAA supports the following accounting modes:

l l
Non-accounting: provides free services. Remote accounting: supports remote accounting through the RADIUS server or the HWTACACS server.
Issue 03 (2009-03-10)
Page 129 of 200
AAA supports prepaid services based on duration, traffic, or the combination of duration and traffic. In addition, when the transmission of accounting stop packets fails, AAA can generate an offline bill based on the accounting information and save the offline bill to the local device. If the accounting to be copied to the RADIUS server is configured in the domain, the accounting information is copied to the server after the accounting packets are sent.
Web Authentication Server

The CX600 provides the web authentication server, that is, the external web server. The CX600 transparently transmits the response message from the RADIUS server to the web authentication server. The CX600 allows setting the Portal version number that is used when the CX600 communicates with the web server. By default, the Portal version number is V2.0. In the Web authentication , after a user is successfully connected to the CX600 and assigned an IP address,It is not authorized to access the Internet before passing the authentication on a Web page.
DHCP Users, Dedicated Line Users

The CX600 supports the access of DHCP users and Layer 2/Layer 3/Layer 2 VPN dedicated line users. Ethernet sub-interfaces, GE sub-interfaces, and Eth-Trunk sub-interfaces can be configured as access interfaces to access users. For DHCP users, the CX600 supports the DHCP relay mode and the DHCP server mode. Users can be assigned addresses through the address pool on the local device or through the DHCP server. The DHCP relay agent supports user access through triggering. The CX600 can allocate QoS resources and implement accounting for users connected through access interfaces in host, location, or CE-VLAN mode. The CX600 also allows configuring the maximum number of users on interfaces. The CX600 can restrict the number of access users. The CX600 can also enable or disable the traffic statistics function for the downstream or upstream traffic of domain users. The CX600 can record the online or offline failures of users and support the record query according to the domain name, access location, MAC address, slot number, user type, or user name. The CX600 also supports the record query according to the user type, access location, user name, or any combination of them.
Static User
Static users refer to the users whose IP addresses, login interfaces, VLAN IDs, VPN instances, or MAC addresses are specified by the system. Static users' IP addresses are permanent instead of being allocated through DHCP. The CX600 supports a maximum of 1024 static users.
User Login Triggered by ARP or IP Packets

When the link between a user and the CX600 is faulty but the user cannot sense the fault, the CX600 sends the ARP request packet to the user to detect whether the user
Issue 03 (2009-03-10)
Page 130 of 200
is online. If users have gone offline, the CX600 releases resources related to the user and deletes the user entry. After the link recovers, the user will resend an ARP request packet if the ARP entry of the user ages; if the ARP entry does not age, the user sends IP packets. In this case, to enable the user to log in again, the CX600 supports the user access triggered by ARP or IP packets. That is, when the CX600 receives an ARP packet but fails to find the related ARP entry, a process of login and authentication of the user is triggered.
Backup of User Information

The CX600 can save and restore the information about the users that log off abnormally. When a user logs off abnormally, the CX600 records information about the user. Therefore, when the user logs in again through IP or ARP packet triggering, the CX600 enables the user to enjoy related services again according to the saved user information.
Controllable Multicast
The users through the access interface can receive multicast packets only after passing authentication. Each access user can receive a maximum of four multicast programs, that is, four multicast streams. Unauthorized programs are not sent to access users.
QoS policy
The CX600 supports user-based HQoS to bind the configured QoS template to users. The CX600 can control QoS based on the host, location, or CE-VLAN ID. The CX600 also supports port-based, VLAN-based, user-based, or service-based traffic shaping, and HQoS.
CoA or DM Logout
When users go online, the CX600 allows dynamically modifying authorization information about users, which is known as Change of Authorization (CoA).While maintaining the online status of users, the network administrator can modify the service features of the RADIUS server and then dynamically change the services used by users through the CoA packet. This authorization mode is referred to as dynamic authorization. CoA can modify the following user attributes:
l l l l l l l
Minimum and maximum bandwidth Residual duration Residual traffic Controllable multicast program template Real-time charging interval User group Idle-cut time
Issue 03 (2009-03-10)
Page 131 of 200
When residual traffic or duration is used up, the CX600 can send RADIUS DM messages through the RADIUS server to inform the device of cutting off users.
BOD
BOD is a dynamic bandwidth allocation service. When users require adjusting bandwidth, they can dynamically activate or deactivate the BOD service through the Portal server without need of the intervention of operators. In addition, the BOD service provides a more flexible service-based accounting mode for operators. In addition to providing the BOD service for DHCP users, the CX600 provides the BOD service for different services of enterprise users, including the Internet access service and L3VPN and L2VPN internetworking.
5.12 Network Security

When the CX600 runs as the security gateway to access the customer's network and the service system, it can provide the following functions:
l l l
Advanced security system structure Abundant security protocols Strict service access control
Figure 5-56 Security features

Routing protocol MD5 authentication The control plane separated from the forwarding plane Control information filtering Secure VRP system
SSH RADIUS TACACS+ SYSLOG NQA
Routing security
Bidirectional ACL URPF
Management security
Forwarding security
MIRROR NETSTREAM
Service access security ARP attackproof
SINKHOLE
Layer 2 limit
DHCP snooping
Port rate limit
Broadcast/abnormal traffic suppression
The following section describes the security features that the CX600 supports.
5.12.1 Protocol Security Authentication

PPP supports the authentication methods of PAP and CHAP. Routing protocols including RIPv2, OSPF, IS-IS, and BGP support plain text authentication and MD5 encrypted text authentication.
Issue 03 (2009-03-10)
Page 132 of 200
LDP and RSVP support MD5 encrypted text authentication. SNMP supports SNMPv3 encryption and authentication.
5.12.2 RPF/URPF
Unicast Reverse Path Forwarding (URPF) functions to prevent network attacks based on the source address spoofing. Generally, when receiving a packet, a router obtains the destination address of the packet and searches the forwarding table for a route to the destination address. If a route to the destination address is found, the packet is forwarded; otherwise, the packet is discarded. When a packet is sent to a URPF-enabled interface, URPF obtains the source address and inbound interface of the packet. URPF then takes the source address as the destination address to retrieve the corresponding inbound interface and compares the retrieved interface with the inbound interface. If they do not match, URPF considers the source address as a spoofing one and discards the packet. In this way, URPF can effectively prevent malicious attacks that are launched by changing the source address.
5.12.3 MAC Limit

With abundant MAC limit functions, the CX600 can provide various security solutions for large-scale Layer 2 networks and VPLS networks.
MAC Address Limit

With the rapid development of the Metro Ethernet, security plays a more important role on the ingress of the MAN. In the Metro Ethernet, a large number of individual users access the Internet over Ethernet links and it is common that hackers perform MAC attacks on the network. MAC address limit supported by the CX600 can effectively defend the network against the preceding attacks and guarantee the security of the ISP network. With the function of limit to MAC address learning, the system can limit the number of access MAC addresses of a customer to prevent the customer from occupying the MAC address space of other customers; the system can also discard attack packets on the ingress and prohibit invalid packets from consuming bandwidth. MAC address learning is the basic feature of Layer 2 forwarding. It is automatically carried out and is easy to use. It, however, needs to be deployed with caution to avoid attacks. The CX600 supports the following types of limit to MAC address learning:
l l l l l l
Limit to the number of MAC addresses that can be learned Limit to the speed of MAC address learning Limit to interface-based MAC address learning Limit to MAC address learning based on VLAN+port Limit to MAC address learning based on port+VSI Limit to MAC address learning based on QinQ
MAC address learning limit can be applied to the network environment with fixed access users and lacking in security, such as the community access or the intranet without security management. When the number of MAC addresses learnt by an
Issue 03 (2009-03-10)
Page 133 of 200
interface exceeds the limited threshold, the MAC address of a new access user is not learnt. The traffic of this user is thus broadcast at a restricted transmission rate.
MAC Address Entry Deletion

In a VPLS or a Layer 2 network, the MAC address table is the key of forwarding. It, however, is also vulnerable to attacks though MAC entries are to be aged. MAC entries need to be deleted to release MAC resources, minimizing the effect on other services. The CX600 provides the following types of MAC address entry deletion:
l l l l
Deletion of MAC address entries based on port+VSI Deletion of MAC address entries based on port+VLAN Deletion of MAC address entries based on the trunk interface Deletion of MAC address entries based on the outbound QinQ interface
5.12.4 Unknown Traffic Suppression

In the VPLS or Layer 2 network, unknown traffic limit supported by the CX600 functions as follows:
l l
Manages users' traffic. Allocates bandwidth to users.
In this manner, the network bandwidth is efficiently used and network security is guaranteed.
5.12.5 DHCP Snooping

DHCP snooping, a DHCP security feature, filters untrusted DHCP messages by creating and maintaining a binding table. The binding table contains the MAC address, IP address, lease, binding type, VLAN ID, and interface information. DHCP snooping acts as a firewall between DHCP clients and the DHCP server. DHCP snooping is mainly used to prevent DHCP Denial of Service (DoS) attacks, bogus DHCP server attacks, ARP middleman attacks, and IP/MAC spoofing attacks when DHCP is enabled on the device. The working mode of DHCP snooping varies with the type of attacks, as shown in Table 5-2. Table 5-2 Attack types and DHCP snooping working modes Attack Type DHCP exhaustion attack Bogus DHCP server attack Middleman attack and IP/MAC spoofing attack DoS attack by changing the value of the CHADDR DHCP Snooping Working Mode MAC Address limit Trusted/Untrusted DHCP snooping binding table Check on the CHADDR field in DHCP messages
Issue 03 (2009-03-10)
Page 134 of 200
5.12.6 Local Anti-attack

The CX600 provides a uniform local anti-attack module to maintain and manage the anti-attack policy of the whole system. An all-around anti-attack solution that is operable and maintainable is thus provided for users.
Whitelist
The whitelist refers to a group of valid users or users with the high priority. By setting the whitelist, you can enable the system to protect existing services or user services with the high priority. You can define the whitelist through Access Control List (ACL) rules. Then, the packets matching the whitelist are sent to the CPU in preference at a high rate. The valid users that normally access the system as confirmed and the users with the high priority can be added to the whitelist.
Blacklist
The blacklist refers to a group of invalid users. You can define the blacklist through ACL rules. Then, the packets matching the blacklist are discarded or sent to the CPU in a low priority. The invalid users that are involved in attacks as confirmed can be added to the blacklist.
User-defined Flows
User-defined flows indicate that the user defines ACLs. It is applied when unknown attacks emerge on the network. The user can flexibly specify the characteristics of the attack data flows and limit the data flows that match the specified characteristic.
Active Link Protection

The CX600 protects the TCP-based application-layer data such as session data with the whitelist function. When a session is set up, information about this session is synchronized to the whitelist. This ensures that all sessions are protected by the whitelist and are sent with high priority. This feature is called Active Link Protection (ALP). Through ALP, the running of the existing services can be ensured in the case of attacks. When detecting that the session is deleted, the system deletes information about this session from the whitelist.
Uniform Configuration of CAR Parameters

Committed Access Rate (CAR) is used to set the rate of sending the classified packets to the CPU. You can set the committed information rate (CIR), the committed burst size (CBS), and the priority for each type of packets. With different CAR rules set for various packets, the system can make the packets be free from affecting each other to protect the CPU. The CX600 provides convenient methods for configuring CAR parameters:
l l
Uniform configuration of CAR parameters for different LPUs Uniform user interface for configuration
Issue 03 (2009-03-10)
Page 135 of 200

l
Configuration of CAR parameters with granularity at the protocol level
This makes the configuration interface more user-friendly.
Smallest Packet Compensation

The CX600 can efficiently defend the network against the attacks of small packets with the smallest packet compensation function. After receiving the packets to be sent to the CPU, the system detects the packet length.
l l
When the packet length is smaller than the preset minimum packet length, the system calculates the sending rate with the preset minimum length. When the packet length is greater than the preset minimum packet length, the system calculates the sending rate with the actual packet length.
Application-layer Service Association

The CX600 supports the application-layer service association. The system dynamically detects the enabled application-layer information. When detecting that the application-layer services are started, the system accepts the packets of the application-layer services and sends them to the CPU; when detecting that the application-layer services are closed, the system discards the packets of the services or sends the packets of the services with restricted bandwidth.
Local URPF
URPF detects the packets forwarded and transmitted from the local devices at the ingress of a network. In large-scale networks, local URPF can be enabled on local devices to prevent impact on the forwarding performance. This allows URPF to detect only the validity of source addresses of packets on the local devices. Thus, invalid packets are discarded. This prevents the source address spoofing attacks.
Management and Service Plane Protection

Interfaces on routers are classified into management interfaces and non-management interfaces. Management packets can be sent to the routers through management interfaces. On MANs, the downstream interfaces on routers to connect users are generally non-management interfaces. To prevent the devices from being controlled by hackers through non-management interfaces or by flooding management packets, the CX600 provides management plane protection. This allows the management packets to be received only from management interfaces. The management packets are thus controllable.
Defense Against TCP/IP Packet Attacks

In current networks, attacks on TCP/IP networks are increasing, which brings about great impact. The CX600 provides the following defense measures against attacks on TCP/IP networks:
l
The defective packet attack indicates that the attacker sends a defective IP packet to a targeted system, causing the system to crash during the processing of such an IP packet. The system discards the following defective packets after they are identified through the forwarding engine and software:
IP packets with null load
Issue 03 (2009-03-10)
Page 136 of 200

Null IGMP packets TCPSYN packets whose source and destination IP addresses are the same in LAND attacks ICMP Echo Request packets whose destination addresses are broadcast addresses or subnet broadcast addresses in Smurf attacks Attacks of the TCP packet flag bit when the six flag bits (URG, ACK, PSH, RST, SYN, and FIN) are all 1s, the six flag bits are all 0s, or SYN and FIN bits are both 1s
The fragmented packet attack indicates that the system cannot handle normal requests from users or the system becomes Down when the CPU is busy with fragmented packets. When the fragmented packets are identified by the forwarding engine and software, the system implements CPCAR to limit the rate of sending repetitive fragmented packets to the CPU. The software ensures the correctness of packet reassembly or discards the packets whose reassembly fails.

Attacks of a huge number of fragments or attacks of the packets that have a large offset value Repetitive fragmented packets Tear Drop, syndrop, nesta, fawx, bonk, NewTear, Rose, Ping of death, and Jolt attacks
l l
TCP SYN: The system can identify TCP SYN packet flooding and implement CAR on LPUs. UDP flood: The system can identify packets in Fraggle attacks and attack packets on UDP diagnosis ports. The system can discard those packets or filter out the packets on LPUs.
Attack Source Tracing

When the CX600 is attacked, it obtains and stores suspicious packets. After the packets are formatted, you can use commands or offline tools to view the packets. This helps to locate the source of attacks easily. When attacks occur, the system automatically removes the data encapsulated on upper layers of the transmission layer and then caches the packets in the memory. When the number of packets in the cache reaches a certain amount, for example, 20000 packets on each LPU, the previous packets are overridden when more packets are cached.
5.12.7 GTSM
Currently, some attackers on the network simulate valid packets to attack a router. As a result, the finite resources of the router such as the CPU on the SRU/MPU is heavily loaded and consumed. For example, the attacker continuously sends simulate BGP protocol packets to a router. After the LPU of the router receives the packets destined for the local host, the LPU sends the packets to the BGP processing module of the CPU on the SRU/MPU instead of identifying the validity of the packets. As a result, the system is abnormally busy with the high CPU utilization rate when the SRU/MPU of the router processes these valid packets. To avoid the preceding attacks, the CX600 provides the GTSM. The GTSM protects services of the upper layer over the IP layer by checking whether the TTL value in the IP header is within the specified range. In the application, the GTSM is used to protect
Issue 03 (2009-03-10)
Page 137 of 200
the TCP/IP-based control layer such as the routing protocol from the type of CPU-utilization attacks such as CPU overload. The CX600 supports the following types of GTSM:
5.12.8 ARP Attack Defense

In the current ISP network, Ethernet is commonly used for access. ARP runs as the open protocol on the Ethernet, offering chances for malicious attackers. Malicious attackers attack the network from the perspectives of space and time.
l
Space-based attacks indicate that the attacker resorts to the finite ARP buffer of a router. The attacker sends a large number of simulate ARP request and response messages to the router. As a result, the ARP buffer is overflowed; normal ARP entries cannot be buffered. Normal forwarding is thus interrupted. Time-based attacks indicate that the attacker resorts to the finity of the processing capability of a router. The attacker sends a large number of simulate ARP request, response, or other packets that can trigger the router to perform ARP processing. As a result, the computation resources of the router are busy with ARP processing during a long period; other services cannot be processed. Normal forwarding is thus interrupted.
Interface-based ARP Entry Restriction

The interface-based ARP entry restriction function effectively minimizes the attacked range when the ARP entry overflow attack occurs. The attacked range is restricted in the interface. In this manner, other interfaces of the board or the whole system are not affected.
Timestamp-based Scanning-proof
The timestamp-based scanning-proof function can identify the scanning attack on time and suppress the processing of the requests generated by the scanning when a scanning attack occurs, regardless of whether it is an ARP scanning attack or IP scanning attack. In this way, the CPU is kept away from attacks.
ARP Bidirectional Isolation

As ARP request packets come from the outside of a device and can be initiated at any time, the device cannot distinguish between normal packets and attack packets when the ARP request packets carry valid IP addresses. According to the analysis of actual ARP attacks on some networks, the ARP attack traffic comprises 50% ARP request packets and 50% ARP response packets. Therefore, a solution to the attacks of numerous ARP packets must be based on the two aspects: ARP request packets and ARP response packets. ARP bidirectional isolation enables a device to process ARP request packets and ARP response packets separately.
l
The device performs stateless responses for ARP request packets. That is, the device generates neither ARP entries nor relevant states after replying to the ARP request packets. Without sending the ARP request packets to the CPU for processing, the device defends the ARP table of the gateway against address spoofing attacks by ARP request packets.
Issue 03 (2009-03-10)
Page 138 of 200

l
The device processes only the ARP response packets of the ARP request packets sent by its CPU. The ARP response packets of the ARP request packets that are not sent by its CPU are then discarded. The normal ARP request packets can thus be promptly processed.
Filtering of Invalid ARP Packets

The CX600 filters out the following types of ARP packets:
l
Invalid ARP packets such as the ARP request packets with the destination MAC address as a unicast address, the ARP request packets with the source MAC address as a non-unicast address, and the ARP reply packets with the destination MAC address as a non-unicast address Gratuitous ARP packets ARP request packets whose destination MAC address is not null
l l
You can configure the system to filter out one or more kinds of packets mentioned above through command lines.
ARP VLAN CAR

ARP VLAN CAR is mainly applied to the scenario where packets are processed based on the interface number and VLAN ID. This ensures that VLANs are isolated when attacks occur. The attack against one VLAN does not spread to other VLANs. This minimizes the impact of attacks on devices and services. The CX600 can perform CAR twice on the ARP packets sent to the CPU. ARP VLAN CAR is the second CAR implementation, which can be configured by users. CAR is implemented for the first time before the ARP packets are sent to the CPU. When the number of ARP packets to be sent to the CPU exceeds the value set in CAR rules, the excessive packets are discarded. At the same time, CAR is implemented for the second time on the remaining ARP packets. If the number of ARP packets to be sent to the CPU is smaller than the value set in CAR rules, all the ARP packets are sent to the CPU directly.
5.12.9 Mirroring
Mirroring means that the system copies the received packets on a node in the network to a specified observing port, without interrupting services. Users can specify the number of the port to be observed and connect the packet analysis equipment with the observing port to observe the traffic. In local mirroring, the observing port and mirroring port reside on the same device. In local mirroring, the observing port and mirroring port reside on different devices. The CX600 supports both the local mirroring and remote mirroring. Mirroring is divided into the following types according to the requirements for the packets to be copied:
l l
Port mirroring: The packets received and sent by a mirroring port are completely copied to a specific observing port. Flow mirroring: On the basis of traffic classification, the packets that match specific rules are copied and other packets are filtered out. By analyzing the filtered packets that the system does not concern about, the system can control packets with fine granularity. The efficiency of the packet analysis equipment can thus be improved.
Issue 03 (2009-03-10)
Page 139 of 200
Mirroring is divided into the following types according to the direction in which the packets are copied:
l l
Upstream mirroring: All packets or the packets that match specific rules received by a mirroring port are copied to a specific observing port. Downstream mirroring: All packets or the packets that match specific rules to be sent by a mirroring port are copied to a specific observing port.
Local Mirroring
Figure 5-57 shows the networking diagram of applying local mirroring. Figure 5-57 Networking diagram of applying local mirroring
Network1
PortA
Inbound packets
PortB
Outbound packets Mirroring packets
Network2
PortC
Packet analysis equipment
Network 1 and Network 2 are connected through Router. When the incoming packets from Network 1 to Port A need to be monitored, you can copy the incoming packets to Port A as mirroring packets. When the incoming packets are normally forwarded, the mirroring packets can be forwarded through Port C to the packet analysis equipment for processing. In certain cases, both the incoming packets and outgoing packets to and from Network 1 need be monitored. This allows Router to copy the incoming and outgoing packets on Port A to the observing port. In local mirroring, a physical observing port and multiple logical observing ports can be configured on an LPU. Multiple mirroring ports can be configured on an LPU.
l
Mirroring ports in local mirroring can be Ethernet interfaces and sub-interfaces, low-speed serial interfaces channelized from POS interfaces, MFR interfaces, or MP interfaces. Observing ports in local mirroring can be Ethernet interfaces and sub-interfaces, POS interfaces, Eth-Trunks and Eth-Trunk sub-interfaces, or IP-Trunks.
When the downstream mirroring in local mirroring is implemented, inter-LPU mirroring is supported. That is, the observing port and mirroring port can be configured on different LPUs. If the observing port is a logical interface, the system can carry out CAR to the local mirroring packets.
Remote Mirroring
Compared with local mirroring, remote mirroring features the following:
Issue 03 (2009-03-10)
Page 140 of 200

l l
Network maintenance engineers can analyze mirroring packets from remote devices rather than being on site. A network maintenance engineer can analyze mirroring packets on different sites, which saves human resources.
Figure 5-58 shows the networking diagram of applying remote mirroring. Figure 5-58 Networking diagram of applying remote mirroring
Customer1
CX-C IP/MPLS backbone network Packet analysis equipment
CX-A
CX-B
Customer2 CX-D
CX-A and CX-B are edge routers on the IP/MPLS backbone network. Customer 1 and Customer 2 access the backbone network through CX-C and CX-D respectively. To maintain the network, analyze attacks, and locate faults, you need to check whether the protocol packets sent from or received by CX-A are correct; or you need to check whether the sub-interfaces of a VPN user bound to CX-C are attacked. In this manner, you need to copy a type of protocol packets received by CX-A, protocol packets sent from CX-A to CX-C, or packets received by sub-interfaces on CX-A to CX-B. CX-B then forwards the preceding packets to the packet analysis equipment for analysis. In remote mirroring, data from the mirroring port is copied and then the copy of data is sent over a specified tunnel to a remote destination router where the remote observing port resides. The remote observing port then forwards the copy of data to the packet analysis equipment. Data transmitted from a mirroring port to a remote observing port forms a flow. If there are two pieces of data transmitted from two mirroring ports to a remote observing port, these two pieces of data form two flows. The CX600 provides MPLS LSPs, MPLS TE tunnels, and GRE tunnels for remote mirroring. In remote mirroring, multiple observing ports and mirroring ports can be configured on an LSP.
l
Mirroring ports in remote mirroring can be Ethernet interfaces and sub-interfaces, Eth-Trunks and Eth-Trunk sub-interfaces, IP-Trunks, low-speed serial interfaces, MP interfaces, or MFR interfaces.
Issue 03 (2009-03-10)
Page 141 of 200

l
Observing ports in remote mirroring can be Ethernet interfaces and sub-interfaces, POS interfaces, Eth-Trunks and Eth-Trunk sub-interfaces, or IP-Trunks.
In remote mirroring, the mirroring packets can be intercepted.
5.12.10 NetStream
The Internet develops rapidly. This requires more delicate network monitoring and management while this provides more bandwidth resources. Developing a technology to answer the preceding demands becomes urgent. NetStream is a technology that is based on network traffic statistics. It collects statistics on traffic flows and resource usage in the network accordingly, and monitors and manages the network based on types of services and resources. NetStream provides the following functions:
l
Accounting NetStream provides detailed statistics for the resource-occupation-based (such as links, bandwidth, and time periods) accounting. Statistics such as IP addresses, number of packets and bytes, transmission time, ToS fields, and application types are collected. Based on the collected statistics, the ISP can charge users flexibly based on time periods, bandwidth, application, or QoS; enterprises can count their expenses or distribute costs to make better use of resources. The enterprise customer can count the expense of the department or assign the cost according to the information to make effective use of the resources.
Network planning and analysis NetStream provides key information for advanced network management tools to optimize the network design and planning. The minimum network operation cost thus achieves the best network performance and reliability.
Network monitoring NetStream realizes the real-time network monitoring. The remote monitoring (RMON), RMON-2, and flow-based analysis technology visualizedly displays the flow mode on a single router or routers across the network. This provides the basis for fault pre-detection and effective fault rectification.
Application monitoring and analyzing NetStream provides detailed application statistics about the network. For example, the network administrator can view the proportion of each application, such as Web, the File Transfer Protocol (FTP), Telnet, and other TCP/IP applications to network traffic. The ISP then properly plans and allocates network application resources to meet the users' requirements according to these application statistics.
Abnormal traffic detection NetStream detects the abnormal traffic such as network attack traffic of various types in the real-time manner. NetStream ensures network security by means of alarms of the NMS and the cooperation with devices.
NetStream consists of three devices: NetStream Data Exporter (NDE), NetStream Collector (NSC), and NetStream Data Analyzer (NDA). The relations among the three devices are shown in Figure 5-59.
Issue 03 (2009-03-10)
Page 142 of 200
Figure 5-59 Diagram of NetStream data collection and analysis
NSC
NDA NSC
The NDE samples packets and exports the information to the NSC. The NSC is responsible for analyzing and collecting the statistics data from the NDE. The NDA analyzes the statistics data and then provides the basis for various services, such as network accounting, network planning, network monitoring, application monitoring, and analysis. The CX600 can run as an NDE to sample packets, aggregate flows, and output flows. According to the position of sampling packets and processing flows, NetStream on the CX600 is classified into distributed NetStream and integrated NetStream. Distributed NetStream supports load balancing among multiple NetStream boards.
l l
Distributed NetStream: An LPU can sample packets, aggregate flows, and output flows independently. Integrated NetStream: Some LPUs do not support integrated NetStream. They only sample packets and then send the sampled packets to the NetStream SPU for integrated processing of flow aggregation and output.
The CX600 provides the following functions from the aspect of sampling:
l l l l l
Supports sampling in the inbound and outbound interfaces. Some boards support sampling on the inbound interface. Supports interface-based sampling and traffic-classification-based sampling. Supports sampling on IPv4 unicast/multicast packets, fragmented packets, MPLS packets, and MPLS L3VPN packets. Supports regular packet sampling, random packet sampling, regular time sampling, and random time sampling. Supports sampling of various physical and logical interfaces such as POS interfaces, Ethernet interfaces, VLAN sub-interfaces, serial/MP/FR PVC/FR MP interfaces provided by CPOS interfaces, ATM interfaces, FR interfaces, RPR interfaces, trunk interfaces, VLANIF interfaces, and GRE interfaces.
The CX600 provides the following functions from the aspect of aggregation and output:
l
IPv4 supports the ten aggregation modes that are as, as-tos, protocol-port, protocol-port-tos, source-prefix, source-prefix-tos, destination-prefix, destination-prefix-tos, prefix, and prefix-tos 10. Supports aggregation of MPLS packets based on three-layer labels.
Issue 03 (2009-03-10)
Page 143 of 200

l
Outputs the generated statistics in v5, v8, and v9 formats. When the packets are output in the v9 format, both the 16-bit and 32-bit indexes are supported, which can be set through commands as required. Each aggregated flow can be output to two NMS servers.
5.12.11 Lawful Interception

Lawful interception indicates that law enforcement agencies lawfully intercept user information after authorized. In lawful interception, the following information is intercepted:
l l
CC: the contents of the communication such as emails and VoIP packets IRI: information related to the communication, including the address, time, and network location
The contents of communication (CC) and intercepted related information (IRI) can be provided by the network devices of the carrier. The IRI is generally provided by the AAA server. The CC is provided by the interception device, for example, the CX600. Figure 5-60 shows the scenario for lawful interception.
In this scenario, the IRI is provided by the AAA server and the CC is provided by the CX600.
Figure 5-60 Scenario for lawful interception

LIG management system AAA server HI1 Interception center 1 HI2 Interception center 2 ... Interception management center L1 X1,X2 Carrier
HI3 LIG
X1,X3 CX
Interception center N
Lawful interception involves the following roles:

l
Interception center The law enforcement agency intercepts the activities of online users. The interception center initiates the interception and receives the interception result. The functions of the interception center are as follows:

Defining the intercepted target Initiating or terminating the interception Receiving and recording the interception result
Issue 03 (2009-03-10)
Page 144 of 200

l
Analyzing the interception result
Interception management center The interception management center is the agent of the interception centers. The interception management center receives the interception request from the interception center, transforms the information in the request to the location and service identifier, and then delivers the configuration of interception to the network devices of the carrier.
LIG The lawful interception gateway (LIG) acts as the agent between the interception management center and the devices of the carrier. The LIG plays an important role in lawful interception. Its functions are as follows:

Receives the interception request from the interception management center through the L1 and H1 interfaces. Delivers the configuration of interception to network devices and obtains intercepted contents through the X interfaces. Sends the intercepted contents to the interception management center through the H2 and H3 interfaces.
LIG management system The LIG management system receives the interception request from the interception management center and sends the request to the LIG. A LIG management system can manage multiple LIGs.
The LIG management system delivers the configuration to the LIG through the L1 interface. The LIG is located in the network of the carrier. The LIG management system is managed by the interception management center.
Carrier The carrier deploys the lawful interception function on the network devices. The devices that support lawful interception receive the configuration from the interception management center, and then send the intercepted traffic to the interception management center.
5.13 Network Reliability

The CX600 provides all-around reliability techniques. This caters to the requirements for reliability of the carrier-class network.
Issue 03 (2009-03-10)
Page 145 of 200
Figure 5-61 Reliability techniques
Backup
Interface backup
Link reliability
NSF
BFD
Routing optimization
FRR
Device reliability
99.999% Customized alarm damping
Network reliability
Active/standby MPUs Multiple SFUs
Eth Trunk IP Trunk
Grace Restart
Inter-board Ethernet OAM port binding Active/standby power modules RPR interface backup
Fast detection of link fault
Fast route convergence Loose policybased routing ECMP
IP FRR TE FRR LDP FRR VLL FRR VPN FRR
5.13.1 Backup of Key Modules

The CX600 can work with a single SRU/MPU or two SRU/MPUs in backup mode. The SRU/MPU of the CX600 supports hot backup. If the device is configured with two SRU/MPUs for backup, the master SRU/MPU works in active state and the slave SRU/MPU is in standby state. In addition, users cannot access the management interface of the slave SRU/MPU, or configure commands on the Console port or the AUX port. The slave SRU/MPU exchanges information (including heartbeat messages and data backup) only with the master SRU/MPU. The system supports active/standby switchover in two ways: automatic switchover and forcible switchover. The automatic switchover may be triggered by serious faults or resetting of the master SRU/MPU. The forcible switchover is triggered with commands. You can forcibly prohibit the active/standby switchover of the SRU/MPU through the related command. The CX600 supports backup of management bus and 1+1 backup for the power module. The LPU, the power module, and the fan module are hot swappable. These designs enable the system to recover or respond quickly when a severe abnormality is detected on the device or the network, thereby improving the Mean Time between Failure (MTBF) and minimizing the impact of unreliable factors on normal service.
5.13.2 High Reliability of the LPU

The CX600 supports backup of some key service interfaces through protocol extension.
l
The CX600 supports the Virtual Router Redundancy Protocol (VRRP) on the Ethernet interface. With the extended VRRP, the CX600 enables two interfaces on one router or on different routers to back up each other, thus ensuring high reliability of the interfaces. On the CX600, the Eth-Trunk and the IP-Trunk support inside backup and outside backup for member interfaces.
Issue 03 (2009-03-10)
Page 146 of 200

l
The CX600 supports inter-board trunk bundling.

Users can access different LPUs over double links for inter-board bundling. This ensures the high reliability of services. The CX600 realizes the inter-board bundling by the high-performance engine and forwards packets in load balancing mode at the line rate over multiple links. The Hash algorithm based on the source and destination IP addresses carries out even load balancing to forward traffic over links. Seamless switchover is performed in the case of a link failure, without interrupting services.
The CX600 also provides backup of RPR-based interfaces through the RPR protocol and RPR networking technologies.
The backup function allows the router to monitor and back up the running status of the interface when bearing LAN, MAN or WAN services. In this case, the status change of the interface that is backed up will not affect the routing table and the service at the interface can be restored quickly.
5.13.3 Alarm Customized Damping

With a higher requirement for device reliabilities posed by the current carrier-class network, network devices must have the capability of fast fault detection. After an interface is initiated with fast fault detection, the physical status of the interface frequently converts between Up and Down because alarm generation is speeded up. In this case, the network repetitively flaps. Therefore, generated alarms need be filtered and suppressed to avoid frequent network flaps. Alarm damping can effectively filter and suppress alarms, avoiding repetitive flaps of the interface status; alarm customization enables you to control the impact of alarms on the interface status. Alarm customization and alarm damping function as follows:
l l
Allows you to customize alarms, that is, specify which kinds of alarms that can trigger the change of the interface status. Enables the system to suppress alarms, damping the frequent flaps of a network.
5.13.4 Ethernet OAM

The CX600 supports the Ethernet OAM functions as follows:
l l
Fault management Performance management
With the fault management mechanism, the CX600 can detect the network connectivity by sending the detection OAM packets periodically or through manual triggering. This mechanism is similar to the Bidirectional Forwarding Detection (BFD). The CX600 can also locate faults of Ethernet by using means similar to the ping and tracert tools on IP networks. The CX600 triggers protection switchover in less than 50 ms.
Issue 03 (2009-03-10)
Page 147 of 200
Performance management is used to measure the packet loss ratio, delay, and jitter during the transmission of packets. It also collects statistics on various kinds of traffic such as the number of transmitted bytes and the number of errored packets.
Point-to-Point Fault Management for Ethernet

IEEE 802.3ah was brought forward by Ethernet in the First Mile Alliance (EFMA). IEEE 802.3ah defines the following functions:
l l l l
Capability discovery Link performance monitoring Fault detection and alarm Loop test
The PDUs of IEEE 802.3ah OAM are transmitted by a slow protocol. Fault detection messages are sent every one second. Conforming to IEEE 802.3ah, the CX600 supports the point-to-point Ethernet fault management. It can detect faults in the last mile of the direct link at the user side of the Ethernet. By now, the CX600 supports the following functions defined in IEEE 802.3ah:
l l l l
Automatic neighbor discovery Link fault monitoring Remote fault notification Remote loopback configuration
End-to-End Fault Management for Ethernet

This section describes the end-to-end fault management for Ethernet from the following two aspects:
l
Hierarchical MD The CX600 realizes the end-to-end fault management for Ethernet by conforming to IEEE 802.1ag or breaking away IEEE 802.1ag. IEEE 802.1ag is used to test the end-to-end Ethernet connectivity and locate faults. It provides different levels of management domains. OAM messages with a low level are not forwarded to the management domain with a high level. This guarantees security and maintainability of networks. According to IEEE 802.1ag, the network that bears the Ethernet OAM mechanism is divided into different Maintenance Domains (MDs). An MD is an interconnected Ethernet network that is maintained by the same administrator. Multiple Service Instances (SIs) can be applied on an MD. An SI corresponds to a VALN. An SI consists of multiple devices. The border port in the SI is called the Maintenance association End Point (MEP); all the other ports are called the Maintenance association Internal Point (MIP). MIPs are responsible for connecting different MEPs. Both MEPs and MIPs are called MP. All the MEPs in an SI form a Maintenance Association (MA), in which fault detection is carried out. Part of the network in an MD might be maintained by another administrator, namely, the MD might be nested. The MD level is used to differentiate various levels of OAM that can be carried out in an MA. The MD level is carried in the
Issue 03 (2009-03-10)
Page 148 of 200
OAM message. The OAM message with a low level are discarded in the high-level MP.
l
End-to-end fault detection and location The ISP and Internet Context Provider (ICP) have gradually used fault detection to guarantee QoS and reduce maintenance expense. Fault detection is realized by sending and detecting the Continuity Check (CC) message at a scheduled time. The CX600 supports the tools of MAC ping and MAC trace by using the Loop Back (LB) and Link Trace (LT) packet defined in IEEE 802.1ag to locate faults.
MAC ping MAC ping realized by the LB message is used to test whether a device on the network is reachable. It acquires the network status and the delay parameter. To carry out MAC ping between any two devices on the network, the CX600 needs to meet the following requirements: The originating point is a MEP. The two points are MPs belonging to the same MA. The two points are reachable.
MAC trace MAC trace realized by the LT message is used to test the transmission paths of messages and the link break point between the two devices. The requirements for MAC ping also apply to MAC trace.
Ethernet Performance Management

Conforming to ITU-T Y.1731 recommendations, the CX600 supports the Ethernet performance management. The CX600 can measure the delay, jitter, and packet loss ratio in transmission. To achieve that, the CX600 inserts the timestamp in the LB message defined in IEEE 802.1ag. In this way, the CX600 can detect performance during a specified time period and on a specified network segment to obtain the performance parameters of an end-to-end service flow. The CX600 can measure the performance parameter at a scheduled time. The CX600 also combines the performance parameter with the network management information to output reports. By using the performance management tools, the ISP can monitor the network status in real time through the NMS station. The ISP checks whether the forwarding capacity of the network complies with the SLA signed. Then, faults can be swiftly located. The ISP need not carry out detection at the user side. This greatly decreases the maintenance expense.
5.13.5 VRRP
The Virtual Router Redundancy Protocol (VRRP) is a fault-tolerant protocol. VRRP realizes route selection among multiple egress gateways by separating the physical devices from logical devices. VRRP is applicable to such a LAN that supports multicast or broadcast as the Ethernet. VRRP uses logical gateways to ensure high availability of transmission links. This avoids service interruption that results from a gateway device failure, without changing the configuration of routing protocols. VRRP combines a group of routers in a LAN into a backup group that functions as a virtual router. Hosts in the LAN know the IP address of only this virtual router rather
Issue 03 (2009-03-10)
Page 149 of 200
than that of a specific router in the backup group. Hosts set the IP address of the virtual router as their own default next-hop address. Hosts in the LAN thus access other networks through the virtual router. In the backup group, only one router is active and called master router; other routers are in backup state with different priorities and called backup router. Figure 5-62 shows the typical networking diagram of VRRP. Figure 5-62 Typical networking diagram of VRRP
10.100.10.2/24 PC 10.100.10.3/24 Backup Master
Internet
Server Internal network Backup 10.100.10.0/24 Backup group Virtual IP address 10.100.10.1/24 10.100.10.4/24
VRRP dynamically associates the virtual router with a physical router that undertakes transmission services. VRRP can select a new router to take over the transmission when the physical router fails. The entire process is transparent to users, and realizes non-blocking communication between the internal network and the external network.
mVRRP
The management Virtual Router Redundancy Protocol (mVRRP) refers to a management VRRP group. The only difference between an mVRRP group and a common VRRP group is that the mVRRP group can be bound to common VRRP groups and determine the status of a common VRRP group according to the binding. An mVRRP group cannot serve as a common VRRP group and be bound to other mVRRP groups although it can be bound to multiple common VRRP groups. An mVRRP group can join a VGMP group as a member. After an mVRRP group joins a VGMP group, you can configure the mVRRP group to monitor the statuses of both the peer and link BFD sessions. The mVRRP group, however, loses its independence. Except for the Initialize state, the Backup and Master statuses depend on the status of the VGMP group that the mVRRP group joins.
VGMP
Some applications require the same come-and-go path of a session. That is, the packets of the same session must pass through the same devices. In this case, VRRP has its own limitations. If the master/backup switchover is performed, the come-and-go path of the same session cannot be ensured the same.
Issue 03 (2009-03-10)
Page 150 of 200
To avoid the preceding problem, Huawei develops the VRRP Group Management Protocol (VGMP) on the basis of VRRP. The VRRP management group set up on the basis of VGMP uniformly manages the joining VRRP backup groups. On a router, the interfaces that belong to different VRRP backup groups are thus kept master or backup simultaneously. In this manner, the VRRP statuses of the router are kept consistent. Configure VGMP in the following scenarios:
l
The system is configured with a large number of VRRP backup groups. The system processes the VRRP protocol packets on the SRU/MPU. A large number of VRRP backup groups may generate many VRRP protocol packets. These protocol packets compete with other protocol packets for the CPU resources and the channel as well as the bandwidth of the inter-board communication. In this case, the system is overloaded. When you configure a VRRP management group to uniformly manage the VRRP backup groups, the managed VRRP backup groups do not send protocol packets independently. In this way, the occupancy of system resources is reduced.
The router has functions of the firewall, NAT gateway, or proxy server. These functions require the same come-and-go path of a session. Configuring a VRRP management group to uniformly manage the VRRP backup groups ensures the status of the VRRP backup group consistent.
5.13.6 GR
Graceful Restart (GR) is a key technology in implementing HA. The GR switchover and subsequent restart can be performed by the administrator or triggered by faults. GR neither deletes the routing information from the routing table or the FIB nor resets the board during the switchover when faults occur. This prevents the services interruption of the entire system. GR has the following advantages:
l l l
Simple and easy to implement. You only need to modify some protocols rather than changing the current software. It does not need to back up the protocol status information. Few data needs to be backed up from the AMB to the SMB. The data includes configuration modification, updated messages and events, interface status change, and topology information and routing information from neighbors after restart. During the switchover, there is little probability of service interruption. The network converges rapidly in normal situations.
l l
The CX600 supports system-based GR and protocol-based GR. The protocol-based GR includes:
l l l l l l
BGP GR OSPF GR IS-IS GR MPLS LDP GR L3VPN GR RSVP GR
Issue 03 (2009-03-10)
Page 151 of 200
5.13.7 BFD
The BFD is a detection mechanism used in the entire network. It is used to quickly detect and monitor the connection of links and forwarding state of the IP route in the network. Detection packets are transmitted from both ends of the bidirectional link. The CX600 tests the link status from both directions to realize failure detection in milliseconds. The CX600 supports single-hop BFD and multi-hop BFD. The following describes the BFD features supported by the CX600.
BFD for VRRP

BFD is used to detect and monitor the connectivity of the link layer or IP layer of the network and trigger the rapid VRRP switchover.
BFD for FRR

l
BFD for LDP FRR BFD can detect the protected interfaces that can trigger the LDP FRR switching. BFD for IP FRR and BFD for VPN FRR On the CX600, IP FRR and VPN FRR are triggered after BFD reports detection faults to the upper-layer application.
BFD for Static Routes

Static routes do not have the detection mechanism. When the network fails, administrator interference is needed. With the feature of BFD for static routes, the BFD session can be used to detect the status of the IPv4 static route in the public network. The routing management system determines whether the static route is available according to the BFD session status.
BFD for IS-IS

The CX600 supports the detection on the IS-IS adjacency by using the BFD session configured statically. BFD detects the fault of the link between adjacent IS-IS nodes and rapidly reports the fault to IS-IS to trigger the fast route convergence of IS-IS.
BFD for OSPF/BGP

The CX600 supports OSPF and BGP in dynamically setting up and deleting the BFD session.
l
When the routing protocol neighbor relation is established successfully, a routing protocol notifies the establishment of a BFD session through routing management module and fast detects the neighbor relation of the routing protocol. The detection parameters of the BFD session are set by the routing protocol. When the BFD session detects the fault, the BFD session status becomes Down. BFD triggers route convergence through the RM module.
Issue 03 (2009-03-10)
Page 152 of 200
Generally, routing protocols implement second-level detection based on the Keepalive mechanism of Hello packets, whereas BFD carries out millisecond-level detection. When the detection interval is 10 ms and the detection multiplier is 3, BFD can report the protocol failures in 50 ms. The route convergence thus speeds up.
l
When the neighbor status is unreachable, the routing protocol tells BFD to delete the session through the RM module.
BFD for PIM

PIM BFD is applicable to the shared network segment where routers enabled with PIM reside. PIM BFD fast detects the fault of the DR or Assert Winner. PIM BFD uses normal BFD messages. It automatically sets up BFD sessions between PIM neighbors, monitors the status of the PIM neighbors, and responds to the failure of the neighbor promptly.
BFD for IP-Trunk and Eth-Trunk

IP-Trunk and Eth-Trunk consist of member links, providing large bandwidth or high reliability. When the number of member links being Up reaches a certain value, the corresponding trunks can keep Up. On the CX600, BFD can detect a trunk and a trunk member interface independently. That is, it can detect the connectivity of the trunk and that of an important member link of the trunk.
BFP for LSP

BFD for LSP indicates that BFD packets are transmitted along the static LSP, the dynamic LSP, the RSVP-TE tunnel, and the PW. By fast transmitting and receiving of BFD packets, fast detection of the link fault can be carried out. The carried services can thus be fast switched for service protection. BFD for LSP performs fast fault detection of LSPs, TE tunnels, and PWs. In this way, BFD for LSP realizes fast switchover of MPLS services such as VPN FRR, TE FRR, and VLL FRR.
5.13.8 FRR
The CX600 provides multiple FRR features. You can deploy FRR as required to improve network reliability.
IP FRR
FRR can minimize data loss due to network faults. The switching time can reach 50 ms. The CX600 provides FRR that enables the system to monitor and store the real-time status of the boards and ports, and check the status of the ports when packets are forwarded. When abnormality occurs on a port, the system can fast switch traffic to another preset route. This improves the Mean Time Between Failures (MTBF) and reduces the amount of lost packets.
Issue 03 (2009-03-10)
Page 153 of 200
LDP FRR
The traditional IP FRR cannot effectively protect the traffic in the MPLS network. The CX600 provides the LDP FRR function and the solution to port protection. Along an LDP with Downstream Unsolicited (DU) label distribution, ordered label control and liberal label retention, a Label Switch Router (LSR) saves all label mapping messages. Only the label mapping messages sent by the next hop corresponding to the FEC can generate a label forwarding table. With this feature, the backup LSP is set up if a label forwarding table is produced for the liberal label mappings. Normally, a packet is forwarded through the primary LSP. When the outgoing interface of the primary LSP is Down, the packet is forwarded through the backup LSP. This ensures continuous traffic follow before network convergence.
Hybrid FRR
The CX600 supports the FRR formed by the combination of IP routes and VPN routes in a same VPN instance. That is, the CX600 supports hybrid FRR. In a bearer network, IP FRR is deployed when a CE is dual-homed to PEs. If multiple voice VPNs are connected to the CE and a POS link is encapsulated between the two PEs, the POS interface cannot be divided into subinterfaces that can be bound to different VPNs to provide a backup link for the traffic. In this case, the BGP VPNv4 peer can be set up between the two PEs. Therefore, the backup path, in the form of a private route, is exchanged between the two PEs. The VPNv4 route then serves as a backup of the IP route between the PE and the CE, and FRR is thus implemented on the CX600. In this manner, the traffic can be switched within 50 ms.
TE FRR
TE FRR is a technology used in MPLS TE to implement local protection for the network. Only the interfaces at a speed of over 100 Mbit/s support TE FRR. The switching time of TE FRR can reach 50ms. It can minimize data loss when network failures occur. TE FRR is only a temporary protection method. When the protected LSP becomes normal or a new LSP is established, the traffic is switched back to the original LSP or the newly established LSP. After an LSP is configured with TE FRR, the traffic is switched to its protection link and the ingress node of the LSP attempts to establish a new LSP when a link or a node on the LSP fails. Based on the objects to be protected, FRR is divided into the following two types:
l
Link protection: Direct link connection exists between PLR and MP, and primary LSP passes this link. When this link is out of service, traffic is switched to bypass LSP. As shown in Figure 5-63, the primary LSP is R1R2R3R4, and the bypass LSP is R2R6R3.
Issue 03 (2009-03-10)
Page 154 of 200
Figure 5-63 Schematic diagram of FRR link protection

PLR MP
R1
R2
R3
R4
Primary LSP Bypass LSP
R6
Node protection: PLR is connected with MP through R3, and primary LSP passes this router. When R3 fails, traffic is switched to bypass LSP. As shown in Figure 5-64, the primary LSP is R1R2R3R4R5, and the bypass LSP is R2R6R4. R3 is the protected router.
Figure 5-64 Schematic diagram of FRR node protection

PLR MP
R1
R2
Primary LSP Bypass LSP
R3
R4
R5
R6
VLL FRR
VLL FRR is a technique of realizing network protection in the L2VPN. It fast switches user traffic to the backup link after a fault occurs to the network. In this way, the reliability of the L2VPN is improved. VLL FRR is also called VLL redundancy. VLL FRR in the L2VPN includes fault detection, fault notification, and active/standby switchover of links. The CX600 provides kinds of features that can be combined to realize VLL FRR.
l
Fault detection

BFD for LSP/PW can fast detect the fault of the LSP/PW at the network side in an L2VPN. Ethernet OAM, ATM OAM, PPP, and FR can fast detect the fault at the access circuit (AC) side in an L2VPN. LDP, BGP, or RSVP can notify the remote PE router of the fault of the LSP/PW or the AC.
Fault notification
Issue 03 (2009-03-10)
Page 155 of 200

l
BFD for LSP/PW can inform the remote PE router of the fault of the LSP/PW or the AC. Ethernet OAM, ATM OAM, PPP, and FR can notify the local CE router of the fault. In a symmetric network, CE routers perform the active/standby switchover. In an asymmetric network, PE routers work with CE routers to perform active/standby switchover.
Active/standby switchover of links

VPN FRR
In the traditional L3VPN, the local PE router senses the fault of the remote PE router through the BGP Hello packets. The time taken to sense the fault defaults to 90 seconds. That is, VPN routes on the local PE router converge after the fault of the remote PE router lasts 90 seconds. VPN FRR supported by the CX600 can solve the preceding problem. When the CE router is dual-homed, VPN FRR can fast switch VPN services to the backup tunnel and PE router after the link between the CE router and the PE router is disconnected or after the PE router restarts. In this manner, services are restored within a short period.
l
The forwarding engine of the local PE router keeps not only the outer labels of the remote active PE router and the inner labels distributed to VPN routes, but also the outer labels of the remote standby PE router and the inner labels distributed to VPN routes. With the end-to-end fault detection mechanisms such as BFD, the local PE router senses the fault of the remote active PE router within 200 milliseconds and then switches the outer and inner labels of the remote active and standby PEs at the same time. VPN FRR solves the problem of switchover between inner labels. The switchover priority level of VPN FRR is lower than that of LDP/MPLS TE FRR. The time taken by VPN FRR to sense the fault is thus more than that taken by LDP/TE FRR.
Issue 03 (2009-03-10)
Page 156 of 200
6 Maintenance and Network Management System

About This Chapter
The following table shows the contents of this chapter. Section 6.1 Maintenance Features and Functions 6.2 Network Management Description This section describes the maintenance features and functions of the CX600. This section describes the network management services of the CX600.
Issue 03 (2009-03-10)
Page 157 of 200
6.1 Maintenance Features and Functions

6.1.1 System Configuration Mode
The CX600 provides two configuration modes, that is, command line configuration and NMS configuration. Command line configuration supports:
l l l
Local configuration through the console port Remote configuration through the AUX port with a Modem Remote configuration through Telnet
NMS configuration supports the SNMP-based NMS.
6.1.2 System Management and Maintenance

The CX600 provides the following system management and maintenance functions:
l
In-service board detection, hot swap detection, Watch Dog, board reset, control over running and debugging indicators, fan monitoring, power monitoring, active/standby switchover control, and version query Local and remote software upgrading and data loading, upgrade rollback, backup, storage, and removal Hierarchical user authority management, operation log management, online help and comment for command lines Multi-user operation Collection of multi-layer information, including port information, Layer 2 information, and Layer 3 information Hierarchical management, alarm classification, and alarm filtering
l l l l l
6.1.3 HGMP
The CX600 supports Huawei Group Management Protocol (HGMP), which is a cluster management protocol developed by Huawei. HGMP is used to group Layer 2 devices that are connected to the CX600 into a unified management domain, that is, a cluster. In addition, HGMP supports automatic collection of network topologies and provides integrated maintenance and management channels. In this manner, a cluster uses only one IP address for external communications, simplifying device management and saving IP addresses.
6.1.4 System Service and Status Tracking

The CX600 can track the system service and status as follows:
l l l l
Monitors the change of the state machine of routing protocols. Monitors the change of the state machine of MPLS LDP. Monitors the change of VPN-related state machine. Monitors the type of protocol packets sent by the NP to the CPU, and displays details about the packets with the debugging function.
Issue 03 (2009-03-10)
Page 158 of 200

l l l
Monitors and clears the statistics on abnormal packets. Displays notification when the processing of the abnormality takes effect. Collects the statistics on the resources used by each feature system.
6.1.5 System Test and Diagnosis

The CX600 provides debugging for running services. It can in-service record key events, packet processing, packet resolution, and state switchover at the specified period. This helps in device debugging and networking. You can enable or disable the debugging of a specific service (such as a routing protocol) and a specific interface (such as the routing protocol information on a specified interface) through the debugging command. The CX600 provides the trace function on system operation. It can in-service record key events such as task switchover, task interruption, queue read-and-write, and system abnormality. When the system is restarted after a fault occurs, you can read the trace information for fault location. You can enable or disable the trace function through the tracert command. In addition, you can query the CPU usage of the SRU/MPU and the LPU in real time. The debugging and trace functions of the CX600 classify information. The sensitive information of different classes is directed to different destinations of output based on the user configuration. The destinations of output include the console display, Syslog server, and SNMP Trap trigger alarm. The CX600 also provides the Network Quality Analysis (NQA) function. NQA measures the performance of each protocol that runs in the network and helps the network operator collect network running indexes, such as total delay of HTTP, delay of a TCP connection, delay of DNS resolution, rate of file transfer, delay of an FTP connection, and rate of wrong DNS resolution. By controlling these indexes, the network operator provides users with services of various grades and charges them differently. NQA is also an effective tool in diagnosing and locating faults in the network.
6.1.6 Upgrade Features

In-Service Upgrade
The router supports in-service upgrading and patching of the software. Thus, you can upgrade only the features that require modification.
System Upgrade
The system upgrade optimizes the upgrading process. You can use one command to complete the upgrading. Thus, you can save time. During the upgrading process, the progress is displayed. After the upgrading is complete, you can view the results.
Rollback
During the upgrading process, if the new system software cannot start the system, you can use the previous one that successfully started the system. The rollback function can protect services against the failure in the system upgrading.
Issue 03 (2009-03-10)
Page 159 of 200
License Contrul Policy

The License file dynamically controls the availability of product features. By License authorization, a new customer can purchase relevant functional modules of services and resources, lowering the cost; a sold customer can apply for a new License to expand the capacity and maintain functions. The CX600 is bearing more software features. Thus, the cost of software gradually constitutes a larger percentage of the total cost. This mode, however, cannot cater to users and carriers in the following aspects:
l l
Common users want to reduce the purchase cost. Users that need upgrade the devices want to be able to expand the capacity of devices and choose the service features as required.
To meet different requirements, the CX600 provides a management platform of license authorization through newly-developed software to provide flexible authorization of service features. This achieves the authorization of service features. In this mode,
l l
Common users can purchase the service features as required. The purchase cost is thus reduced. Users that need upgrade the devices can expand the capacity of devices and add new service features by applying for new licenses.
Provided with new software, the CX600 manages the features of L3VPN, MVPN, GRE tunnels, IPv6 tunnels, 6PE (IPv4 over IPv6) tunnels, Netstream, and PBB-TE.
6.1.7 Miscellaneous Features

The CX600 provides the following additional configuration features:
l l l l l
Hierarchical protection for configuration commands, ensuring that the unauthorized users can not access the router. Online help available if you type a "?". Various debugging information for network troubleshooting. DosKey-like function for running a history command. Fuzzy search for command lines. For example, you can enter the non-conflicting key words "disp" for the display command.
6.2 Network Management

6.2.1 NMS
The CX600 adopts the Huawei iManager N2000 NMS. It supports SNMP V1/V2c/V3 and the Client/Server model. The CX600 NMS can operate on multiple operating systems such as Windows NT/2000/XP and UNIX (SUN, HP, and IBM). The CX600 NMS provides graphic user interfaces in multiple languages. The iManager N2000 NMS can be seamlessly integrated with the NMS of other Huawei fixed network telecommunication equipment, for centralized management.
Issue 03 (2009-03-10)
Page 160 of 200
The N2000 NMS can also be integrated with other universal NMSs in the industry, such as HP OpenView, IBM NetView, What's up Gold, and SNMPc. This makes it possible to perform the unified management on the devices of multiple vendors. The N2000 NMS provides real-time management on the topology, fault, performance, configuration tool, equipment log, security and users, QoS policy, and VPN service. In addition, it can be used to download, save, modify, and upload configuration files, as well as upgrade the system software.
6.2.2 LLDP
At present, the Ethernet technology is extensively used in the Local Area Network (LAN) and Metropolitan Area Network (MAN). With the increasing demand for large-scale networks, the network management capabilities of Ethernet are in great demand. For example, the network management of Ethernet should address issues such as automatically obtaining topology of interconnected devices and conflicts in configurations on different devices. Recently, the Network Management System (NMS) software adopts the function of automated discovery to trace changes in topology. Most NMS software, however, can at best analyze the network layer topology and group devices to different IP subnets. The NMS provides data only about adding or deleting devices. The NMS cannot obtain information about the interfaces on a device, which are used to connect another device. That is, the NMS cannot locate a device or determine its operation mode. The Layer 2 Discovery (L2D) protocol can discover precise information about the interfaces situated on the devices and the interfaces that are used to connect other devices. The L2D protocol also displays the paths between the client, switch, router, application server, and network server. The preceding detailed information helps locate a network fault. The Link Layer Discovery Protocol (LLDP) is an L2D protocol defined in IEEE 802.1ab. LLDP specifies that the status information is stored on all the interfaces and the device can send its status to the neighbor stations. The interfaces can also send information about changes in the status to the neighbor stations as required. The neighbor stations then store the received information in the standard Management Information Base (MIB) of the Simple Network Management Protocol (SNMP). The NMS can search for the Layer 2 information in the MIB. As specified in IEEE 802.1ab, the NMS can also find the unreasonable Layer 2 configurations based on the information provided by LLDP. When LLDP runs on the devices, the NMS can obtain the Layer 2 information about all the devices it connects and the detailed network topology information. This expands the scope of network management. LLDP also helps find unreasonable configurations on the network and reports the configurations to the NMS. This removes error configurations timely.
Issue 03 (2009-03-10)
Page 161 of 200
7 Networking Applications
As shown in Figure 7-1, the metro Ethernet consists of the core layer, the edge layer, the aggregation layer, and the access layer. The core layer is responsible for the high-speed forwarding of service data. The edge layer and the aggregation layer serve as the access point of various services. The services access the network for forwarding through the BRAS, the centralized PE, or the aggregation node, based on the service type. The access layer is responsible for the user access, and the devices at the access layer include the DSLAM, the converged switch, AG, and NodeB. Figure 7-1 Metro Ethernet network diagram
Access Ethernet Aggregation Edge Core Application
Distribution node BRAS DSLAM CMTS Aggregafion Node VoD ES Distribution node AccSwitch PE P/PE
I n te rnet
Internet
P/PE P/PE SoftX
VoD CS
The aggregation layer device accesses and forwards the services through the IP or MPLS technologies. Individual services are accessed to the aggregation node through the DSLAM, and corporate services are converged at Layer 2 through a switch or are directly accessed to the aggregation node.
l
DSLAM: refers to the Digital Subscriber Line Access Multiplexer that accesses the individual services through the permanent virtual circuit (PVC). The DLSAM adds the VLAN or QinQ tag based on the types of users and services, and is generally connected to the aggregation node. Switch: refers to the access switch that converges the Layer 2 corporate services to the aggregation node. Aggregation node: refers to the distributed service node (PE). The aggregation node distinguishes the VLAN or QinQ user services, forwards Layer 3 services or VPN services, or transparently transmits services to the BRAS or the centralized PE through the IP or MPLS technologies.
l l
Issue 03 (2009-03-10)
Page 162 of 200

l
Distribution node: refers to the distribution node that converges the services in the metro Ethernet. The distribution node terminates the IP or MPLS technologies and transparently transmits the services to the BRAS or the centralized PE. BRAS: refers to a device that processes PPPoE login services of individual users. PE: refers to the centralized service node, which can also serve as the distribution node. PE accesses the services that should be converged and processed, such as centralized L3VPN services. P/PE: refers to the core forwarding node or the edge node on the back bone network. P or PE rapidly forwards the services or accesses the services to the backbone network.
l l
The CX600 is applicable for the aggregation node and the distribution node to guarantee the access of individual services and corporate services.
Individual Services
l
HSI service: The DSLAM adds QinQ tags to distinguish user services. The outer VLAN tag indicates the service type. The CX600 at the aggregation node transparently transmits the services to the distribution node through EOMPLS (VLL or VPLS). The distribution node can be the CX600 or the CX600. The distribution node terminates the transmission and then transparently transmits the QinQ data to the BRAS. VOD/VoIP: The CX600 at the aggregation node terminates the VLAN or QinQ tag added by the DSLAM, and forwards the services to Layer 3 network or accesses the services to L3VPN for forwarding. BTV: The CX600 at the aggregation node serves as the designated router (DR) of the Protocol Independent Multicast (PIM). The aggregation node receives the multicast data distributed through the PIM protocol, and then sends the data to the DSLAM through multicast VLAN. The user joins or withdraws a group through IGMP, and the hot channels send data to DR by static route.
Corporate Services
l l
Corporate dedicated line: The corporate dedicated line is connected to Layer 3 network through the CX600 at the aggregation node. E-LINE: The PW, an end-to-end L2VPN tunnel, is set up between the CX600 at the aggregation node and the peer end. The E-LINE services are transmitted to the peer end through different tunnels based on the VLAN or QinQ tags identified at the aggregation node. E-LAN: The CX600 at the aggregation node creates the VSI, and forwards the service data to different VSIs for forwarding after the VLAN or QinQ tag is identified. The service data can also be accessed to the 2-LAN services through H-PVLS, during which the VSI is created by the distribution node.
L3VPN: The services are accessed to the Virtual Route Forwarding (VRF) at the aggregation node, or accessed to the centralized service node for VRF forwarding through HoVPN.
Issue 03 (2009-03-10)
Page 163 of 200
8 Technical Specifications
About This Chapter
The following table shows the contents of this chapter. Section 8.1 Physical Specifications 8.2 System Configuration 8.3 Specifications of System Features and Service Performances Description This section describes the physical specifications of the CX600. This section describes the system configuration of the CX600. This section describes the specification of system features and service performance of the CX600.
Issue 03 (2009-03-10)
Page 164 of 200
8.1 Physical Specifications

Table 8-1 Physical specifications Item External dimensions (width x depth x height) Description
l
CX600-16 442 mm x 669 mm x 1600 mm (36 U) CX600-8: 442 mm x 669 mm x 886 mm (20 U) CX600-4: 442 mm x 669 mm x 442 mm (10 U) CX600-X3:DC input power module: 442 mm x 650 mm x 175 mm (4 U); AC input power module: 442 mm x 650 mm x 220 mm (5 U)
l l l
Installation Weight
Mounted in a 19-inch standard cabinet or an N68E-22/N68E-18 cabinet Fully configured:

l l l l
CX600-16: 250 kg CX600-8: 147 kg CX600-4: 87 kg CX600-X3:
DC power module: 36 kg AC power module: 46 kg Board weight: CX600-16:

l l l
MPU: 3.8 kg SFU: 3.0 kg LPU: 5.0 kg SRU: 3.8 kg SFU: 1.8 kg LPU: 5.0 kg MPU: 1.5 kg LPU: 5.0 kg
CX600-8/CX600-4:
l l l
CX600-X3:
l l
Maximum power consumption
CX600-16: 6800 W CX600-8: 2200 W CX600-X3: 900W 48 V 72 V to 38 V
DC input voltage
Rated voltage Maximum voltage range
Issue 03 (2009-03-10)
Page 165 of 200
Item AC input voltage Rated voltage range Maximum voltage range Environmental temperature Long-term Short-term Remark Storage temperature Relative environmental humidity Long-term Short-term
Description 200 V to 240 V 175 to 275 V 0C to 45C 5C to 55C Restriction on the temperature variation rate: 30C per hour 40C to 70C 5% to 85% RH, non-condensing 0% to 95% RH, non-condensing 0% to 95% RH, non-condensing Within 3000 meters Within 5000 meters
Relative storage humidity Altitude for permanent work Storage altitude
8.2 System Configuration

Table 8-2 System configuration list Item Processing unit BootROM SDRAM NVRAM Flash Description Main frequency: 1 GHz 1 MB 2 GB 512 KB 32 MB Remark
Issue 03 (2009-03-10)
Page 166 of 200
Item CF card
Description 1 GB
Remark The capacity can be extended. The CF card is used as a mass storage device to store data files.
l
The CF card on the SRU/MPU stores logs and is hot swappable. The CF card inside the SRU/MPU stores system files and is not hot swappable.
Switching capacity
CX600-16: 2.56 Tbit/s CX600-8: 640 Gbit/s CX600-4: 320 Gbit/s CX600-X3: 240 Gbit/s
Backplane capacity
CX600-16: 4 Tbit/s (bidirectional) CX600-8: 2 Tbit/s (bidirectional)s CX600-4: 1 Tbit/s (bidirectional) CX600-X3: 1.35 Tbit/s (bidirectional)
Interface capacity
CX600-16: 640 Gbit/s (bidirectional) CX600-8: 320 Gbit/s (bidirectional) CX600-4: 160 Gbit/s (bidirectional) CX600-X3: 120 Gbit/s (bidirectional)
Number of LPU slots
CX600-16: 16 CX600-8: 8 CX600-4: 4 CX600-X3: 3
LPU (optional)
Transmitting rate of the LPU Number of SRU/MPU slots
16 kbit/s
Bidirectional: sending packets to the SRU/MPU and receiving packets from the SRU/MPU
Issue 03 (2009-03-10)
Page 167 of 200
Item Transmitting rate of the SRU/MPU
Description 32 kbit/s
Remark Bidirectional: sending packets to the LPU and receiving packets from the LPU
8.3 Specifications of System Features and Service Performances

8.3.1 Specifications of System Features
Table 8-3 Specifications of the system features Feature Interworking Description LAN protocols Ethernet_II IEEE802.1Q IEEE802.1p Link layer protocols PPP, MP HDLC FR ATM IP over ATM RPR RRPP POS over FR Ethernet switching Basic VLAN features VLAN aggregation VLAN trunk Dynamic learning between VLAN members VLANIF interface Inter-VLAN routing VLAN translation VLAN Mapping STP/RSTP/MSTP QinQ VLAN Stacking
Issue 03 (2009-03-10)
Page 168 of 200
Feature Network protocol
Description IPv4 Static routes Dynamic unicast routing protocols:

l l l l
RIP-1/RIP-2 OSPF IS-IS BGP IGMP IGMP Snooping PIM-DM PIM-SM PIM-SSM MBGP MSDP
Multicast protocols:
l l l l l l l
Multicast VLAN Multicast VPN Multicast flow control Multicast CAC Routing policies NQA IPv6 IPv4-to-IPv6 transition technologies:
l l l l l l
Manually configured tunnel GRE Automatic tunnel 6to4 tunnel 6PE IPv4 over IPv6 tunnel
IPv6 static unicast routes IPv6 dynamic unicast routing

l l l l
BGP4+ RIPng OSPFv3 IS-ISv6 MLD PIM-IPv6-DM PIM-IPv6-SM PIM-IPv6-SSM
IPv6 Multicast protocols:

l l l l
Issue 03 (2009-03-10)
Page 169 of 200
Feature MPLS
Description MPLS basic functions MPLS forwarding MPLS LDP MPLS TE DS-TE MPLS QoS MPLS Uniform, Pipe, and Short Pipe MPLS OAM IPTN
VPN
L2VPN
VLL/PWE3 in Martini or Kompella mode VPLS QinQ HVPLS ATM IWF
L3VPN
MPLS/BGP VPN (as the PE router or the P router) HoVPN Multicast VPN Inter-VPN Carrier's carrier RRVPN Multi-role host
IPv6 L3VPN
IPv6 MPLS/BGP VPN (as the PE router or the P router) Inter-VPN Carrier's carrier
User management
Access user management
MSE AAA Domain RADIUS HWTACACS
Security
AAA
CHAP PAP RADIUS HWTACACS
Load balancing
Equal-cost load balancing Unequal-cost load balancing
Issue 03 (2009-03-10)
Page 170 of 200
Feature
Description Other security features SSH Local mirroring Remote mirroring Port traffic sampling Traffic control on the LPU and the SRU/MPU URPF Layer 2 limit ARP anti-attack Local Attack defense DHCP Snooping Lawful interception Hierarchical commands to defend against unauthorized users' login
Reliability
Hot backup
1:1 backup of SRU/MPUs 3+1 load balancing and backup of SFUs 1+1 backup of power modules 1+1 backup of the system management bus and data bus
GR
Protocol-level GR: IS-ISv4, OSPF, BGP4, LDP, and VPN System-level GR
Others
IP FRR LDP FRR TE FRR VLL FRR VPN FRR IP and VPN hybrid FRR VRRP BFD Dampening control to support Up/Down of interfaces Transmission alarm customization and suppression
QoS
Traffic classification
Simple traffic classification Complex traffic classification: based-on port; based on Layer 2, Layer 3, or Layer 4 packets Traffic policing and traffic shaping based on srTCM or trTCM DiffServ EF and AF services GTS
Traffic policing and shaping
Issue 03 (2009-03-10)
Page 171 of 200
Feature
Description Congestion management Congestion avoidance Policy-based routing QPPB PQ/WFQ WRED Route redirection, MPLS LSP explicit route distribution IP precedence Specific traffic behavior BGP accounting VPN QoS BGP identifies and classifies the routes through BGP traffic index to account the traffic on the basis of classification QoS that transmits the private network routes through BGP is an extension of QPPB in the L3VPN Supports traffic classification, traffic shaping, and queue scheduling in the L2VPN and L3VPN Supports the combination between VPN QoS and MPLS DiffServ/MPLS TE/MPLS DS-TE QinQ QoS 802.1p re-mark function supported by QinQ 802.1p and DSCP re-mark function during QinQ termination 802.1p and EXP re-mark function during QinQ termination ATM QoS FR QoS Simple traffic classification and forcible traffic classification Traffic shaping, traffic policing, congestion management, queue management, and FR fragmentation Two-level scheduling mode Level 1 scheduling ensures bandwidth for each user and level 2 scheduling ensures bandwidth for services of each user L2VPN HQoS L3VPN HQoS TE and DS-TE HqoS HQoS for users
HQoS
Issue 03 (2009-03-10)
Page 172 of 200
Feature Configuration management
Description Command line interface Local configuration through the console port Local or remote configuration through the AUX port Local or remote configuration through Telnet Local or remote configuration through SSH Hierarchical commands to defend against unauthorized users' login Detailed debugging information for network faults diagnosis Network test tools such as tracert and ping Supports the login to and management of other routers through Telnet FTP server and client functions to upload and download configuration files and applications TFTP client functions to upload and download configuration files and applications Upload and download configuration files and applications through the XModem protocol System logs Virtual file system Time service Time Zone Summer Time NTP server and NTP client In-service upgrade In-service upload In-service upgrade In-service patching Information center Provides three types of information: alarm, log, and debugging Provides eight levels of information: emergency, alert, critical, error, warning, notification, informational, and debugging Information can be output to the log host or user terminal; log information and alarm information can be output through the SNMP Agent or the buffer Network management Supports SNMP v1/v2c/v3 RMON NetStream Traffic statistics
Issue 03 (2009-03-10)
Page 173 of 200
8.3.2 Specifications of Service Performances

Table 8-4 Service performance specifications Attribute IP unicast Service Feature IPv4/IPv6 forwarding IPv4/IPv6 routing entries IPv4 FIB Routing convergence speed Number of IPv6 over IPv4 tunnels Number of 6PEs MPLS Label layers Number of LSPs Number of LDP neighbors MPLS FRR switching time Layer 2 features L2VPN MAC table (dynamic and static) VLL entries Number of VPLS VSIs Number of VPLS PWs Number of VRF QoS Number of traffic classification rules Number of ACLs CAR granularity Number of queues Levels of HQoS scheduling Packet buffer time Multicast Number of multicast routes Number of multicast static routes Number of multicast forwarding table entries Technical and Performance Specifications Line-rate forwarding of IPv4/IPv6 packets on high-speed interfaces 1600 K/600 K 1M 10K routing entries/s 8000 1000 4 100 K 63 K 50 ms 256 K 16 K 4K 16 K 2K 16 K/slot 8 K/slot 64 kbit/s 256 K (bidirectional)/LPU 5 levels 200 ms 8K 256 8K
Issue 03 (2009-03-10)
Page 174 of 200
A
ARP RFC1027 ATM RFC2225 RFC2226 RFC2364 RFC2515 RFC2684 BFD draft-ietf-bfd-base-05 draft-ietf-bfd-v4v6-1hop-05 draft-ietf-bfd-multihop-04 draft-ietf-bfd-generic-02 draft-ietf-bfd-mpls-02 BGP RFC1105 RFC1163 RFC1164 RFC1265 RFC1266 RFC 1267
Compliant Standards
A.1 Standards and Telecom Protocols

Using ARP to implement transparent subnet gateways
Classical IP and ARP over ATM IP Broadcast over ATM Networks PPP Over AAL5 Definitions of Managed Objects for ATM Management Multiprotocol Encapsulation over ATM Adaptation Layer 5
Bidirectional Forwarding Detection BFD for IPv4 and IPv6 (Single Hop) BFD for Multihop Paths Generic Application of BFD BFD For MPLS LSPs
Border Gateway Protocol BGP A Border Gateway Protocol (BGP) Application of the Border Gateway Protocol in the Internet BGP Protocol Analysis Experience with the BGP Protocol A Border Gateway Protocol 3 (BGP-3)
Issue 03 (2009-03-10)
Page 175 of 200
RFC 1268 RFC1269 RFC1364 RFC1397 RFC1403 RFC1654 RFC1655 RFC1656 RFC1771 RFC1772 RFC1773 RFC1774 RFC1863 RFC1930 RFC1965 RFC1966 RFC1997 RFC1998 RFC2270 RFC2283 RFC2385 RFC2439 RFC2519 RFC2545 RFC2547 RFC2796 RFC2842 RFC2858
Application of the Border Gateway Protocol in the Internet Definitions of Managed Objects for the Border Gateway Protocol:Version 3 BGP OSPF Interaction Default Route Advertisement in BGP2 and BGP3 Version of the Border Gateway Protocol BGP OSPF Interaction A Border Gateway Protocol 4 (BGP-4). Application of the Border Gateway Protocol in the Internet BGP-4 Protocol Document Roadmap and Implementation Experience (BGP-4) BGP basic functions support obsoletes RFC 1656 BGP-4 Protocol Analysis A BGP/IDRP Route Server alternative to a full mesh routing Guidelines for creation, selection, and registration of an Autonomous System (AS) Autonomous System Confederations for BGP BGP Route-Reflection BGP Community Attribute An Application of the BGP Community Attribute Using a Dedicated AS for Sites Homed to a Single Provider Multiprotocol Extensions for BGP-4 TCP MD5 BGP Route Flap Damping A Framework for Inter-Domain Route Aggregation BGP suppor IPV6 BGP/MPLS VPNs BGP Route Reflection Capabilities Advertisement with BGP-4 Multiprotocol Extensions for BGP-4
Issue 03 (2009-03-10)
Page 176 of 200
RFC2918 RFC3065 RFC3392 RFC3562 RFC4271 RFC4272 RFC4273 RFC4274 RFC4275 RFC4276 RFC4277 RFC4360 RFC4364 RFC4382 RFC4456 RFC4486 RFC4724 RFC4760 RFC4781 RFC4798 draft-ietf-ppvpn-rfc2547bis-01 draft-ietf-idr-restart-08 draft-ietf-idmr-bgp-mcast-attr-00 draft-ramachandra-bgp-ext-communities-04 draft-kato-bgp-ipv6-link-local-00 draft-ietf-idr-cap-neg-01 draft-ietf-mpls-bgp-mpls-restart-03 draft-ietf-l2vpn-vpls-bgp-02 draft-ietf-idr-rfc3065bis-06
Route Refresh Capability for BGP-4 Autonomous System Confederations for BGP Support BGP capabliteis advertisement Key Management Considerations for the TCP MD5 Signature Option A Border Gateway Protocol 4 (BGP-4) BGP Security Vulnerabilities Analysis Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4) BGP-4 Protocol Analysis BGP-4 MIB Implementation Survey BGP 4 Implementation Report Experience with the BGP-4 Protocol BGP Extended Communities Attribute BGP/MPLS IP Virtual Private Networks MPLS/BGP Layer 3 Virtual Private Network (VPN) Management nformation Base BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) Subcodes for BGP Cease Notification Message Graceful Restart Mechanism for BGP Multiprotocol Extensions for BGP-4 Graceful Restart Mechanism for BGP with MPLS Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE) BGP/MPLS VPN Arch Supprot Graceful Restart Mechanism for BGP-4 bgp support the multicast Extended Community Attribute BGP4+ Peering Using IPv6 Link-local Address Capabilities Negotiation with BGP4 Graceful Restart Mechanism for BGP with MPLS Autonomous System Confederations for BGP
Issue 03 (2009-03-10)
Page 177 of 200
draft-ooms-v6ops-bgp-tunnel Draft-marques-l3vpn-ibgp-01 Ethernet RFC0826
Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE) Internal BGP as PE-CE protocol draft-marques-l3vpn-ibgp-01
Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware (ARP) Standard for the transmission of IP datagrams over Ethernet networks A Standard for the Transmission of IP Datagrams over IEEE 802 Networks IEEE Standard for Local and Metropolitan Area Networks :Virtual Bridged Local Area Networks IEEE Standards for Local Area Networks: Logical Link Control (LLC) IEEE Standards for Local Area Networks: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access,Method and Physical Layer Specifications Link Aggregation Control Protocol
RFC0894 RFC1042 IEEE802.1q IEEE802.2 IEEE802.3
IEEE802.3af IPv6 RFC1886 RFC1887 RFC1981 RFC2373 RFC2374 RFC2375 RFC2452 RFC2454 RFC2460 RFC2461 RFC2462 RFC2463 RFC2464 RFC2465 RFC2466
DNS Extensions to Support IP version 6 An Architecture for IPv6 Unicast Address Allocation Path MTU Discovery for IP version 6 IP Version 6 Addressing Architecture An IPv6 Aggregatable Global Unicast Address Format IPv6 Multicast Address Assignments MIB for TCP6 MIB for UDP6 Internet Protocol, Version 6 (IPv6) Specification Neighbor Discovery for IP Version 6 (IPv6) IPv6 Stateless Address Auto configuration Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)Specification Transmission of IPv6 Packets over Ethernet Networks Management Information Base for IP Version MIB for ICMP6
Issue 03 (2009-03-10)
Page 178 of 200
RFC2470 RFC2472 RFC2529 RFC2893 RFC3056 RFC3363 RFC3513 RFC3542 RFC3587 RFC3775 draft-ietf-ngtrans-bgp-tunnel-04 draft-ietf-l3vpn-bgp-ipv6 ISIS RFC1142 ISO10598 RFC1195 RFC2104 RFC2763 RFC2966 RFC2973 RFC3277 RFC3373 RFC3567 RFC3719 RFC3784 RFC3786 RFC3787
Transmission of IPv6 Packets over Token Ring Networks IP Version 6 over PPP Transmission of IPv6 over IPv4 Domains without Explicit Tunnels Transition Mechanisms for IPv6 Hosts and Routers Connection of IPv6 Domains via IPv4 Clouds Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS). IP Version 6 Addressing Architecture Advanced Sockets API for IPv6 An Aggregatable Global Unicast Address Format Mobility Support in IPv6 Connecting IPv6 Domains across IPv4 Clouds with BGP BGP-MPLS VPN extension for IPv6 VPN
OSI IS-IS Intra-domain Routing Protocol IS-IS intra-domain routing protocol Use of OSI Is-Is for Routing in TCP/IP and Dual Environments HMAC: Keyed-Hashing for Message Authentication Dynamic Name-to-systemID mapping support route leak support Support IS-IS Mesh Groups IS-IS Transient Blackhole Avoidance Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication Recommendations for Interoperable Networks using IS-IS ISIS TE support Extending the Number of IS-IS LSP Fragments Beyond the 256 Limit Recommendations for Interoperable IP Networks using IS-IS
Issue 03 (2009-03-10)
Page 179 of 200
RFC3847 RFC4444 draft-ietf-isis-admin-tags-01 draft-ietf-isis-admin-tags-03 draft-ietf-isis-ipv6-04 draft-ietf-isis-wg-mib-20 draft-ietf-isis-wg-multi-topology-11 draft-ietf-isis-igp-p2p-over-lan-06 draft-ietf-isis-ipv6-06 draft-ietf-isis-link-attr-03 draft-ietf-isis-hmac-sha-03 draft-ietf-isis-wg-multi-topology-07 draft-ietf-bfd-v4v6-1hop-04 draft-ietf-isis-3way-03.tx MPLS RFC1186 RFC2205 RFC2209 RFC2210 RFC2430 RFC2702 RFC2747 RFC2961 RFC3031 RFC3034 RFC3035 RFC3036
Restart signaling for IS-IS Management Information Base for Intermediate System to Intermediate System (IS-IS) Policy Control Mechanism in ISIS Using Administrative Tags A Policy Control Mechanism in IS-IS Using Administrative Tags ISIS ipv6 support Management Information Base for IS-IS M-ISIS: Multi Topology (MT) Routing in IS-IS Point-to-point operation over LAN in link-state routing protocols Routing IPv6 with IS-IS Definition of an IS-IS Link Attribute sub-TLV IS-IS Generic Cryptographic Authentication M-ISIS: Multi Topology (MT) Routing in IS-IS BFD for IPv4 and IPv6 (Single Hop) Three-Way Handshake for IS-IS Point-to-Point Adjacencies
Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management Resource ReSerVation Protocol (RSVP) Version 1 Functional Specification Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules The Use of RSVP with IETF Integrated Services A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE). Requirements for Traffic Engineering Over MPLS RSVP Cryptographic Authentication RSVP Refresh Overhead Reduction Extensions Multiprotocol Label Switching Architecture Use of Label Switching on Frame Relay Networks Specification MPLS using LDP and ATM VC Switching LDP Specification
Issue 03 (2009-03-10)
Page 180 of 200
RFC3037 RFC3038 RFC3063 RFC3107 RFC3209 RFC3210 RFC3212 RFC3214 RFC3215 RFC3270 RFC3272 RFC3443 RFC3469 RFC3478 RFC3479 RFC3480 RFC3612 RFC4023 RFC4090 RFC4124 RFC4125 RFC4126
LDP Applicability VCID Notification over ATM link for LDP MPLS Loop Prevention Mechanism Support BGP carry Label for MPLS RSVP-TE Extensions to RSVP for LSP Tunnels
Applicability Statement for Extensions to RSVP for LSP-Tunnels Constraint-Based LSP setup using LDP (CR-LDP) LSP Modification Using CR-LDP LDP State Machine Multi-Protocol Label Switching (MPLS) Support of Differentiated Services Overview and Principles of Internet Traffic Engineering Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks Framework for Multi-Protocol Label Switching (MPLS)-based Recovery Graceful Restart Mechanism for LDP Fault Tolerance for the Label Distribution Protocol (LDP) Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol) Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP) Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE) 2005-12-07 Fast Reroute Extensions to RSVP-TE for LSP Tunnels Protocol Extensions for Support of DS-TE Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering & Performance Comparisons Removing a Restriction on the use of MPLS Explicit NULL Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks
RFC4182 RFC4197
Issue 03 (2009-03-10)
Page 181 of 200
RFC4221 RFC4377 RFC4379 RFC4446 RFC4447 RFC4448 RFC4558 RFC4561 draft-ietf-mpls-ldp-mtu-extensions-00 draft-ietf-mpls-rsvp-lsp-fastreroute-01 draft-ietf-mpls-ftn-mib-05.tx draft-ietf-mpls-lsr-mib-07 draft-ietf-mpls-te-mib-09 draft-ietf-mpls-lsp-ping-version-09 draft-ietf-tewg-diff-te-mam-04 draft-ietf-bfd-mpls-02 draft-ietf-bfd-mpls-03 draft-ietf-mpls-rfc3036bis-04 draft-ietf-mpls-ldp-typed-wildcard-00 draft-jork-ldp-igp-sync-01 draft-chen-mpls-ldpigp-syn-accurate-00 draft-ietf-ccamp-inter-domain-framework-04 draft-kompella-ppvpn-l2vpn-02 draft-rosen-ppvpn-l2vpn-00 draft-martini-l2circuit-trans-mpls-10
Multiprotocol Label Switching (MPLS) Management Overview Operations and Management (OAM) Requirements for MPLS Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3) Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) Encapsulation Methods for Transport of Ethernet over MPLS Networks Node-ID Based Resource Reservation Protocol (RSVP) Hello Definition of a Record Route Object (RRO) Node-Id Sub-Object MTU Signalling Extensions for LDP Fast Reroute Extensions to RSVP-TE for LSP Tunnels Multiprotocol Label Switching (MPLS) FEC-To-NHLFE (FTN) Management Information Bas Multiprotocol Label Switching (MPLS) Label Switch Router (LSR) Management Information Base Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures Maximum Allocation Bandwidth Constraints Model for Diff-Serv-aware MPLS Traffic Engineering BFD For MPLS LSPs BFD For MPLS LSPs LDP Specification LDP Typed Wildcard FEC LDP and IGP synchronization technique LDP and IGP synchronization technique Mechanisms for Inter-AS or Inter-Domain Traffic Engineering Layer 2 VPNs Over Tunnels An Architecture for L2VPNs Transport of Layer 2 Frames Over MPLS
Issue 03 (2009-03-10)
Page 182 of 200
draft-martini-l2circuit-encap-mpls-04 draft-ietf-avt-hc-over-mpls-protocol ITU-T Y.1710 ITU-T Y.1711 ITU-T Y.1720 MSTP IEEE802.1s IEEE802.1ad Multicast RFC1112 RFC2236 RFC2362 RFC3376 RFC3446
Encapsulation Methods for Transport of Layer 2 Frames Over IP and MPLS Networks Requirements for OAM functionality for MPLS networks Operation and maintenance mechanism for MPLS networks Protection switching for MPLS networks
Multiple Spanning Trees Virtual Bridged Local Area Networks - Amendment 4: Provider Bridges,QinQ
Host Extensions for IP Multicasting Internet Group Management Protocol, Version 2 Protocol Independent Multicast-Sparse Mode (PIM-SM):Protocol Specification Internet Group Management Protocol, Version 3 Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP) An Overview of Source-Specific Multicast (SSM) Multicast Source Discovery Protocol (MSDP) Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address Considerations for Internet Group Management Protocol (IGMP)and Multicast Listener Discovery (MLD) Snooping Switches Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast Source-Specific Protocol Independent Multicast in 232/8 Bootstrap Router (BSR) Mechanism for PIM Sparse Mode Source-Specific Multicast for IP Source-Specific Multicast for IP
RFC3569 RFC3618 RFC3973 RFC4541
RFC4601 RFC4604
RFC4608 draft-ietf-pim-sm-bsr-09 draft-ietf-ssm-arch-01 draft-ietf-ssm-overview-04
Issue 03 (2009-03-10)
Page 183 of 200
draft-ietf-pim-dm-new-v2-02 draft-ietf-pim-v2-dm-03 draft-rosen-vpn-mcast-08 draft-fenner-traceroute-ipm-01 draft-ietf-magma-snoop-12
Protocol Independent Multicast - Dense Mode (PIM-DM) Protocol Independent Multicast Version 2 Dense Mode Specification Multicast in MPLS/BGP VPNs A : traceroute facility for IP Multicast Considerations for Internet Group Management Protocol (IGMP)and Multicast Listener Discovery (MLD) Snooping Switches Multicast Source Discovery Protocol (MSDP)
draft-ietf-msdp-spec-13 NTP RFC1305 OSPF RFC1131 RFC1245 RFC1246 RFC1247 RFC1248 RFC1252 RFC1253 RFC1583 RFC1587 RFC1765 RFC1850 RFC2178 RFC2328 RFC2329 RFC2370 RFC2740 RFC2844 RFC3101 RFC3137 RFC3623 RFC3630 RFC4167
Network Time Protocol
(Version 3)
OSPF specification OSPF Protocol Analysis Experience with the OSPF Protocol OSPF Version 2 OSPF Version 2 Management Information Base OSPF Version 2 Management Information Base OSPF Version 2 Management Information Base OSPF Version 2 The OSPF NSSA Option OSPF Database Overflow OSPF Version 2 Management Information Base OSPF Version 2 OSPF Version 2 OSPF Standardization Report The OSPF Opaque LSA Option OSPF for IPv6 (OSPFv3) OSPF over ATM and Proxy-PAR The OSPF NSSA Option OSPF Stub Router Advertisement OSPF Graceful Restart Traffic Engineering Extensions to OSPF Graceful OSPF Restart Implementation Report
Issue 03 (2009-03-10)
Page 184 of 200
draft-katz-yeung-ospf-traffic-09 draft-ietf-tewg-diff-te-proto-02 draft-rosen-vpns-ospf-bgp-mpls-05 draft-rosen-ppvpn-ospf2547-area0-01 Draft-ietf-ospf-ospfv3-mib-04 draft-ietf-ospf-ospfv3-graceful-restart-04 draft-ietf-ospf-hmac-sha-00 PPP RFC1471 RFC1473 RFC1570 RFC1661 RFC1877 RFC1990 RFC1915 RFC1934 RFC1962 RFC1974 RFC1989 RFC1994 RFC2364 RFC2484 RFC2516 QoS RFC1144 RFC1349 RFC2309 RFC2386 RFC2474
Ospf TE support OSPF DS-TE support BGP/MPLS VPN support BGP/MPLS VPN support on AREA 0 OSPF for ipv6 mib OSPFv3 Graceful Restart OSPF HMAC-SHA Cryptographic Authentication
The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol. PPP LCP Extensions The Point-to-Point Protocol (PPP) PPP Internet Protocol Control Protocol Extensions for Name Server Addresses The PPP Multilink Protocol (MP) The PPP Connection Control Protocol Ascend's Multilink Protocol Plus (MP+) The PPP Compression Control PPP Stac LZS Compression Protocol PPP Link Quality Monitoring PPP Challenge Handshake Authentication Protocol (CHAP PPP over AAL5 (PPPoA) PPP LCP Internationalization Configuration Option A Method for Transmitting PPP Over Ethernet (PPPoE)
Compressing TCP/IP Headers for Low-Speed Serial Links Type of Service in the Internet Protocol Suite Recommendations on Queue Management and Congestion Avoidance in the Internet A Framework for QoS-based Routing in the Internet Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
Issue 03 (2009-03-10)
Page 185 of 200
RFC2475 RFC2597 RFC2598 RFC2697 RFC2698 RFC3246 RFC3247 RFC3260 RIP RFC1058 RFC1389 RFC2082 RFC2091 RFC2453 RFC2080 RFC2081 RMON RFC2021 RFC2819 RSTP IEEE802.1w Security RFC1244 RFC1492 RFC1519 RFC2267 RFC2338 RFC2365
An Architecture for Differentiated Services Assured Forwarding PHB Group An Expedited Forwarding PHB A Single Rate Three Color Marker. A Two Rate Three Color Marker An Expedited Forwarding PHB (Per-Hop Behavior) Supplemental Information for the New Definition of the EF PHB New Terminology and Clarifications for Diffserv
Routing Information Protocol (RIP) RIP Version 2 MIB Extension RIP-2 MD5 Authentication Triggered Extensions to RIP to Support Demand Circuits RIP Version 2 RIPng support RIPng Protocol Applicability Statement
Remote Network Monitoring Management Information Base Version 2 using SMIv2 Remote Network Monitoring Management Information Base
Rapid Reconvergence of Spanning Tree (RSTP)
Site Security Handbook An Access Control Protocol, Sometimes Called TACACS Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing Virtual Router Redundancy Protocol Administratively Scoped IP Multicast
Issue 03 (2009-03-10)
Page 186 of 200
RFC2787 RFC2827 RFC2865 RFC2866 RFC2867 RFC2868 RFC2869 RFC2903 RFC2904 RFC2906 RFC3164 RFC3575 RFC3619 RFC3768 RFC3826 draft-grant-tacacs-02 draft-ietf-syslog-transport-udp-09 draft-ietf-syslog-protocol-20 SNMP RFC1155 RFC1157 RFC1212 RFC1214 RFC1215 RFC1901 RFC1902 RFC1903
Definitions of Managed Objects for the Virtual Router Redundancy Protocol Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing. Remote Authentication Dial In User Service (RADIUS) RADIUS Accounting RADIUS Accounting Modifications for Tunnel Protocol Support RADIUS Attributes for Tunnel Protocol Support RADIUS Extensions Generic AAA Architecture AAA Authorization Framework AAA Authorization Requirements The BSD Syslog Protocol IANA Considerations for RADIUS (Remote Authentication Dial In User Service) Extreme Networks' Ethernet Automatic Protection Switching (EAPS) Version 1 Virtual Router Redundancy Protocol (VRRP) The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model The TACACS+ Protocol Version 1.78 Transmission of syslog messages over UDP The syslog Protocol
Structure and identification of management information for TCP/IP-based internets Simple Network Management Protocol (SNMP) Concise MIB definitions Definitions of Managed Objects for Data Link Switching using SMIv2. A Convention for Defining Traps for use with the SNMP Introduction to Community-based SNMPv2 Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2) Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)
Issue 03 (2009-03-10)
Page 187 of 200
RFC1904 RFC1905 RFC1906 RFC1907 RFC2570 RFC2571 RFC2572 RFC2573 RFC2574 RFC2575 RFC2576
Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2) Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2) Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2) Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2) Introduction to Version 3 of the Internet-standard Network Management Framework An Architecture for Describing SNMP Management Frameworks Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) SNMP Applications User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework Structure of Management Information Version 2 (SMIv2) Textual Conventions for SMIv2 Conformance Statements for SMIv2 An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks An Architecture for Describing Simple Network Management Protocol (SNMP) Management rameworks Message Processing and Dispatching for the Simple NetworkManagement Protocol SNMP) Simple Network Management Protocol (SNMP) Applications User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
RFC2578 RFC2579 RFC2580 RFC3410
RFC3411
RFC3412 RFC3413 RFC3414 RFC3415
Issue 03 (2009-03-10)
Page 188 of 200
RFC3416 RFC3418 RFC3512 SSHV2 RFC1918 RFC4245 RFC4250 RFC4251 RFC4252 RFC4253 RFC4254 RFC4344 System Management RFC1200 RFC1537 RFC1239 RFC1493 RFC2096 RFC2737 RFC3593 RFC3737 TCP/IP RFC0768 RFC0791 RFC0792 RFC0793 RFC0950 RFC1034
Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP). Management Information Base (MIB) for the Simple Network Management Protocol (SNMP). Configuring Networks and Devices with Simple Network Management Protocol (SNMP).
Address Allocation for Private Internets Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol Protocol Assigned Numbers The Secure Shell (SSH) Protocol Architecture The Secure Shell (SSH) Authentication Protocol The Secure Shell (SSH) Transport Layer Protocol The Secure Shell (SSH) Connection Protocol The Secure Shell (SSH) Transport Layer Encryption Modes
IAB official protocol standards Common DNS Data File Configuration Errors Reassignment of experimental MIBs to standard MIBs Definitions of Managed Objects for Bridges IP Forwarding Table MIB Entity MIB (Version 2). Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals IANA Guidelines for the Registry of Remote Monitoring (RMON) MIB modules
User Datagram Protocol INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION INTERNET CONTROL MESSAGE PROTOCOL TRANSMISSION CONTROL PROTOCOL Internet Standard Subnetting Procedure Domain Names - Concepts and Facilities
Issue 03 (2009-03-10)
Page 189 of 200
RFC1035 RFC1071 RFC1122 RFC1141 RFC1256 RFC1323 RFC1534 RFC1624 RFC1878 RFC2131 RFC2132 RFC2507 RFC2508 RFC2644 RFC2694 RFC3046 RFC3396 draft-fenner-traceroute-ipm-01 TELNET RFC0854 RFC0857 RFC0858 RFC1091 VPN RFC1701 RFC1702 RFC2764 RFC2784 RFC3809
Domain Names - Implementation and Specification Computing the Internet Checksum Requirements for Internet Hosts -- Communication Layers Incremental Updating of the Internet Checksum ICMP Router Discovery Messages TCP Extensions for High Performance Interoperation Between DHCP and BOOTP Computation of the Internet Checksum via Incremental Update Variable Length Subnet Table For IPv4 Dynamic Host Configuration Protocol DHCP Options and BOOTP Vendor Extensions IP Header Compression Compressing IP/UDP/RTP Headers for Low-Speed Serial Links Changing the Default for Directed Broadcasts in Routers DNS extensions to Network Address Translators (DNS_ALG) DHCP Relay Agent Information Option. Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4) A "traceroute" facility for IP Multicast
TELNET PROTOCOL SPECIFICATION TELNET ECHO OPTION TELNET SUPPRESS GO AHEAD OPTION Telnet Terminal-Type Option
Generic Routing Encapsulation (GRE) Generic Routing Encapsulation over IPv4 networks A Framework for IP Based Virtual Private Networks Generic Routing Encapsulation (GRE) Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN)
Issue 03 (2009-03-10)
Page 190 of 200
RFC3916 RFC3985 RFC4110 RFC4659 RFC4664 RFC4665 RFC4761 RFC4762 RFC4847 draft-ietf-ppvpn-rfc2547bis-01 draft-ietf-ppvpn-mpls-vpn-mib-04 draft-ietf-mpls-bgp-mpls-restart-05 draft-ietf-l3vpn-bgpvpn-auto draft-ietf-l3vpn-bgp-ipv6-03 draft-ietf-pwe3-hdlc-ppp-encap-mpls-09 draft-ietf-pwe3-vccv-10 draft-raggarwa-rsvpte-pw-00 draft-ietf-pwe3-vccv-10 draft-ietf-pwe3-oam-msg-map-04 draft-ietf-pwe3-vccv-10 draft-ietf-l2vpn-vpls-bgp-06 draft-ietf-l2vpn-vpls-ldp-02 draft-kompella-l2vpn-l2vpn-00
Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3). Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs). BGP-MPLS VPN Extension for IPv6 VPN Framework for Layer 2 Virtual Private Networks (L2VPNs) Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling Framework and Requirements for Layer 1 Virtual Private Networks BGP/MPLS VPN Arch BGP/MPLS VPN Management Information Using SMIv2 Base
Graceful Restart Mechanism for BGP with MPLS Using BGP as an Auto-Discovery Mechanism for Provider-provisioned VPNs BGP-MPLS VPN extension for IPv6 VPN Encapsulation Methods for Transport of PPP/HDLC Over MPLS Networks Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) Setup and Maintenance of Pseudowires using RSVP-TE Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) Pseudo Wire (PW) OAM Message Mapping Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) Virtual Private LAN Service Virtual Private LAN Services over MPLS pseudo wires created using BGP as signalling and auto-discovery protocol
Issue 03 (2009-03-10)
Page 191 of 200
draft-ietf-pwe3-MS-PW-arch
A.2 Electromagnetic Compatibility Standards

l l l l l l l l l l l
CISPR22 Class A CISPR24 EN55022 Class A EN50024 ETSI EN 300 386 Class A CFR 47 FCC Part 15 Class A ICES 003 Class A AS/NZS CISPR22 Class A GB9254 Class A VCCI Class A CNS 13438 Class A
A.3 Safty Standards

l l l l l l l l l l l l
IEC 60950-1 IEC/EN41003 EN 60950-1 UL 60950-1 CSA C22.2 No 60950-1 AS/NZS 60950.1 BS EN 60950-1 ITU-T K.20 GB4943 FDA rules, 21 CFR 1040.10 and 1040.11 IEC60825-1, IEC60825-2, EN60825-1, EN60825-2 GB7247
A.4 Environmental Standards

l l l l l l l l
RoHS GR-63 GB/T13543-92 ETS 300 019-2 GB2423-89 IEC 60068-2 GB 4789 ISTA
Issue 03 (2009-03-10)
Page 192 of 200
A.5 Other Standards

l l l l l l l l
ICNIRP Guideline 1999-519-EC EN 50385 OET Bulletin 65 IEEE Std C95.1 EN 60215 ITU-T K.27 ETSI EN 300 253
Issue 03 (2009-03-10)
Page 193 of 200
B
A AAA AAL5 AC ACL AF ANSI ARP ASBR ASIC ATM AUX
Acronyms and Abbreviations
Authentication, Authorization and Accounting ATM Adaptation Layer 5 Alternating Current Access Control List Assured Forwarding American National Standard Institute Address Resolution Protocol Autonomous System Boundary Router Application Specific Integrated Circuit Asynchronous Transfer Mode Auxiliary (port)
B BE BGP BGP4 Best-Effort Border Gateway Protocol BGP Version 4
C CAR CBR CE CHAP CoS Committed Access Rate Constant Bit Rate Customer Edge Challenge Handshake Authentication Protocol Class of Service
Issue 03 (2009-03-10)
Page 194 of 200
CPU CR-LDP D DC DHCP DNS DS
Center Processing Unit Constrained Route - Label Distribution Protocol
Direct Current Dynamic Host Configuration Protocol Domain Name Server Differentiated Services
E EACL EF EMC Enhanced Access Control List Expedited Forwarding ElectroMagnetic Compatibility
F FE FEC FIB FIFO FR FTP Fast Ethernet Forwarding Equivalence Class Forward Information Base First In First Out Frame Relay File Transfer Protocol
G GE GRE GTS Gigabit Ethernet Generic Routing Encapsulation Generic Traffic Shaping
H HA HDLC HTTP High availability High level Data Link Control Hyper Text Transport Protocol
I ICMP Internet Control Message Protocol
Issue 03 (2009-03-10)
Page 195 of 200
IDC IEEE IETF IGMP IGP IP IPoA IPTN IPv4 IPv6 IPX IS-IS ISP ITU
Internet Data Center Institute of Electrical and Electronics Engineers Internet Engineering Task Force Internet Group Management Protocol Interior Gateway Protocol Internet Protocol IP Over ATM IP Telephony Network IP version 4 IP version 6 Internet Packet Exchange Intermedia System-Intermedia System; Interim inter-switch Signaling Protocol International Telecommunication Standardization Sector Union Telecommunication
L L2TP LAN LCD LCP LDP LER LPU LSP LSR Layer 2 Tunneling Protocol Local Area Network Liquid Crystal Display Link Control Protocol Label Distribution Protocol Label switching Edge Router Line Processing Unit Label Switched Path Label Switch Router
M MAC MBGP MD5 MIB MP Media Access Control Multiprotocol Border Gateway Protocol Message Digest 5 Management Information Base Multilink PPP
Issue 03 (2009-03-10)
Page 196 of 200
MPLS MSDP MSTP MTBF MTTR MTU
Multi-protocol Label Switch; Multicast Source Discovery Protocol Multiple Spanning Tree Protocol Mean Time Between Failures Mean Time To Repair Maximum Transmission Unit
N NAT NLS NP NTP NVRAM Network Address Translation Network Layer Signaling Network Processor Network Time Protocol Non-Volatile Random Access Memory
O OSPF Open Shortest Path First
P PAP PE PFE PIC PIM-DM PIM-SM POP POS PPP PQ PT PVC PWE3 Password Authentication Protocol Provider Edge Packet Forwarding Engine Parallel Interference Cancellation Protocol Independent Multicast-Dense Mode Protocol Independent Multicast-Sparse Mode Point Of Presence Packet Over SDH/SONET Point-to-Point Protocol Priority Queue Protocol Transfer Permanent Virtual Channel Pseudo Wire Emulation Edge-to-Edge
Issue 03 (2009-03-10)
Page 197 of 200
Q QoS Quality of Service
R RADIUS RAM RED RFC RH RIP RMON ROM RP RPR RSVP RSVP-TE Remote Authentication Dial in User Service Random-Access Memory Random Early Detection Requirement for Comments Relative Humidity Routing Information Protocol Remote Monitoring Read Only Memory Rendezvous Point Resilient Packet Ring Resource Reservation Protocol RSVP-Traffic Engineering
S SAP SCSR SDH SDRAM SFU SLA SNAP SNMP SONET SP SPI4 SSH STM-16 SVC Service Advertising Protocol Self-Contained Standing Routing Synchronous Digital Hierarchy Synchronous Dynamic Random Access Memory Switch Fabric Unit Service Level Agreement SubNet Attachment Point Simple Network Management Protocol Synchronous Optical Network Strict Priority SDH Physical Interface Secure Shell SDH Transport Module -16 Switching Virtual Connection
Issue 03 (2009-03-10)
Page 198 of 200
T TCP TE TFTP TM ToS TP Transfer Control Protocol Traffic Engineering Trivial File Transfer Protocol Traffic Manager Type of Service Topology and Protection packet
U UBR UDP UNI UTP URPF Unspecified Bit Rate User Datagram Protocol User Network Interface Unshielded Twisted Pair Unicast Reverse Path Forwarding
V VBR-NRT VBR-RT VC VCI VDC VLAN VLL VPI VPLS VPN VRP VRRP Non-Real Time Variable Bit Rate Real Time Variable Bit Rate Virtual Circuit Virtual Channel Identifier Variable Dispersion Compensator Virtual Local Area Network Virtual Leased Line Virtual Path Identifier Virtual Private LAN Service Virtual Private Network Versatile Routing Platform Virtual Router Redundancy Protocol
W WAN WFQ WRED Wide Area Network Weighted Fair Queuing Weighted Random Early Detection
Issue 03 (2009-03-10)
Page 199 of 200
WRR
Weighted Round Robin
Issue 03 (2009-03-10)
Page 200 of 200

CX600 Product Description

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

CX600 Product Description

Caricato da

Copyright:

Formati disponibili

Product Description

Quidway CX600 Metro Services Platform

HUAWEI TECHNOLOGIES CO., LTD.

Huawei Technologies Co., Ltd.

Copyright Huawei Technologies Co., Ltd. 2009. All rights reserved.

Trademarks and Permissions

Quidway CX600 Metro Services Platform Product Description

About This Document

Quidway CX600 Metro Services Platform Product Description

2 System Architecture .................................................................................................... 19

3 Hardware Architecture ................................................................................................. 25

Quidway CX600 Metro Services Platform Product Description 3.6.5 SPU.................................................................................................................................. 47

5 Primary Service Features ............................................................................................ 59

6 Maintenance and Network Management System .................................................... 157

7 Networking Applications ........................................................................................... 162 8 Technical Specifications............................................................................................ 164

A Compliant Standards................................................................................................. 175

B Acronyms and Abbreviations ................................................................................... 194

Quidway CX600 Metro Services Platform Product Description

Quidway CX600 Metro Services Platform Product Description

1.2 Abundant Services

Quidway CX600 Metro Services Platform Product Description

1.3 High-Density LPUs

LAN and MAN Access interfaces:

WAN Access interfaces:

Quidway CX600 Metro Services Platform Product Description

Interface Type 10GE

Quantity per Slot 4

Quantity in the System CX600-16:32 CX600-8:16 CX600-4:8 CX600-X3:6

CX600-16:384 CX600-8:192 CX600-4:96 CX600-X3:72

CX600-16:1536 CX600-8:768 CX600-4:384 CX600-X3:288

CX600-16:384 CX600-8:192 CX600-4:96 CX600-X3:72

CX600-16:256 CX600-8:128 CX600-4:64 CX600-X3:48

CX600-16:16 CX600-8:8 CX600-4:4

CX600-16:64 CX600-8:32 CX600-4:16

CX600-16:128 CX600-8:64 CX600-4:32 CX600-X3:24

CX600-16:1536 CX600-8:768 CX600-4:384 CX600-X3:288

Quidway CX600 Metro Services Platform Product Description

Interface Type E3/T3/CT3

Quantity per Slot 16

Quantity in the System CX600-16:256 CX600-8:128 CX600-4:64 CX600-X3:48

1.4 Powerful Forwarding Capacity

1.5 Perfect QoS Mechanism

Quidway CX600 Metro Services Platform Product Description

1.6 Excellent Security Design

1.7 Good IPv4 and IPv6 Compatibility

Quidway CX600 Metro Services Platform Product Description

1.8 Compatibility and Extensibility

1.9 High Reliability

Quidway CX600 Metro Services Platform Product Description

Fault tolerance design

Quidway CX600 Metro Services Platform Product Description

Operation and maintenance center

Quidway CX600 Metro Services Platform Product Description

Quidway CX600 Metro Services Platform Product Description

2.1 Physical System Architecture

Figure 2-1 Physical architecture

Power distribution system

Functional host system

Fan heat dissipation system

Ethernet Network management subsystem

RTN indicates Return.

Quidway CX600 Metro Services Platform Product Description

Figure 2-2 Functional host system

Monitoring bus Management bus