NE40E X1&NE40E X2 Product Description

HUAWEI NetEngine40E Universal Service Router V600R002C03
Product Description
Issue Date
01 2010-03-01
HUAWEI TECHNOLOGIES CO., LTD.
Copyright Huawei Technologies Co., Ltd. 2010. 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 purchased products, services and features are stipulated by the contract made between Huawei and the customer. All or part of the products, services and features described in this document may not be within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information, and recommendations in this document are provided "AS IS" without warranties, guarantees or representations of any kind, either express or implied. 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.
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
Issue 01 (2010-03-01)
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E Universal Service Router Product Description
About This Document
About This Document

Purpose
This document describes the contents, the related version, the intended audience, the conventions, and the update history.
Related Versions
The following table lists the product versions related to this document. Product Name HUAWEI NetEngine40E Universal Service Router Version V600R002C03
Intended Audience
The intended audiences of this document are: On-site maintenance engineer Commissioning engineer System maintenance engineer
Organization
This document consists of nine chapters and is organized as follows. Chapter 1 Introduction 2 Architecture Description This chapter introduces the product positioning and features of the NE40E. This chapter describes the physical, logical, and software architecture of the NE40E.
Issue 01 (2010-03-01)
iii
About This Document
Chapter 3 Hardware Architecture 4 Link Features 5 Service Features 6 Application Scenarios 7 Operation and Maintenance 8 Technical Specifications 9 Compliant Standards A Acronyms and Abbreviations
Description This chapter describes the chassis, fans, power modules, and board types of the NE40E. This chapter describes the link features of the NE40E. This chapter describes the service features of the NE40E This chapter describes the networking applications of the NE40E. This chapter describes the operation and maintenance, and network management of the NE40E. This chapter describes the technical specifications of the NE40E. This chapter describes the compliant standards of the NE40E. This appendix lists the acronyms and abbreviations mentioned in this manual.
Conventions
Symbol Conventions
The symbols that may be found in this document are defined as follows. Symbol Description Indicates a hazard with a high level of risk, which if not avoided, will result in death or serious injury.
Indicates a hazard with a medium or low level of risk, which if not avoided, could result in minor or moderate injury. Indicates a potentially hazardous situation, which if not avoided, could result in equipment damage, data loss, performance degradation, or unexpected results. Indicates a tip that may help you solve a problem or save time. Provides additional information to emphasize or supplement important points of the main text.
iv
Issue 01 (2010-03-01)
About This Document
General Conventions
The general conventions that may be found in this document are defined as follows. Convention Times New Roman Boldface Italic Courier New Description Normal paragraphs are in Times New Roman. Names of files, directories, folders, and users are in boldface. For example, log in as user root. Book titles are in italics. Examples of information displayed on the screen are in Courier New.
Command Conventions
The command conventions that may be found in this document are defined as follows. Convention Boldface Italic [] { x | y | ... } [ x | y | ... ] { x | y | ... }* Description The keywords of a command line are in boldface. Command arguments are in italics. Items (keywords or arguments) in brackets [ ] are optional. Optional items are grouped in braces and separated by vertical bars. One item is selected. Optional items are grouped in brackets and separated by vertical bars. One item is selected or no item is selected. Optional items are grouped in braces and separated by vertical bars. A minimum of one item or a maximum of all items can be selected. Optional items are grouped in brackets and separated by vertical bars. Several items or no item can be selected. The parameter before the & sign can be repeated 1 to n times. A line starting with the # sign is comments.
[ x | y | ... ]* &<1-n> #
GUI Conventions
The GUI conventions that may be found in this document are defined as follows. Convention Boldface Description Buttons, menus, parameters, tabs, window, and dialog titles are in boldface. For example, click OK.
Issue 01 (2010-03-01)
About This Document
Convention >
Description Multi-level menus are in boldface and separated by the ">" signs. For example, choose File > Create > Folder.
Keyboard Operation
The keyboard operations that may be found in this document are defined as follows. Format Key Key 1+Key 2 Description Press the key. For example, press Enter and press Tab. Press the keys concurrently. For example, pressing Ctrl+Alt+A means the three keys should be pressed concurrently. Press the keys in turn. For example, pressing Alt, A means the two keys should be pressed in turn.
Key 1, Key 2
Mouse Operation
The mouse operations that may be found in this document are defined as follows. Action Click Double-click Drag Description Select and release the primary mouse button without moving the pointer. Press the primary mouse button twice continuously and quickly without moving the pointer. Press and hold the primary mouse button and move the pointer to a certain position.
Update History
Updates between document versions are cumulative. Therefore, the latest document version contains all updates made to previous versions.
Updates in Issue 01(2010-03-01)

First commercial release.
vi
Issue 01 (2010-03-01)
Contents
Contents
About This Document...................................................................................................................iii 1 Introduction.................................................................................................................................1-1
1.1 Positioning ....................................................................................................................................................1-1 1.2 Product Features............................................................................................................................................1-1
2 Architecture .................................................................................................................................2-1
2.1 Physical Architecture.....................................................................................................................................2-1 2.2 Logical Architecture......................................................................................................................................2-2 2.3 Software Architecture....................................................................................................................................2-3 2.4 Data Forwarding Process ..............................................................................................................................2-4
3 Hardware Architecture..............................................................................................................3-1
3.1 NE40E-X2.....................................................................................................................................................3-1 3.1.1 Chassis .................................................................................................................................................3-1 3.1.2 Heat Dissipation System ......................................................................................................................3-2 3.1.3 Power Supply System ..........................................................................................................................3-2 3.1.4 Introduction to the Board Cage ............................................................................................................3-3 3.1.5 MPU.....................................................................................................................................................3-4 3.1.6 NPUI-20...............................................................................................................................................3-5 3.2 NE40E-X1.....................................................................................................................................................3-6 3.2.1 Chassis .................................................................................................................................................3-6 3.2.2 Heat Dissipation System ......................................................................................................................3-6 3.2.3 Power Supply System ..........................................................................................................................3-7 3.2.4 Introduction to the Board Cage ............................................................................................................3-8 3.2.5 MPU.....................................................................................................................................................3-8 3.2.6 NPUI-20.............................................................................................................................................3-10 3.3 Subcard........................................................................................................................................................ 3-11
4 Link Features...............................................................................................................................4-1
4.1 Ethernet Link Features ..................................................................................................................................4-1 4.1.1 Basic Features ......................................................................................................................................4-1 4.1.2 Eth-Trunk .............................................................................................................................................4-1 4.2 CPOS Link Features......................................................................................................................................4-3 4.2.1 Channelization .....................................................................................................................................4-3
Issue 01 (2010-03-01)
vii
Contents
HUAWEI NetEngine40E Universal Service Router Product Description 4.2.2 PPP/TDM.............................................................................................................................................4-3
4.3 TDM Link Feature ........................................................................................................................................4-3 4.4 E1 Link Features ...........................................................................................................................................4-4 4.5 ATM E1 IMA ................................................................................................................................................4-5 4.6 E-Trunk .........................................................................................................................................................4-6 4.7 APS ...............................................................................................................................................................4-6
5 Service Features ..........................................................................................................................5-1

5.1 Ethernet Features...........................................................................................................................................5-1 5.1.1 Switched Ethernet Features..................................................................................................................5-2 5.1.2 Routed Ethernet Features .....................................................................................................................5-2 5.1.3 QinQ.....................................................................................................................................................5-3 5.1.4 RRPP Link Features.............................................................................................................................5-9 5.1.5 RSTP/MSTP ...................................................................................................................................... 5-11 5.1.6 BPDU Tunnel..................................................................................................................................... 5-11 5.2 IP Features...................................................................................................................................................5-12 5.2.1 IPv4/IPv6 Dual Stack.........................................................................................................................5-12 5.2.2 IPv4 Features .....................................................................................................................................5-12 5.2.3 IPv6 Features .....................................................................................................................................5-13 5.3 Routing Protocols........................................................................................................................................5-13 5.3.1 Fast Convergence of BGP Routes ......................................................................................................5-13 5.3.2 Unicast Routing .................................................................................................................................5-13 5.3.3 Multicast Routing...............................................................................................................................5-14 5.4 MPLS ..........................................................................................................................................................5-16 5.4.1 Basic Functions..................................................................................................................................5-16 5.4.2 MPLS TE ...........................................................................................................................................5-17 5.4.3 MPLS OAM.......................................................................................................................................5-20 5.5 VPN Features ..............................................................................................................................................5-20 5.5.1 Tunnel Policy .....................................................................................................................................5-21 5.5.2 VPN Tunnel .......................................................................................................................................5-21 5.5.3 MPLS L2VPN....................................................................................................................................5-21 5.5.4 BGP/MPLS L3VPN...........................................................................................................................5-27 5.5.5 L2VPN Accessing L3VPN.................................................................................................................5-35 5.5.6 MPLS HQoS ......................................................................................................................................5-37 5.6 IPTN Features .............................................................................................................................................5-41 5.7 QoS Features ...............................................................................................................................................5-42 5.7.1 DiffServ Model ..................................................................................................................................5-43 5.7.2 Traffic Classification..........................................................................................................................5-43 5.7.3 Traffic Policing ..................................................................................................................................5-44 5.7.4 Queue Scheduling ..............................................................................................................................5-45 5.7.5 Congestion Management....................................................................................................................5-46 5.7.6 Traffic Shaping...................................................................................................................................5-47
viii
Issue 01 (2010-03-01)
Contents
5.7.7 HQoS .................................................................................................................................................5-47 5.7.8 QPPB .................................................................................................................................................5-47 5.7.9 Ethernet QoS......................................................................................................................................5-48 5.8 Load Balancing ...........................................................................................................................................5-49 5.8.1 Equal-Cost Load Balancing ...............................................................................................................5-49 5.8.2 Unequal-Cost Load Balancing ...........................................................................................................5-49 5.9 Traffic Statistics...........................................................................................................................................5-50 5.9.1 URPF Traffic Statistics ......................................................................................................................5-50 5.9.2 ACL Traffic Statistics.........................................................................................................................5-51 5.9.3 CAR Traffic Statistics ........................................................................................................................5-51 5.9.4 HQoS Traffic Statistics ......................................................................................................................5-53 5.9.5 Interface-based Traffic Statistics ........................................................................................................5-53 5.9.6 VPN Traffic Statistics ........................................................................................................................5-53 5.9.7 TE Tunnel Traffic Statistics................................................................................................................5-53 5.10 Security Features.......................................................................................................................................5-53 5.10.1 Security Authentication....................................................................................................................5-54 5.10.2 RPF/URPF .......................................................................................................................................5-54 5.10.3 MAC Limit ......................................................................................................................................5-54 5.10.4 Unknown Traffic Suppression..........................................................................................................5-55 5.10.5 DHCP Snooping...............................................................................................................................5-55 5.10.6 Local Defense attack........................................................................................................................5-56 5.10.7 GTSM ..............................................................................................................................................5-59 5.10.8 ARP Attack Defense.........................................................................................................................5-59 5.10.9 Mirroring..........................................................................................................................................5-60 5.10.10 Lawful Interception........................................................................................................................5-63 5.11 Network Reliability ...................................................................................................................................5-64 5.11.1 Backup of Key Modules...................................................................................................................5-65 5.11.2 High Reliability of the LPU .............................................................................................................5-66 5.11.3 Transmission Alarm Customization and Suppression ......................................................................5-66 5.11.4 VRRP ...............................................................................................................................................5-66 5.11.5 GR ....................................................................................................................................................5-70 5.11.6 BFD..................................................................................................................................................5-71 5.11.7 Auto FRR .........................................................................................................................................5-73 5.11.8 NSR..................................................................................................................................................5-76
6 Application Scenarios ...............................................................................................................6-1

6.1 Application on a Metro Ethernet ...................................................................................................................6-1
7 Operation and Maintenance ....................................................................................................7-1

7.1 Benefits .........................................................................................................................................................7-1 7.1.1 System Configuration Mode ................................................................................................................7-1 7.1.2 System Management and Maintenance................................................................................................7-2 7.1.3 HGMP..................................................................................................................................................7-2
Issue 01 (2010-03-01)
ix
Contents
HUAWEI NetEngine40E Universal Service Router Product Description 7.1.4 System Service and Status Tracking ....................................................................................................7-2 7.1.5 System Test and Diagnosis...................................................................................................................7-2 7.1.6 In-Service Debugging ..........................................................................................................................7-3 7.1.7 Upgrade Features .................................................................................................................................7-3 7.1.8 GTL......................................................................................................................................................7-3 7.1.9 Miscellaneous Features ........................................................................................................................7-4
7.2 Network Management System ......................................................................................................................7-4
8 Technical Specifications ...........................................................................................................8-1

8.1 Physical Specifications..................................................................................................................................8-1 8.1.1 NE40E-X2 ...........................................................................................................................................8-1 8.1.2 NE40E-X1 ...........................................................................................................................................8-2 8.2 System Configuration....................................................................................................................................8-3 8.2.1 NE40E-X2 ...........................................................................................................................................8-3 8.2.2 NE40E-X1 ...........................................................................................................................................8-4 8.3 System Features ............................................................................................................................................8-4
9 Compliant Standards.................................................................................................................9-1
9.1 Standards and Telecom Protocols..................................................................................................................9-1 9.2 Electromagnetic Compatibility Standards ...................................................................................................9-20 9.3 Safety Standards..........................................................................................................................................9-20 9.4 Environmental Standards ............................................................................................................................9-21 9.5 Other Standards ...........................................................................................................................................9-21
A Acronyms and Abbreviations............................................................................................... A-1
Issue 01 (2010-03-01)
Figures
Figures
Figure 2-1 Physical architecture.........................................................................................................................2-1 Figure 2-2 Structure of the functional host system.............................................................................................2-2 Figure 2-3 Logical architecture ..........................................................................................................................2-2 Figure 2-4 Software architecture ........................................................................................................................2-3 Figure 2-5 Data forwarding process ...................................................................................................................2-4 Figure 3-1 Appearance and components of the NE40E-X2 ...............................................................................3-1 Figure 3-2 Direction of air flow in the NE40E-X2.............................................................................................3-2 Figure 3-3 Board cage of the NE40E-X2 ...........................................................................................................3-3 Figure 3-4 Appearance and components of the NE40E-X1 ...............................................................................3-6 Figure 3-5 Direction of air flow in the NE40E-X1.............................................................................................3-6 Figure 3-6 Board cage of the NE40E-X1 ...........................................................................................................3-8 Figure 4-1 TDM service .....................................................................................................................................4-4 Figure 4-2 Inverse multiplexing and de-multiplexing of ATM cells in IMA groups ..........................................4-5 Figure 4-3 E-Trunk.............................................................................................................................................4-6 Figure 5-1 Networking diagram of applying interface-based QinQ...................................................................5-4 Figure 5-2 Networking diagram of applying VLAN-based QinQ......................................................................5-5 Figure 5-3 Compatibility of the EType field in the TPID in the outer tag of QinQ packets...............................5-7 Figure 5-4 Networking diagram of applying multicast QinQ.............................................................................5-8 Figure 5-5 Network diagram of the VLAN swapping feature based on QinQ ...................................................5-9 Figure 5-6 Application of tangent RRPP rings in the MAN .............................................................................5-10 Figure 5-7 Structure of the IPv4/IPv6 dual stack .............................................................................................5-12 Figure 5-8 Networking diagram of applying LDP over TE..............................................................................5-19 Figure 5-9 Networking diagram of applying MPLS OAM ..............................................................................5-20 Figure 5-10 Networking diagram of a VLL .....................................................................................................5-22 Figure 5-11 VPLS networking..........................................................................................................................5-24 Figure 5-12 H-VPLS model .............................................................................................................................5-25
Issue 01 (2010-03-01)
xi
Figures
Figure 5-13 BGP/MPLS L3VPN......................................................................................................................5-28 Figure 5-14 Networking diagram of applying public network multicast..........................................................5-29 Figure 5-15 Networking diagram of applying VPN A multicast ......................................................................5-30 Figure 5-16 Networking diagram of applying VPN B multicast ......................................................................5-30 Figure 5-17 Networking diagram of the IPv6 VPN over the IPv4 public network ..........................................5-32 Figure 5-18 Basic architecture of HoVPN .......................................................................................................5-33 Figure 5-19 Implementation of a multi-role host .............................................................................................5-35 Figure 5-20 Traditional access network............................................................................................................5-36 Figure 5-21 L2VPN accessing the L3VPN ......................................................................................................5-37 Figure 5-22 L2VPN/L3VPN with MPLS TE ...................................................................................................5-39 Figure 5-23 L2VPN/L3VPN with MPLS DS-TE.............................................................................................5-40 Figure 5-24 VPN-based QoS on the network side in an L2VPN/L3VPN ........................................................5-41 Figure 5-25 Application scenario of the IPTN .................................................................................................5-42 Figure 5-26 Flowchart of traffic policing with CAR........................................................................................5-45 Figure 5-27 Networking diagram of traffic congestion ....................................................................................5-46 Figure 5-28 Networking diagram of applying QPPB .......................................................................................5-48 Figure 5-29 Networking diagram of 802.1p re-marking supported by QinQ...................................................5-49 Figure 5-30 URPF traffic statistics ...................................................................................................................5-51 Figure 5-31 Traffic statistics in traffic classification ........................................................................................5-52 Figure 5-32 CAR traffic statistics.....................................................................................................................5-52 Figure 5-33 Networking diagram of applying local mirroring .........................................................................5-61 Figure 5-34 Networking diagram of applying remote mirroring......................................................................5-62 Figure 5-35 Scenario of lawful interception.....................................................................................................5-63 Figure 5-36 Reliability technologies ................................................................................................................5-65 Figure 5-37 Networking diagram of VRRP......................................................................................................5-67 Figure 5-38 E-VRRP networking .....................................................................................................................5-69 Figure 5-39 Networking diagram of VRRP for IPv6........................................................................................5-70 Figure 5-40 Diagram of TE FRR link protection .............................................................................................5-74 Figure 5-41 Diagram of TE FRR node protection............................................................................................5-75 Figure 6-1 Networking diagram of a Metro Ethernet .........................................................................................6-1 Figure 6-2 2G/3G RAN solutions.......................................................................................................................6-3 Figure 6-3 Clock synchronization in IEEE 1588v2............................................................................................6-4
xii
Issue 01 (2010-03-01)
Tables
Tables
Table 1-1 Reliability implementation .................................................................................................................1-4 Table 3-1 Technical parameters of the fan module on the NE40E-X2 ...............................................................3-2 Table 3-2 Technical parameters of the DC power supply module on the NE40E-X2.........................................3-3 Table 3-3 Description of the slots on the NE40E-X2 .........................................................................................3-3 Table 3-4 Description of the interfaces on the MPU ..........................................................................................3-5 Table 3-5 Parameters of the NPUI-20 on the NE40E-X2 ...................................................................................3-5 Table 3-6 Technical parameters of the fan module on the NE40E-X1 ...............................................................3-7 Table 3-7 Technical parameters of the DC power supply module on the NE40E-X1.........................................3-7 Table 3-8 Description of the slots on the NE40E-X1 .........................................................................................3-8 Table 3-9 Description of the interfaces on the MPU ..........................................................................................3-9 Table 3-10 Parameters of the NPUI-20 on the NE40E-X2 ...............................................................................3-10 Table 3-11 Subcards supported by the NE40E-X2 and NE40E-X1.................................................................. 3-11 Table 5-1 Attack types and DHCP snooping working modes ...........................................................................5-56 Table 8-1 Parameters of the NE40E-X2 .............................................................................................................8-1 Table 8-2 Parameters of the NE40E-X1 .............................................................................................................8-2 Table 8-3 Default configurations on the NE40E-X2 ..........................................................................................8-3 Table 8-4 Default configurations on the NE40E-X1 ..........................................................................................8-4 Table 8-5 System features...................................................................................................................................8-4
Issue 01 (2010-03-01)
xiii
1 Introduction
1
About This Chapter
1.1 1.2 Positioning Product Features
Introduction
1.1 Positioning
Huawei NE40E-X1 and NE40E-X2 Metro Services Platform are a high-end network product used to access, converge, and transmit carrier-class Ethernet services on Fixed-Mobile Convergence (FMC) Metropolitan Area Networks (MANs). The NE40E-X1 and NE40E-X2 operate on the Versatile Routing Platform (VRP) operating system developed by Huawei and adopts the hardware-based forwarding and non-blocking data switching technology. The NE40E features carrier-class reliability, line-speed forwarding capability, perfect Quality of Service (QoS) mechanism, service processing capability, and good expansibility. The NE40E-X1 and NE40E-X2 feature strong capabilities in network access, Layer 2 switching, and transmission of Ethernet over MultiProtocol Label Switching (EoMPLS) services. With the support of diverse high-speed and low-speed interface types, the NE40E can bear triple play services, 2G services, 3G services, and LTE services. The NE40E can work in conjunction with the CX, NE, and ME series products developed by Huawei to build a hierarchical metro Ethernet that provides comprehensive services for customers.
1.2 Product Features

Comprehensive Services
The NE40E-X1 and NE40E-X2 provide the following features or solutions: Provides rich Layer 2 service features, such as Layer 2 VLAN, selective QinQ, QinQ termination, Rapid Ring Protection Protocol (RRPP), Spanning Tree Protocol (STP), Rapid Spanning Tree Protocol (RSTP), and Multiple Spanning Tree Protocol (MSTP). Provides IPv4/IPv6 unicast and multicast routing protocols and multicast Call Admission Control (CAC) to ensure carrier-class QoS for multicast, and supports complete MultiProtocol
Issue 01 (2010-03-01)
1-1
1 Introduction
Label Switching (MPLS), MPLS Traffic Engineering (TE), and IP Telephony Network (IPTN) solutions. Supports the Interior Gateway Protocol (IGP) fast convergency, multicast fast convergency, and Border Gateway Protocol (BGP) fast convergency. Provides comprehensive VPN services and strong QoS capabilities, such as L2VPN services, including Virtual Private LAN Service (VPLS), Hierarchical VPLS (HVPLS), and Virtual Leased Line (VLL), L3VPN, multicast VPN services, Huawei-patent Hierarchy of VPN (HoVPN) services, and multi-role host services. Provides Eth PWE3, TDM PWE3, 1588v2 clocks, Ethernet clocks, and adaptive clocks, and ensures network reliability and offers a complete IP backhaul solution by supporting E-automatic protection switching (E-APS), enhanced-Trunk (E-Trunk), and PW redundancy.
Diverse LPU Types

The NE40E-X1 and NE40E-X2 support the following interfaces: 155 M CPOS interface Low-speed E1 interface 10 M/100 M/1000 M/10 G Ethernet interface
Powerful Forwarding Capability

Adopting the hardware-based forwarding engine, the NE40E-X1 and NE40E-X2 support duplex line forwarding on all interfaces (including IPv4 forwarding, IPv6 forwarding, MPLS forwarding, and Layer 2 forwarding) and ACL-based line forwarding. The NE40E-X1 and NE40E-X2 also support the line rate forwarding of multicast services, which is achieved on the hardware by replicating packets at two levels: The NPU replicates multicast packets to the 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.
Perfect QoS Mechanism

The NE40E-X1 and NE40E-X2 support strong QoS capabilities, including: Traffic classification: The NE40E-X1 and NE40E-X2 classify traffic according to the Layer 2 rules, Layer 3 rules (IPv4 and IPv6), and MPLS rules. Diff-Serv: The NE40E-X1 and NE40E-X2 identify traffic priorities according to the DSCP, EXP, 802.1p, or IP priorities and then provides Diff-Serv. Traffic marking: The NE40E-X1 and NE40E-X2 can increase or decrease the priority of the specific traffic by changing its DSCP, EXP, 802.1p, or IP priority according to the pre-defined policy. Traffic policing: The NE40E-X1 and NE40E-X2 can control the traffic by monitoring all the traffic or specific traffic on a specified interface. Congestion avoidance: The NE40E-X1 and NE40E-X2 can use the tail-drop algorithm or WRED algorithm to discard packets in queues, thus preventing queue overflow. Congestion management: The NE40E-X1 and NE40E-X2 manage the congestion based on the Priority Queue (PQ) and Weighted Fair Queuing (WFQ) algorithms, realizing fair scheduling and preferentially guaranteeing services of high priorities. In addition, the
1-2
Issue 01 (2010-03-01)
1 Introduction
NE40E-X1 and NE40E-X2 provide five levels of scheduling to meet the requirements of different service combinations. The NE40E-X1 and NE40E-X2 support the PQ and WFQ, realizing fair scheduling and preferentially guaranteeing services of high priorities. The NE40E-X1 and NE40E-X2 support the three-level switching network based on Combined Input and Output Queuing (CIOQ), preventing head of line blocking. Flow-based scheduling: The NE40E-X1 and NE40E-X2 support DiffServ and Integrated Service (InterServ), facilitating the implementation of MPLS TE. PQ: The NE40E-X1 and NE40E-X2 support eight priority queues, preventing traffic of high priorities from being interrupted. The preceding QoS mechanism answers the demands of the IPTN and the multi-service-bearing IP network by providing differentiated delay, jitter, bandwidth, and packet loss ratio for services to guarantee the launch of carrier-class services such as Voice over IP (VoIP) and IPTV.
Excellent Security Design

The NE40E-X1 and NE40E-X2 take multiple security measures to protect the data of Internet Service Provider (ISP) networks and end users. The measures can protect against Denial of Service (DoS) attacks, illegal access, and overload on the control plane. A distributed structure adopted by the NE40E-X1 and NE40E-X2 guarante the separation of the data plane and the control plane, which ensures an industry-leading security performance. The NE40E-X1 and NE40E-X2 provide the following security features: Three user authentication modes: local authentication, RADIUS authentication, and HWTACACS authentication Hardware-based packet filtering and attack packet sampling, which guarantees high performance and high scalability Multiple authentication methods including plain text authentication and Message Digest 5 (MD5) authentication 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 based on the forwarding plane and control plane Anti-attack features, including:

Defends against TCP/IP spoofing attacks. Traces sources of attacks Defends the management and service planes. The NE40E-X1 and NE40E-X2 can control management packets and some service packets on physical interfaces. A physical interface can be specified as the management interface. Supports the application layer association. 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.
Supports lawful interception and Unicast Reverse Path Forwarding (URPF). URPF checks the source IP addresses of received packets and then discards illegal packets. Supports DHCP snooping and MAC address limit. Supports Generalized TTL Security Mechanism (GTSM). Supports ARP attack defense. Supports attack self suppression.
Issue 01 (2010-03-01)
1-3
1 Introduction
Complete IPv4/IPv6 Solutions

The NE40E-X1 and NE40E-X2 support the IPv4 and IPv6 dual protocol stacks and comprehensive IPv6 features, and offers a solution for smooth IPv4/IPv6 transition. Supports IPv6 over IPv4 tunnels. Supports the routing table and the forwarding table with large capacities, which enables the NE40E-X1 and NE40E-X2 to function as the VPN Provider Edge (PE) and meet the requirements of future service expansion. Supports the distributed forwarding of IPv4/IPv6 and Multiprotocol Label Switching (MPLS).
Good Compatibility and Scalability

The NE40E-X1 and NE40E-X2 have good compatibility and strong scalability. It supports smooth expansion. The backplane of the NE40E-X1 and NE40E-X2 have a large capacity, which meets the bandwidth requirement of a 40 G slot in the case of capacity expansion. The system adopts the flexibly programmable Network Processor (NP) to forward services. In this way, services can be added through software, realizing strong service scalability. Designed with separated Traffic Manager (TM) from the Packet Forwarding Engine (PFE), the NE40E-X1 and NE40E-X2 support two PFEs, the Application Specific Integrated Circuit (ASIC) and NP, to meet various application requirements.
High Reliability and Manageability

On the basis of the carrier-class design, the chassis of the NE40E-X1 and NE40E-X2 support hot swapping. It can be installed in an N68-22 or a standard 19-inch cabinet. In addition, the NE40E-X1 and NE40E-X2 provide a powerful monitoring system. It manages and maintains the entire system through the MPU. That is, the MPU manages, monitors, and maintains the boards, fans, and power distribution modules. With module-level shielding, the NE40E-X1 and NE40E-X2 carriy out the Electro Magnetic Compatibility (EMC) isolation between boards. The NE40E-X1 and NE40E-X2 fully meet the requirements for the high reliability of carrier-class and high-end routers. In terms of the system design and implementation, the NE40E-X1 and NE40E-X2 provide the following features as shown in Table 1-1 to ensure high reliability. Table 1-1 Reliability implementation Item System protection mechanism Description Hot-swappable boards, power modules, and fans. The MPUs work in 1:1 backup mode. The switching function of the NE40E-X1 and NE40E-X2 are implemented by the NPU. The NE40E-X1 and NE40E-X2 adopt the DC power supply modules in 1+1 backup mode.
1-4
Issue 01 (2010-03-01)
1 Introduction
Item
Description The key components such as the clocks and management buses work in backup mode. Protections against abnormalities The system can automatically restart and recover when abnormalities occur. The system can reset a faulty board and restore the services on the board.
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 Reliability Design 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.
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 Network Management System (NMS) alarm function.
Reliable upgrade
Supports online patching. Improves the upgrading methods of the device and supports In-Service Software Upgrade (ISSU), which shortens the duration of service interruption. Supports version rollback without interrupting services. Supports in-service upgrading of the BootROM. The backplane bus supports 8BIP 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, preventing data loss.
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.
Issue 01 (2010-03-01)
1-5
1 Introduction
Item Operation security
Description 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 protection against and confirmation prompts for misoperations, such as the confirmation prompts for the commands that may degrade the system performance.
Operation and maintenance center
The system adopts the generic integrated NMS platform developed by Huawei.
1-6
Issue 01 (2010-03-01)
2 Architecture
2
About This Chapter
2.1 2.2 2.3 2.4 Physical Architecture Logical Architecture Software Architecture Data Forwarding Process
Architecture
2.1 Physical Architecture

The physical architecture of the NE40E and NE40E-X2 are shown in Figure 2-1, including the following systems: Power distribution system Functional host system Heat dissipation system Network management system
Issue 01 (2010-03-01)
2-1
2 Architecture
Figure 2-1 Physical architecture
-48 V
-48 V RTN
Power distribution system
Functional host system Monitorbus
Heat dissipation system
Network management system

RTN: Return
Except the network management system (NMS), all the other systems are in the integrated cabinet. Among these systems, the power distribution system works in 1+1 backup mode. The following describes only the functional host system. The functional host system consists of the system backplane, MPU, NPUI-20, and subcard. The functional host system is mainly responsible for data processing, device monitoring, and device management, including the control and management of the power distribution system and heat dissipation system. The functional host system is connected to the NMS through NMS interfaces. Figure 2-2 illustrates the structure of the functional host system.
2-2
Issue 01 (2010-03-01)
2 Architecture
Figure 2-2 Structure of the functional host system

Control Bus PSU-A (Power Support Monitor Bus Unit) Control Bus Monitor Bus FAN GE/Console/ Bits/USB
-48 VA
-48 VB
Control Bus PSU-B (Power Support Monitor Bus Unit)
Control Bus Monitor Bus MPU (Master)
GE/Console/ Bits/USB
Backplane
Control Bus 2*10G NPU Monitor Bus Data Bus Control Bus 2*10G NPU Monitor Bus Data Bus
Control Bus
MPU Monitor Bus (Slave)
GE/Console/ Bits/USB
Control Bus Monitor Bus Data Bus PIC 0-7 GE/FE/E1 (Physical etc Interface Card)
The and NE40E-X1 has one NPU and four PIC subcards.
2.2 Logical Architecture

The logical architecture consists of the following planes: Data plane Control and management plane Monitoring plane Figure 2-3 shows the logical architecture .
Issue 01 (2010-03-01)
2-3
2 Architecture
Figure 2-3 Logical architecture
MPU
MPU
Monitoring plane
System monitoring unit
Control and management plane
Managemeng Managemeng unit unit Data plane Forwarding unit NPUI Forwarding unit NPUI
PIC managemeng unit
Data channel Pic *N
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, and 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, and monitors the temperature and controls the fan. In this manner, 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 other parts.
2.3 Software Architecture

Figure 2-4 shows the software architecture of the NE40E.
2-4
Issue 01 (2010-03-01)
2 Architecture
Figure 2-4 Software architecture
Power monitoring
Fan monitoring
SNMP
RPS Active
RPS Standby IPC
FSU
FSU
FSU
EFU LPU
EFU LPU
EFU LPU
In terms of the software, the NE40E consists of the Routing Process System (RPS), power monitoring module, fan monitoring module, Forwarding Support Unit (FSU), and Express Forwarding Unit (EFU). The RPS is the control and management module that runs on the MPU. The RPSs of the active MPU and the standby 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 RPS includes IPOS software, VRP software, and product adapter software. The FSU implements the functions of the link layer and IP protocol stacks on interfaces. The EFU performs hardware-based IPv4/IPv6 forwarding, multicast forwarding, MPLS forwarding, and statistics.
Issue 01 (2010-03-01)
2-5
2 Architecture
2.4 Data Forwarding Process

Figure 2-5 Data forwarding process
PIC Datagram
Processing on the incoming interface Upstream traffic classification
Datagram
Processing on the outgoing interface Downstream traffic classification IPv4 unicast IPv4 multicast MPLS IPv6 Packet encapsulation and forwarding in the downstream
PFE
IPv4 unicast Searching the IPv4 multicast routing table to MPLS forward packets IPv6 MAC
QoS in the upstream
Congestion management Queue scheduling
Queue scheduling Congestion management
QoS in the downstream
TM
Packet fragmentation
Multicast replication
Packet reassembly
Micro cell SFU
Micro cell
As shown in Figure 2-5, the Packet Forwarding Engine (PFE) adopts the Network Processor (NP) or Application Specific Integrated Circuit (ASIC) to search the routing table and forward packets at a high speed. External memories include the Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), and Net Search Engine (NSE). The SRAM stores forwarding entries; the DRAM stores packets; the NSE performs non linear searching. The data forwarding process can be classified as the upstream and downstream processes according to data flow directions. Upstream process: Packets are encapsulated in frames on the Physical Interface Card (PIC) and then sent to the PFE. On the incoming interface, packets are decapsulated and packet types are identified. Then, traffic classification is performed according to the configurations
2-6
Issue 01 (2010-03-01)
2 Architecture
on the incoming interface. In addition, information about scheduling priorities are carried in the packets sent to the Traffic Manager (TM ) for traffic scheduling. Then, the Forwarding Information BASE (FIB) is searched to forward packets. For example, to forward an IPv4 unicast packet, the FIB is searched for the outgoing interface and the next hop according to the destination IP address of the packet. Finally, the searching results and the packets are sent to the TM. Downstream process: According to the packet types parsed in the upstream process and the outgoing interface, the packets are encapsulated through the link layer protocol and stored in corresponding queues. For an IPv4 packet whose outgoing interface is an Ethernet interface, the MAC address needs to be obtained according to the next hop. Then, the outgoing traffic can be classified according to the configurations on the outgoing interface. Finally, the packets are encapsulated with the new Layer 2 header on the outgoing interface and are then sent to the PIC.
Issue 01 (2010-03-01)
2-7
3 Hardware Architecture
3
About This Chapter
3.1 3.2 3.3 NE40E-X2 NE40E-X1 Subcard
Hardware Architecture
3.1 NE40E-X2
3.1.1 3.1.2 3.1.3 3.1.4 3.1.5 3.1.6 Chassis Heat Dissipation System Power Supply System Introduction to the Board Cage MPU NPUI-20
3.1.1 Chassis
The NE40E-X2 is of 442 mm x 220 mm x 222 mm (W x D x H), and can be mounted in an N63E cabinet, a standard 19-inch cabinet, or a 23-inch North American open rack. Figure 3-1 illustrates the appearance and components of the NE40E-X2.
Issue 01 (2010-03-01)
3-1
Figure 3-1 Appearance and components of the NE40E-X2
3.1.2 Heat Dissipation System

In the NE40E-X2, seen from the front side, the air flow passes through the chassis in a left-to-right direction. Figure 3-2 Direction of air flow in the NE40E-X2
Table 3-1 Technical parameters of the fan module on the NE40E-X2 Parameter Weight Maximum power consumption Value 1.7 kg 180 W
3-2
Issue 01 (2010-03-01)
Parameter Maximum wind pressure Maximum air volume Noise
Value 477.2 Pa
64.4 CFM 64.3 dB
3.1.3 Power Supply System

The NE40E-X2 uses the DC power supply modules (CX67PSUA), which work in 1+1 backup mode. The power supply modules provide power for the MPU, NPU, subcards, and fan modules. The power supply modules are installed in the two slots on the top of the chassis. When one power module is faulty or pulled out, the other one can still supply sufficient power for the entire system. The DC power supply module provides the following protections: Protection against overcurrent of output power Protection against overvoltage of output power Protection against under-voltage of input power Protection against over-temperature Protection against short circuit Alarm function Table 3-2 Technical parameters of the DC power supply module on the NE40E-X2 Item Dimensions (W x D x H) Weight Input voltage range Maximum input current Maximum output power Current of the customer's air circuit breaker Parameter 196 mm x 184 mm x 19.8 mm 1 kg 72 V DC to 38 V DC 24.5 A 905 W 32 A
At present, the NE40E-X2 supports the DC power supply only.
Issue 01 (2010-03-01)
3-3
3.1.4 Introduction to the Board Cage

The NE40E-X2 has 15 slots, which can be equipped with two NPUI-20s, two MPUs, eight subcards, one fan module, and two DC power supply modules, as illustrated in Figure 3-3. Figure 3-3 Board cage of the NE40E-X2
13 PWR 11 PIC 9 PIC 15 FAN 8 NPU 7 NPU 5 PIC 3 PIC 1 MPU
14 PWR 12 PIC 10 PIC
6 PIC 4 PIC 2 MPU
Table 3-3 Description of the slots on the NE40E-X2 Slot Number Slots 3 to 6, slots 9 to 12 Slots 7 and 8 Slots 1 and 2 Slots 13 and 14 Slot 15 Quanti ty 8 Remarks Indicates the slots for subcards. Slots 5, 6, 9, and 10 can be equipped with both high-speed and low-speed subcards. Slots 3, 4, 11, and 12 support only low-speed subcards. Indicates the slots for the NPUs. Indicates the slots for the MPUs. Two MPUs work in 1:1 backup mode. Indicates the slots for DC power supply modules. Two DC power supply modules work in 1+1 backup mode. Indicates the slot for the fan module.
2 2 2 1
Low-speed subcards refers to the subcards whose single port rate is lower than 1 Gbit/s; high-speed subcards refers to the subcards whose single port rate is higher than or equal to 1 Gbit/s
3.1.5 MPU
The NE40E-X2 can work with a single MPU or two MPUs in backup mode. When the NE40E-X2 is equipped with two MPUs, the master MPU works in the active state and the slave MPU is in the standby state. You cannot access the management interface of the slave MPU, or configure commands on the console or the AUX interface of the slave MPU. The slave MPU exchanges information (including Heartbeat messages and backup data) only
3-4 Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. Issue 01 (2010-03-01)
with the master MPU. Data consistency between the master and slave MPUs is ensured through high reliability mechanisms such as batch backup and real-time backup. After the master-slave switchover, the slave MPU immediately takes over the master MPU. The default master MPU is configurable. During the start process, the MPU that you set wins the competition and becomes the master MPU. MPUs support two switchover modes: failover and manual switchover. The failover is triggered by serious faults or resetting of the master MPU. The manual switchover is triggered by commands run on the console interface. The MPU integrates multiple functional units. By integrating the system control and management unit, system switching unit, clock unit, and management and maintenance unit, the MPU provides the functions of the control plane, switching plane, and maintenance plane. The function and hardware implementation of each integrated part are separated from each other. The following describes the function and hardware implementation of the MPU. System control and management unit The MPU is mainly responsible for processing routing protocols. In addition, the MPU broadcasts and filters routing packets, downloads routing policies from the policy server, manages the NPUI-20s, and communicates with the NPUI-20s. The MPU implements outband communication between boards. The MPU manages and carries out communication between the NPUI-20s and slave MPU through the outband management bus. The MPU is also responsible for data configuration. The system configuration data, booting file, upgrade software, and system logs are stored on the MPU. The CF card on the MPU stores system files, configuration files and log, and does not support hot swap. The MPU manages and maintains the device through management interfaces such as the serial interface and the network interface. System clock unit The system clock unit of the MPU provides LPUs with reliable and synchronous SDH clock signals. The MPUs of the NE40E-X2 support the clock that complies with IEEE 1588v2. System maintenance unit The system maintenance unit of the MPU collects monitoring information, remotely or locally tests system units, or performs in-service upgrade of system units. Through the Monitorbus, the MPU collects the operation data periodically. The MPU produces controlling information, such as detecting the board presence and adjusting the fan speed. Through the load bus, the MPU tests or in-service upgrades system units from the far end or the near end.
The MPU works in 1+1 hot backup mode, improving the system reliability.
Table 3-4 Description of the interfaces on the MPU Interface Name Ethernet interface (10M/100M/10 00M Base-TX auto-sensing) Interface Type RJ45 Description One Ethernet interface, for system maintenance
Issue 01 (2010-03-01)
3-5
Interface Name Console interface AUX interface
Interface Type RJ45 RJ45
Description One console interface, used to connect to the console for on-site configurations One AUX interface, used to connect to a Modem for remote maintenance through a dial-up connection One hot swappable USB2.0 interface, for software upgrade or temporary data access Two RJ45 interfaces, for receiving and sending 1588v2 time signals -
USB interface CLK RS485 interface
USB 2.0 RJ45 RJ45
3.1.6 NPUI-20
The NPUI-20 has bi-directional 20 Gbit/s forwarding capability. All subcards exchange data through the NPUI-20s. Each NPUI-20 provides two 10G Ethernet optical interfaces, supports WAN and LAN modes, and can be installed with XFP optical modules. The NE40E-X2 can be equipped with two NPUI-20s, working in back-to-back mode. In this mode, the NPUI-20 in slot 7 is connected to the subcards in slots 3, 4, 5, and 6; the NPUI-20 in slot 8 is connected to the subcards in slots 9, 10, 11, and 12. The NPUI-20 consists of the following units: Control and management unit Through the GE channel connecting the MPU and the NPUI-20, the MPU manages the LPUs and subcards and transmits routing protocol data. Data forwarding unit Working as the forwarding core of the system, the NPUI-20 is connected to all subcards through data channels. Each NPUI-20 provides two 10G Ethernet optical interfaces, supports WAN and LAN modes, and can be installed with XFP optical modules. Table 3-5 Parameters of the NPUI-20 on the NE40E-X2 Item Forwarding capability Interface Description Bi-directional 20 Gbit/s forwarding capability Two 10G Ethernet XFP optical interfaces, supporting WAN and LAN modes Remarks -
3-6
Issue 01 (2010-03-01)
3.2 NE40E-X1
3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 Chassis Heat Dissipation System Power Supply System Introduction to the Board Cage MPU NPUI-20
3.2.1 Chassis
The NE40E-X1 is of 442 mm x 220 mm x 132 mm (W x D x H), and can be mounted in an N63E cabinet, a standard 19-inch cabinet, or a 23-inch North American open rack. Figure 3-4 illustrates the appearance and components of the NE40E-X1. Figure 3-4 Appearance and components of the NE40E-X1
3.2.2 Heat Dissipation System

In the NE40E-X1, seen from the front side, the air flow passes through the chassis in a left-to-right direction. Figure 3-5 Direction of air flow in the NE40E-X1
Issue 01 (2010-03-01)
3-7
The NE40E-X1 supports six fan modules working in N+1 mode. In this mode, the NE40E-X1 operates properly even if a fan module fails. Table 3-6 Technical parameters of the fan module on the NE40E-X1 Parameter Weight Maximum power consumption Maximum wind pressure Maximum air volume Noise Value 1.1 kg 120 W
477.2 Pa
64.4 CFM 64.3 dB
3.2.3 Power Supply System

The NE40E-X1 uses the DC power supply module CX67PSUAs, which work in 1+1 backup mode. The power supply modules provide power for the MPU, NPUI-20, subcards, and fan modules. The power supply modules are installed in the two slots on the top of the chassis. When one power module is faulty, the other one can still supply sufficient power for the entire system. The DC power supply module provides the following protections: Protection against overcurrent of output power Protection against overvoltage of output power Protection against under-voltage of input power Protection against over-temperature Protection against short circuit Alarm function Table 3-7 Technical parameters of the DC power supply module on the NE40E-X1 Item Dimensions (W x D x H) Weight Input voltage range Maximum input current Maximum output power Current of the customer's air circuit breaker Parameter 196 mm x 184 mm x 19.8 mm 1 kg 72 V DC to 38 V DC 24.5 A 905 W 32 A
3-8
Issue 01 (2010-03-01)
At present, the NE40E-X1 supports the DC power supply only.
3.2.4 Introduction to the Board Cage

The NE40E-X1 has 10 slots, which can be equipped with one NPUI-20s, two MPUs, four subcards, one fan module, and two DC power supply modules, as illustrated in Figure 3-6. Figure 3-6 Board cage of the NE40E-X1
8 PWR 6 MPU 10 FAN 4 PIC 2 PIC 1 NPU
9 PWR 7 MPU 5 PIC 3 PIC
Table 3-8 Description of the slots on the NE40E-X1 Slot Number Slot 1 Slots 2, 3, 4, and 5 Quanti ty 2 4 Remarks Indicates the slot for the NPU. Indicates the slots for subcards. These slots can be equipped with both high-speed subcards and low-speed subcards. Indicates the slots for the MPUs. Two MPUs work in 1:1 backup mode. Indicates the slots for DC power supply modules. Two DC power supply modules work in 1+1 backup mode. Indicates the slot for the fan module.
Slots 6 and 7 Slots 8 and 9 Slot 10
2 2 1
Low-speed subcards refers to the subcards whose single port rate is lower than 1 Gbit/s; high-speed subcards refers to the subcards whose single port rate is higher than or equal to 1 Gbit/s
3.2.5 MPU
The NE40E-X2 can work with a single MPU or two MPUs in backup mode. When the NE40E-X2 is equipped with two MPUs, the master MPU works in the active state and the slave MPU is in the standby state. You cannot access the management interface of the slave MPU, or configure commands on the console or the AUX interface of the slave MPU. The slave MPU exchanges information (including Heartbeat messages and backup data) only with the master MPU. Data consistency between the master and slave MPUs is ensured
Issue 01 (2010-03-01) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 3-9
through high reliability mechanisms such as batch backup and real-time backup. After the master-slave switchover, the slave MPU immediately takes over the master MPU. The default master MPU is configurable. During the start process, the MPU that you set wins the competition and becomes the master MPU. MPUs support two switchover modes: failover and manual switchover. The failover is triggered by serious faults or resetting of the master MPU. The manual switchover is triggered by commands run on the console interface. The MPU integrates multiple functional units. By integrating the system control and management unit, system switching unit, clock unit, and management and maintenance unit, the MPU provides the functions of the control plane, switching plane, and maintenance plane. The function and hardware implementation of each integrated part are separated from each other. The following describes the function and hardware implementation of the MPU. System control and management unit The MPU is mainly responsible for processing routing protocols. In addition, the MPU broadcasts and filters routing packets, downloads routing policies from the policy server, manages the NPUI-20s, and communicates with the NPUI-20s. The MPU implements outband communication between boards. The MPU manages and carries out communication between the NPUI-20s and slave MPU through the outband management bus. The MPU is also responsible for data configuration. The system configuration data, booting file, upgrade software, and system logs are stored on the MPU. The CF card on the MPU stores system files, configuration files and log, and does not support hot swap. The MPU manages and maintains the device through management interfaces such as the serial interface and the network interface. System clock unit The system clock unit of the MPU provides LPUs with reliable and synchronous SDH clock signals. The MPUs of the NE40E-X2 support the clock that complies with IEEE 1588v2. System maintenance unit The system maintenance unit of the MPU collects monitoring information, remotely or locally tests system units, or performs in-service upgrade of system units. Through the Monitorbus, the MPU collects the operation data periodically. The MPU produces controlling information, such as detecting the board presence and adjusting the fan speed. Through the load bus, the MPU tests or in-service upgrades system units from the far end or the near end.
The MPU works in 1+1 hot backup mode, improving the system reliability.
Table 3-9 Description of the interfaces on the MPU Interface Name Ethernet interface (10M/100M/10 00M Base-TX auto-sensing) Interface Type RJ45 Description One Ethernet interface, for system maintenance
3-10
Issue 01 (2010-03-01)
Interface Name Console interface AUX interface
Interface Type RJ45 RJ45
Description One console interface, used to connect to the console for on-site configurations One AUX interface, used to connect to a Modem for remote maintenance through a dial-up connection One hot swappable USB2.0 interface, for software upgrade or temporary data access Two RJ45 interfaces, for receiving and sending 1588v2 time signals -
USB interface CLK RS485 interface
USB 2.0 RJ45 RJ45
3.2.6 NPUI-20
The NPUI-20 has bi-directional 20 Gbit/s forwarding capability. All subcards exchange data through the NPUI-20s. Each NPUI-20 provides two 10G Ethernet optical interfaces, supports WAN and LAN modes, and can be installed with XFP optical modules. The NE40E-X2 can be equipped with two NPUI-20s, working in back-to-back mode. In this mode, the NPUI-20 in slot 7 is connected to the subcards in slots 3, 4, 5, and 6; the NPUI-20 in slot 8 is connected to the subcards in slots 9, 10, 11, and 12. The NE40E-X1 can be equipped with one NPUI-20. The NPUI-20 consists of the following units: Control and management unit Through the GE channel connecting the MPU and the NPUI-20, the MPU manages the LPUs and subcards and transmits routing protocol data. Data forwarding unit Working as the forwarding core of the system, the NPUI-20 is connected to all subcards through data channels. Each NPUI-20 provides two 10G Ethernet optical interfaces, supports WAN and LAN modes, and can be installed with XFP optical modules. Table 3-10 Parameters of the NPUI-20 Item Forwarding capability Interface Description Bi-directional 20 Gbit/s forwarding capability Two 10G Ethernet XFP optical interfaces, supporting WAN and LAN modes Remarks -
Issue 01 (2010-03-01)
3-11
3.3 Subcard
The NE40E-X2 has eight slots for subcards. All these slots can be equipped with high-speed subcards or low-speed subcards. Subcards are hot swappable and support automatic configuration recovery. The NE40E-X1 has four slots for subcards. All these slots can be equipped with high-speed subcards or low-speed subcards. Table 3-11 Subcards supported by the NE40E-X2 and NE40E-X1 Interface Name 8-port 100/1000Base-X-SFP Flexible Plug-in Card (FPIC) (1588v2) Description Supports synchronization Ethernet feature and multiple types of optical modules, and complies with the 1588v2 standard. Supports the GE optical module to provide GE optical interfaces. Supports the FE optical module to provide FE optical interfaces. Supports the SFP electrical module to provide 100 M/1000 M auto-sensing electrical interfaces. (In this case, the synchronization Ethernet feature is not supported.) Supports the mixed use of the preceding modules. 8-port 100/1000Base-X-SFP FPIC Supports the synchronization Ethernet feature and multiple types of optical modules. Supports the GE optical module to provide GE optical interfaces. Supports the FE optical module to provide FE optical interfaces. Supports the SFP electrical module to provide the features of 100 M/1000 M auto-sensing electrical interfaces. Supports the mixed use of the preceding modules. Subcards of this type can be inserted in the slots 5, 6, 9, and 10 on the NE40E-X2, and the slots 2 and 5 on the NE40E-X1. Remarks Subcards of this type can be inserted in the slots 5, 6, 9, and 10 on the NE40E-X2, and the slots 2 and 5 on the NE40E-X1.
3-12
Issue 01 (2010-03-01)
Interface Name Auxiliary interface and 4-line FE FPIC
Description Supports on-site ambient monitoring, including the monitoring of burglarproof switches and smoke sensors.
Remarks The subcards installed in the slots 5, 6, 9, and 10 on the NE40E-X2 support both 4-line FE services and ambient monitoring; the subcards installed in the slots 3, 4, 11, and 12 on the NE40E support only environment monitoring. Subcards of this type can be inserted in the slots 2 and 5 on the NE40E-X1.
8-port 100Base-T FPIC (electrical interface)
Subcards of this type can be inserted in the slots 3, 4, 5, 6, 9, 10, 11, and 12 on the NE40E-X2, and in the slots 2 and 5 on the NE40E-X1. Subcards of this type can be inserted in the slots 3, 4, 5, 6, 9, 10, 11, and 12 on the NE40E-X2, and in the slots 2 and 5 on the NE40E-X1. Supports hot swapping, the synchronization Ethernet feature, and three protocols: Circuit Emulation Service (CES), Inverse Multiplexing for ATM (IMA), and Multi-link Point-to-Point Protocol (ML-PPP). Supports hot swapping. Subcards of this type can be inserted in the slots 3, 4, 5, 6, 9, 10, 11, and 12 on the NE40E-X2, and in the slots 2 and 5 on the NE40E-X1.
8-port 100Base-X SFP FPIC (optical interface)
1-port channelized STM-1 FPIC
16-port E1 FPIC (75 ohm)
Subcards of this type can be inserted in the slots 3, 4, 5, 6, 9, 10, 11, and 12 on the NE40E-X2, and in the slots 2 and 5 on the NE40E-X1. Subcards of this type can be inserted in the slots 3, 4, 5, 6, 9, 10, 11, and 12 on the NE40E-X2, and in the slots 2 and 5 on the NE40E-X1.
16-port E1 FPIC (120 ohm)
Supports hot swapping.
Issue 01 (2010-03-01)
3-13
4 Link Features
4
About This Chapter
4.1 Ethernet Link Features 4.2 CPOS Link Features 4.3 4.4 TDM Link Feature E1 Link Features 4.5 ATM E1 IMA 4.6 E-Trunk 4.7 APS
Link Features
4.1 Ethernet Link Features

4.1.1 4.1.2 Basic Features Eth-Trunk
4.1.1 Basic Features

The Ethernet link provided by the NE40E has the following features: VLAN trunk VLANIF interfaces VLAN aggregation Inter-VLAN interface isolation Ethernet sub-interfaces VLAN aggregation sub-interfaces Ethernet clock synchronization
4.1.2 Eth-Trunk
Ethernet bundling is a technology that bundles multiple physical Ethernet interfaces into a logical interface (Eth-Trunk ) to increase bandwidth.
4 Link Features
Eth-Trunks of the NE40E function as follows: 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 the active/standby mode and performs active/standby switchover automatically in accordance with the link status of interfaces. The NE40E supports the addition or deletion of member interfaces to or from an Eth-Trunk. The NE40E 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: 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: IPv4/IPv6 forwarding MPLS forwarding Multicast forwarding L3VPN L2VPN The Layer 3 Eth-Trunk supports the creation of sub-interfaces. Each Layer 3 Eth-Trunk supports a maximum of 4000 sub-interfaces.
LACP (802.3ad)
The NE40E 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 bundling 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 NE40E 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 NE40E negotiates with the peer device to determine the interfaces for data forwarding by
4-2
Issue 01 (2010-03-01)
4 Link Features
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 aggregation changes.
4.2 CPOS Link Features

4.2.1 4.2.2 Channelization PPP/TDM
4.2.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. A 155-Mbit/s CPOS interface can be channelized into 63 E1 channels. After being channelized from the CPOS interface, the E1 interface can transparently transmit unstructured TDM services over the MPLS PW, which complies with the SAToP protocol. After being channelized from the CPOS interface, the E1 interface can transparently transmit structured TDM services over the MPLS PW, which complies with the CESoPSN protocol.
4.2.2 PPP/TDM
The NE40E provides CPOS interfaces at a rate of 155 Mbit/s. On the link layer, CPOS supports the following protocols: PPP TDM PPP on CPOS interfaces supports the following: LCP IPCP MPLSCP MP PAP CHAP
4.3 TDM Link Feature

In Time Division Multiplexing (TDM), a channel is divided into different timeslots. Voice signals are sampled and quantized, and then occupy specific timeslots in specific order. In this manner, multiple channels of signals are multiplexed into a channel of compound digital signals at a high speed, namely, aggregate signals. The signals of each channel are transmitted independently. Through Pulse Code Modulation (PCM), voice signals and other digital signals
4 Link Features
are transmitted over Plesiochronous Digital Hierarchy (PDH) links or Synchronous Digital Hierarchy (SDH) links through TDM. Generally, PDH and SDH services are called TDM services. Figure 4-1 TDM service
The following interfaces support TDM: cSTM-1 POS In a Packet Switched Network (PSN), the Circuit Emulation Service (CES) technology is used to transparently transmit the TDM circuit-switching data. The NE40E supports TDM CES accessed by the E1 electrical interfaces and the channelized STM-1 optical interfaces. The NE40E uses the PWE3 technology to provide the CES. The NE40E supports CES services in structured emulation mode and unstructured emulation mode. The structured emulation mode is also the structure-aware TDM Circuit Emulation Service over Packet Switched Network (CESoPSN) mode. In this mode, the equipment detects the frame structure, framing scheme, and timeslot information in the TDM circuit. In this mode, the equipment processes the overhead in the TDM frames and extracts the payload. The equipment then places each channel of timeslots into the packet payload in certain order. In this manner, each channel of services are fixed and known. The unstructured emulation mode is also the Structure-Agnostic TDM over Packet (SAToP) mode. In this mode, the equipment does not detect the structure of any TDM signals but take signals as bit flows of a fixed rate. In this manner, the overall bandwidth for the TDM signals is emulated. In this mode, the overhead and payload in the TDM signals are transparently transmitted.
4.4 E1 Link Features

The NE40E provides E1 interface. E1 interface supports the following link protocols: PPP ATM supported on CE1/CT1 interfaces TDM supported on CE1/CT1 interfaces
4-4
Issue 01 (2010-03-01)
4 Link Features
PPP on serial interfaces supports the following: LCP IPCP MPLSCP MP PAP CHAP
4.5 ATM E1 IMA

When users need to access an ATM network at a rate between E1 and T3/E3, IMA divides a high-speed link into multiple low-speed links, on which user data is transmitted, and can then multiplex the low-speed links into the high-speed link. During the process, the rate of the high-speed link is approximately equal to the sum of the rates of multiple low-speed links. ATM E1 and ATM IMA are supported on the E1 and CSTM-1 interfaces. IMA can dynamically allocate bandwidth. With IMA, links can be increased or decreased without connection termination, and thus the bandwidth of a link that connects two ends can be changed according to traffic volume. In this manner, bandwidth resources are saved. The following is a simple illustration about inverse multiplexing and de-multiplexing. Figure 4-2 Inverse multiplexing and de-multiplexing of ATM cells in IMA groups
IMA Group PHY Physical Link #0 PHY IMA Group
Physical Link #1 PHY Single ATM Cell Stream from ATM Layer PHY PHY Original ATM Cell Stream to ATM Layer PHY
Physical Link #2
IMA Virtual Link
Tx direction: cells distributed across links in round robin sequence Rx direction: cells recombined into single ATM stream
The IMA interface periodically sends certain special cells. The information contained in these cells are used by the receiving end of IMA virtual links to recreate ATM cell flows. Before recreating ATM cell flows, the receiving end should first adjust the link differential delay and remove the Cell Delay Variation (CDV) imported by controlling cells. These types of cells are called IMA Control Protocol cells (ICP), and are used to define IMA frames. Upon sending, the sending end should keep alignment with IMA frames on all links so that it can detect the differential delay between links according to the arrival time of IMA frames on different links and perform adjustment thereafter.
Issue 01 (2010-03-01)
4-5
4 Link Features
The cells are consecutively sent at the sending end. If no cells on the ATM layer can be sent between ICPs of an IMA frame, the IMA sending end keeps consecutive cell flows on the physical layer by adding filler cells, which are later discarded at the IMA receiving end.
4.6 E-Trunk
A Enhanced Trunk (E-Trunk) is an extension of a trunk. In the E-Trunk, a trunk is divided into two sub-groups that connect to two routers respectively, rather than connect to multiple LPUs on one router. These two routers are PE devices that back up each other. The E-Trunk provides reliability for Ethernet links, and also provides reliability for network connections by connecting to two systems. Figure 4-3 E-Trunk
PE1 Active Standard Trunk
Trunk 1 (Sub-group) CPE Trunk 1
E-Trunk
Provider Network
Standby PE2
As shown in Figure 4-3, LACP is used to manage trunk links, which ensures that one sub-group connected to one PE device is in the Active state and the other is in the Standby state. In this manner, no loop occurs. At the same time, the E-Trunk control protocol is running between the two PE devices. The E-Trunk control protocol is IP based, and is run between two devices that back up each other to synchronize the trunk status. When one PE device fails, the other PE can still access the Customer Premises Equipment (CPE). The CPE, however, is still configured with the standard trunk, and does not have to support the E-Trunk. Therefore, the E-Trunk configured on the two PE devices is transparent for the CPE.
4.7 APS
Automatic Protection Switching (APS) has two protection modes, namely, 1+1 and 1:N. When the N is 1, the protection mode is 1:1. In 1+1 mode, a protection interface is paired with each working interface. Normally, the receiver only processes the traffic being received on the working link. When the working link is faulty, traffic is switched to the protect link on the receiver, which is called unidirectional switchover.
4-6
Issue 01 (2010-03-01)
4 Link Features
In 1:1 mode, the working link transmits high-level traffic and the protect link transmits nothing to the receiver. When the working link is faulty, the sender switches the high-level traffic to the protect link and the receiver obtains the high-level traffic from the protect link. This is called bidirectional switchover. At present, the NE40E supports the following APS features: 1+1 unidirectional mode and 1:1 bidirectional mode. Manual switching of APS groups. Forcible switching of APS groups. Locking of APS groups. APS implemented on interfaces. APS implemented on the same SIC or inter-SIC APS. E-APS. Adding the working and protection interfaces of an APS group to a trunk and configuring services on the trunk.
Issue 01 (2010-03-01)
4-7
5 Service Features
5
About This Chapter
5.1 5.2 Ethernet Features IP Features 5.3 Routing Protocols 5.4 MPLS 5.5 5.6 5.7 5.8 VPN Features IPTN Features QoS Features Load Balancing
Service Features
5.9 Traffic Statistics 5.10 5.11 Security Features Network Reliability
5.1 Ethernet Features

5.1.1 5.1.2 5.1.3 5.1.4 5.1.5 5.1.6 Switched Ethernet Features Routed Ethernet Features QinQ RRPP Link Features RSTP/MSTP BPDU Tunnel
Issue 01 (2010-03-01)
5-1
5 Service Features
5.1.1 Switched Ethernet Features

The Ethernet interfaces on the NE40E 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 cover the interfaces of many routers. The NE40E can dynamically add, delete, or modify the VLANs of a VLAN trunk to maintain the consistency of VLAN configurations in the entire network. The NE40E can also work with non-Huawei devices for interworking.
VLANIF Interfaces
The NE40E supports VLANIF interfaces. You can assign IP addresses to VLANIF interfaces and bind VLANIF interfaces to VPNs. This implements 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, but it is allowed between an isolated interface and a non-isolated interface in a VLAN. On the NE40E, 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 NE40E 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.
5.1.2 Routed Ethernet Features

The Ethernet interfaces on the NE40E 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 the configuration of VLAN tags to encapsulate or terminate VLAN packets.
5-2
Issue 01 (2010-03-01)
5 Service Features
Ethernet Sub-interfaces
A common Ethernet sub-interface, which can belong to a VLAN only, has the following functions: Terminating enterprise services Supporting complete routing protocols Supporting MPLS forwarding
Super-VLAN Sub-interfaces
A super-VLAN sub-interface, which can belong to multiple VLANs, functions to terminate individual users' services. It supports the following features to ensure security: DHCP relay DHCP binding URPF ACLs
5.1.3 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, which 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: 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. The NE40E provides rich QinQ features, which satisfies diverse networking requirements.
Interface-based QinQ
Figure 5-1 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.
5 Service Features
Figure 5-1 Networking diagram of applying interface-based QinQ
VLAN100
100 200
ME60
100 300 200 300
ISP Network
VLAN200
Interface-based QinQ provides the following functions: Access to the VPLS to transparently transmit private VLAN packets Access to the VLL and PWE3 to transparently transmit private VLAN packets
VLAN-based QinQ
VLAN-based QinQ is also called selective QinQ. Figure 5-2 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: VLANs 1000-1999: broadband access services VLANs 2000-2999: VoIP services VLANs 3000-3999: IPTV services
5-4
Issue 01 (2010-03-01)
5 Service Features
Figure 5-2 Networking diagram of applying VLAN-based QinQ
iManager N2000 IP backbone/MAN

VLAN200 Broadband access VLAN100 VLAN2001 VLAN 3001 VLAN 1001 VLAN1xxx VLAN300 VOIP access VLAN3xxx IPTV access VLAN2xxx VLAN2002 VLAN 3002 VLAN 1002
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 manners: Adds different outer VLAN tags based on VLAN ranges. That is, packets with a single tag are changed 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, a tag is added 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, a single tag is replaced with another tag. In this manner, services of different user 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
Issue 01 (2010-03-01)
5-5
5 Service Features
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: In interface-based QinQ mode, user packets from the same user side are added with the same outer VLAN tag on the PE. 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: 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 the packets 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: IP forwarding L3VPN/PWE3/VLL/VPLS access Proxy ARP Unicast routing protocols VRRP DHCP server and DHCP relay
5 Service Features
Sub-interfaces for QinQ VLAN tag termination terminate double VLAN tags in the following manners: Exact termination Double VLAN tags of specified VLAN IDs are terminated. 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 manufactures. To connect different manufacturers' devices, 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-3 Compatibility of the EType field in the TPID in the outer tag of QinQ packets
0x9
1 00
IP/MPLS Core
0x9100 Router A ME60

0x 81 00
Switch A
Router C
As shown in Figure 5-3, 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 different manufacturers' devices so that the devices can be set with the same Etype value in the outer TPID. This ensures communications between different manufacturers' devices.
Application of Multicast QinQ

Figure 5-4 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 01 (2010-03-01)
5-7
5 Service Features
Figure 5-4 Networking diagram of applying multicast QinQ
Internet /Intranet Multicast source
PE1 QinQ(VLAN1) PE2
VLAN2
VLAN3
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 for 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.
VLAN Swapping Based on QinQ

As shown in Figure 5-5, the data packets sent from the DSLAM to the UPE carry double VLAN tags. The inner tag indicates the service VLAN and the outer tag indicates the customer VLAN. The UPE, however, can only transmit packets by adding an outer tag to the packet accessing the service VLAN and adding an inner tag to the packet accessing the customer VLAN. To transmit data to correct VLANs, the UPE needs to swap the inner VLAN tag with the outer VLAN tag in the packet. In this manner, the outer tag in the packet can indicate the service VLAN and the inner tag can indicate the customer VLAN. In this manner, when the UPE receives packets with double VLAN tags, the inner tag is swapped with the outer tag. The VLAN tag swapping does not take effect on packets with a single tag.
5-8
Issue 01 (2010-03-01)
5 Service Features
Figure 5-5 Network diagram of the VLAN swapping feature based on QinQ
UPE Metro Ethernet Network
PE-AGG
VLAN Swap Service VLAN/Customer VLAN
Service-POP Customet VLAN/Service VLAN
Service VLAN RG RG
HSI
VOIP
IPTV
HSI
VOIP
IPTV
5.1.4 RRPP Link Features

The Rapid Ring Protection Protocol (RRPP) is a link layer protocol specially used for Ethernet ring networks. When an Ethernet ring network is complete, RRPP can prevent broadcast storms caused by data loops. When a link is disconnected, RRPP helps to quickly enable the standby link and then recover the communications between nodes on the ring network.
Issue 01 (2010-03-01)
5-9
5 Service Features
Figure 5-6 Application of tangent RRPP rings in the MAN
RRPP Domain Master Node Edge Node SwitchA RRPP Sub-Ring 1 Transit Node Router A RRPP Major-Ring ME60C Master Node Assistant Node RRPP Sub-Ring 2 SwitchB Transit Node Master Node
ME60B
An RRPP domain comprises of a group of switches that are mutually connected and configured with the same domain ID and control VLAN. One RRPP domain consists of the elements including the RRPP major ring and sub-ring, control VLAN, master node, transit node, common port and edge port, and primary port and secondary port.
Polling Mechanism
The polling mechanism is used by the master node on an RRPP ring to detect the network status. The master node periodically sends Hello packets from its primary port. The packets are then transmitted through all transit nodes on the ring. If the secondary port on the master node can receive the Hello packets, the ring network is complete. If the Hello packets are not received within a specified period, a link fault occurs on the ring network. When the secondary port on the master node in the Failed state receives Hello packets from its primary port, the master node immediately changes to the Complete state, blocks the secondary port, and refreshes the Forwarding Database (FDB). In addition, the master node sends packets from the primary port to instruct all transit nodes to unblock temporarily blocked ports and refresh FDBs.
Link Status Notification Mechanism

If a link on the ring fails, the port directly connected to the link becomes Down. The transit node immediately sends a Link-Down packet to the master to report the change of the link status. When the master node receives the Link-Down packet, the master node considers that the ring fails so that it immediately opens the secondary port, and sends packets to instruct other
5-10
Issue 01 (2010-03-01)
5 Service Features
transit nodes to refresh FDBs. After other transit nodes refresh their FDBs, the data stream is switched back to the normal link. If the faulty link is recovered, the port of the transit node changes to the Up state. In this case, the transit node temporarily blocks the recovered port. The Hello packets sent by the master node can pass through the temporarily blocked port. When the secondary port on the master node receives the Hello packet from the primary port, the master node considers that the ring recovers to the healthy status. The master node blocks the secondary port and sends packets to notify all transit nodes to unblock temporarily blocked ports and refresh FDBs.
Mechanism of Checking the Channel Status of Sub-ring Protocol Packets on the Major Ring
This mechanism is used for the networking in which multiple sub-rings are crossed with the major ring. When the major ring fails, all master nodes on sub-rings enable their secondary ports. In this case, the broadcast loop occurs among the sub-rings. To prevent this, the mechanism of checking the channel status of sub-ring protocol packets on the major ring is used. This mechanism needs the cooperation of the edge nodes and assistant edge nodes. Before the secondary port is enabled, the master node of each sub-ring blocks the edge port of the edge node; thus the data loop among sub-rings is prevented. The edge node is the initiator and decision-maker of the mechanism. The assistant edge node monitors the channel status and informs the edge node of the channel status change in time.
5.1.5 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 network with loops to a loop-free network. In this manner, the packets are prevented from increasing and infinitely looping. Compared with STP, RSTP speeds up 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 VLANs. In a Layer 2 network, multiple SPTs can be generated.
5.1.6 BPDU Tunnel

BPDUs are Layer 2 protocol packets and are transparently transmitted through a Layer 2 protocol tunnel or a BPDU tunnel across an ISP network. To transparently transmit BPDUs across an ISP network, the following requirements should be met: Each branch of the same user network can receive its own BPDUs. The BPDUs of a user network cannot be processed by the CPU of devices on the ISP network. BPDUs of different user networks must be isolated, so the BPDUs are freed from interference. The NE40E supports the transparent transmission of the following BPDUs: Interface-based BPDUs
5 Service Features
VLAN-based BPDUs QinQ-based BPDUs
5.2 IP Features
5.2.1 5.2.2 5.2.3 IPv4/IPv6 Dual Stack IPv4 Features IPv6 Features
5.2.1 IPv4/IPv6 Dual Stack

The IPv4/IPv6 dual stack features good interoperability and easy implementation. Figure 5-7 shows the structure of the IPv4/IPv6 dual stack. Figure 5-7 Structure of the IPv4/IPv6 dual stack
IPv4/IPv6 Application
TCP
UDP
IPv4
IPv6
Link Layer
5.2.2 IPv4 Features

The NE40E supports the following IPv4 features: 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. IP policy-based routing to specify the next hop based on the attribute of packets without searching the routing table
5-12
Issue 01 (2010-03-01)
5 Service Features
5.2.3 IPv6 Features

The NE40E supports the following IPv6 features: 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 DHCPv6 server, DHCPv6 relay, and DHCPv6 PD
5.3 Routing Protocols

The NE40E supports various unicast and multicast routing protocols; thus different networking requirements are satisfied. 5.3.1 5.3.2 5.3.3 Fast Convergence of BGP Routes Unicast Routing Multicast Routing
5.3.1 Fast Convergence of BGP Routes

With the new mechanism of route convergence and new algorithm, the convergence of BGP routes speeds up greatly. The improvements include: Separation of route prefixes and next hops Through the separation of route prefixes and next hops, the convergence time is irrelevant to the number of prefixes. During route convergence, if a large number of prefixes correspond to the same next hop, a device only needs to refresh the information about the next hop, and then the traffic of the corresponding prefixes can be switched at the same time. On-demand route iteration When a dependent route is changed, only the next hop related to the dependent route is re-iterated. Therefore, when a route changes, a device can re-iterate only the related next hop by determining the destination address of the route. With respect to tunnel iteration, when a tunnel alternates between Up and Down, a device needs to re-iterate only the next hop whose original next hop address is the same as the destination address of the tunnel.
5.3.2 Unicast Routing

The NE40E supports the following unicast routing features: 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
Issue 01 (2010-03-01)
5-13
5 Service Features
Routing policy to select the optimal route Fast Convergence of BGP Routes
5.3.3 Multicast Routing

The NE40E supports multicast. This saves network bandwidth and reduces network load.
Basic Multicast Functions

The NE40E provides the following multicast functions: 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:
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.
Multicast static routes. Configuration of multicast protocols on physical interfaces such as Ethernet, 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 NE40E adopts the Multicast Domain (MD) scheme to implement centralized processing. Addition and deletion of dummy entries. The BRAS interface on the NE40E provides port- and VLAN-based multicast replication. The specific multicast replication engine can speed up channel switchover and shorten the delay of multicast replication, which improves users' experiences on IPTV services. The BRAS interface on the NE40E provides session-based multicast replication. In the networks where DSLAMs do not support multicast replication for PPPoE users, multicast replication for PPPoE users can be performed directly on the BRAS interface,
5 Service Features
and the DSLAMs do not need to be upgraded in large scale. This cuts the costs of initial investment in IPTV services. The BRAS interface on the NE40E provides multicast authorization by defining a channel list containing the authorized multicast for users. Then, the BRAS interface only replicates authorized multicast channels. This simplifies the configuration of multicast authorization and cuts the operating expense (OpEx). In addition, through multicast authorization, the BRAS interface provides scheduling of high-priority multicast traffic, which ensures normal transmission of multicast traffic when the network is congested. The BRAS interface on the NE40E provides virtual multicast scheduling to ensure the unified bandwidth scheduling of multicast and unicast traffic in a dual-edge architecture. Virtual multicast scheduling can effectively prevent packet loss on DSLAMs when multicast traffic bursts, and improve users' experiences on IPTV services. In addition, the NE40E provides full multicast scheduling, which improves IPTV service quality. The BRAS interface on the NE40E supports shaping, priority-based scheduling, and HQoS scheduling, and multicast replication performed by the ASIC chip. In this manner, the delay and jitter of multicast traffic are reduced and multicast traffic can meet the requirements for QoS of IPTV applications.
IGMP Snooping
The NE40E 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 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 NE40E supports the following measures to process unknown multicast packets: Discards the packets directly after receiving them. Broadcasts the packets in the VLAN to which the receiving interface belongs. To control multicast traffic, the NE40E also supports the limit to the maximum percentage of multicast traffic on Ethernet interfaces.
Multicast VLAN
A 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 NE40E forwards multicast packets through the multicast VLAN and replicates the packets based on the multicast routing entries. Then, the NE40E sends these packets to the VLANs of different users. Using the multicast VLAN, the NE40E can converge the multicast flows of different user VLANs to one or more specified VLANs.
Issue 01 (2010-03-01)
5-15
5 Service Features
Multicast across VLANs enables the NE40E 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 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 NE40E on the user side. The NE40E 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 NE40E 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 NE40E adopts the MD solution to implement multicast transmission over VPNs. For details, see Section "5.5 VPN Features."
Multicast CAC
The NE40E 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 demands 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
5.4.1 5.4.2 5.4.3 Basic Functions MPLS TE MPLS OAM
5.4.1 Basic Functions

The NE40E 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).
5-16
Issue 01 (2010-03-01)
5 Service Features
The NE40E supports the following MPLS functions: Basic MPLS functions, 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. 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 NE40E can serve as a Label Edge Router (LER) or an LSR. 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. An LSR is a core router on the MPLS network. It switches and distributes labels.
5.4.2 MPLS TE
Network congestion affects the performance of the backbone network. The congestion may be caused by resource insufficiency 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 prevent 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, MPLS TE can protect the network communications through the backup path and the fast reroute (FRR) function. MPLS TE provides the following functions: 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.
Issue 01 (2010-03-01)
5-17
5 Service Features
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: 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 messages. 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: 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.
Fast Reroute
FRR is a technology in MPLS TE to implement 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
In Auto FRR, to protect a tunnel, you must configure a bypass tunnel and bind it to the tunnel to be protected. 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. 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.
5-18
Issue 01 (2010-03-01)
5 Service Features
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 NE40E supports the following methods of backup: 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. Figure 5-8 Networking diagram of applying LDP over TE
10
R3
10
R1
R2 20 10
R5
R6
R4
Figure 5-8 shows the MPLS VPN networking where LDP is used as the signaling protocol. As PE routers, CX1 and CX6 discover that the link between R2 and R3 is rather congested after a great number of users access. This happens because the traffic between CX1 and CX6 must pass through this link. The link between R2 and R4 is idle. The LSP, however, cannot use the link between R2 and R4 because the IGP cost of this link is high. In this case, you can establish a TE tunnel passing through R4 between R2 and R5, and adjust the metric of the IGP shortcut or forwarding adjacency. Thus, there are two routes carrying out load balancing for R2: Route between physical interfaces connecting R2 and R3 Route between TE tunnel interfaces connecting R2 and R5
Issue 01 (2010-03-01)
5-19
5 Service Features
In this manner, LDP establishes the LSPs for load balancing to allow traffic to go through the idle link.
5.4.3 MPLS OAM

MPLS supports different Layer 2 and Layer 3 protocols such as IP and Ethernet. MPLS offers an OAM mechanism totally independent of any upper or lower layer and provides the following features on the MPLS user plane: Detects the LSP connectivity. Measures the network utility and performance. Carries out switchover against link failure to offer services according to the Service Level Agreements (SLAs) signed with customers. With the MPLS OAM mechanism, the router can detect, identify, and locate faults on the MPLS layer effectively. Then, the fault is reported and processed. In addition, when a failure occurs, the protection switchover can be triggered. MPLS OAM provides the following functions: 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. Figure 5-9 Networking diagram of applying MPLS OAM
FD /F CV
CV /F FD
Ingress LSR
Egress LSR
I BD
BD I
OAM auto protocol function. Protection switching: 1:1, 1+1, sharing protection, and packet-level protection are supported.
5.5 VPN Features

5.5.1 5.5.2 5.5.3 5.5.4 Tunnel Policy VPN Tunnel MPLS L2VPN BGP/MPLS L3VPN
5-20
Issue 01 (2010-03-01)
5 Service Features
5.5.5 5.5.6
L2VPN Accessing L3VPN MPLS HQoS
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 NE40E supports the following types of tunnel policies: 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. This guarantees the QoS of the specified VPN services.
5.5.2 VPN Tunnel

The NE40E supports the following types of VPN tunnels: 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. 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 NE40E provides Layer 2 VPN (L2VPN) services on an MPLS network. This allows the ISP to provide L2VPN over different media.
VLL
Figure 5-10 shows the networking of a VLL supported by the NE40E.
Issue 01 (2010-03-01)
5-21
5 Service Features
Figure 5-10 Networking diagram of a VLL

Support dynamic Martini/ Kompella L2VPN Support static CCC/ SVC L2VPN VPN2 site3 Support access to the MPLS L2VPN through PPP, HDLC, ATM, Eth/VLAN, and Q-in-Q
VPN1 site1 VPN2 site2
PE
PE Support interworking MPLS network PE VPN1 site3
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
VPN3 site1
VPN3 site2
Provide the VPN manager to manage VPNs among devices of different vendors
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 RFC 4096. In the Martini draft, LDP is extended with an FEC type (VC FEC) added 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 PEs assign a VC label to each connection between CEs. The VLL information that carries the VC label 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 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 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.
5-22
Issue 01 (2010-03-01)
5 Service Features
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 must 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. PWE3 IP-interworking If two CEs access the same VLL through different types of links, the PWE3 IP-interworking feature is required. draft-kompella-ppvpn-l2vpn-03 recommends that when a VLL is set up, the VLL interface is encapsulated with ip-interworking on the PE to transparently transmit Layer 3 data, namely, 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 a VLL connection after VC interfaces become Up. The PEs allow VLL forwarding when a 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. 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 without entering the MPLS network.
After a VLL connection is established, the IP packets are processed as follows:

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 type of the link 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
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 5-23
Issue 01 (2010-03-01)
5 Service Features
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 resource consumption and the configuration workload decrease.
VPLS
Figure 5-11 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. Figure 5-11 VPLS networking
VLAN1
VS1
VS1
VLAN1
VLAN2
VS2 PE
VS2 PE
VLAN2
VS1
VS2
PE
VLAN1
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 NE40E supports the following networking models: QinQ VPLS
5-24
Issue 01 (2010-03-01)
5 Service Features
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 that is easy to implement. H-VPLS 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 N^2. Hierarchical Virtual Private LAN Service (H-VPLS) is thus introduced to address the full-mesh VPLS. Figure 5-12 shows the H-VPLS model. Figure 5-12 H-VPLS model
CE
Basic VPLS Full Mesh AC SPE PW AC UPE PW SPE PW SPE
PW
CE
In a basic H-VPLS model, PEs can be divided into the following types:
UPE It is a convergence device that is directly connected to a CE. The UPE needs to be connected to only one PE in a full-mesh VPLS network. The UPE supports routing and MPLS encapsulation. If a UPE is connected to multiple CEs and possesses the basic bridge function, frame forwarding is performed only on the UPE. This reduces the burden on the SPE.
SPE It is connected to a UPE and is located in the core of a full-mesh VPLS network. The SPE is connected to all the devices in a full-mesh VPLS network. For an SPE that is connected to a UPE, the UPE acts as a CE. The PW set up between the UPE and the SPE serves as the AC of the SPE. The SPE must learn the MAC addresses of all the sites on the UPE side and those of the UPE interfaces that are connected to the SPE.
IGMP snooping
Issue 01 (2010-03-01)
5-25
5 Service Features
VPLS can isolate users. Each VPN needs to support IGMP snooping, namely, the multi-instance IGMP snooping. VPLS learns MAC addresses in the following modes:
Unqualified In this mode, there can be numerous VLANs in a VSI to share the MAC address space and a broadcast area. When learning MAC addresses, VPLS also learns the VLAN IDs.
Qualified In this mode, each VSI has only one VLAN that has the independent MAC address space and broadcast area. When learning MAC addresses, VPLS does not need to learn the VLAN IDs.
VPLS/H-VPLS equal-cost load balancing In VPLS/H-VPLS services, when there are multiple public tunnels of equal cost from the local PE to a remote PE, the VPLS PW performs the HASH algorithm and then selects 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/H-VPLS transmits multicast traffic and when the master TE tunnel in the public network is faulty, the TE HSB switchover is performed within 500 ms. 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). The details are as follows:

Common VSI: has two or more Up AC interfaces, or has one Up AC interface and one Up PW. mVSI: has one Up PW or AC interface. An mVSI can be bound to a common VSI. When an mVSI receives a gratuitous ARP packet or a BFD Down packet, the mVSI instructs all the common VSIs bound to it to clear MAC address entries and re-learn MAC addresses.
STP over PW STP over VPLS can address the following problems:

Loops that are formed in inter-AS VPLS networks (Option A) Loops that are formed when multiple ring networks are dual-homed to an H-VPLS network Loops that are formed when the DSLAM accesses multiple UPE devices
Ethernet loop detection Virtual Private LAN Service (VPLS) is a significant technology for the Metropolitan Area Network (MAN). To prevent 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 thus cause broadcast storms. 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.
5-26
Issue 01 (2010-03-01)
5 Service Features
When user networks cannot be controlled, you can deploy Ethernet loop detection supported by the NE40E over the carrier network. Ethernet loop detection need not be deployed at the user side. This also prevents broadcast storms caused by loops formed in a VPLS network.
PW Redundancy
PW redundancy provides reliability by setting up multiple PWs on a VPN to protect traffic transmitted along the PW. Those PWs assume one of two roles: master PW or backup PW. The master and backup PWs are dynamically negotiated and determined. Once one PW fails, traffic on this PW is switched to another PW. This ensures traffic transmission. PW traffic is transmitted over public network tunnels. When a tunnel fails, traffic is switched to another tunnel for transmission. In some scenarios, such as in the case of a PE failure or a AC failure, however, traffic cannot be protected. Thus, PW redundancy is introduced to implement traffic protection. VLL FRR protects traffic by switching traffic from the master PW to the backup PW in case the master PW fails. The master and backup PWs are statically configured. PW redundancy provides the master and backup PWs that are dynamically negotiated and determined through E-Trunk or E-APS on AC interfaces. The applications of VLL FRR and PW redundancy are similar.
5.5.4 BGP/MPLS L3VPN

The NE40E implements BGP/MPLS L3VPN, and thus provides carriers with end-to-end VPN solutions. Carriers can provide VPN service for users as a new value-added service, which serves as a flexible selection. Figure 5-13 shows the application of BGP/MPLS L3VPN that the NE40E supports.
Issue 01 (2010-03-01)
5-27
5 Service Features
Figure 5-13 BGP/MPLS L3VPN

VPN2 site3 VPN1 site1 VPN2 site2 MP-BGP MPLS network VPN1 site2 VPN2 site2 PE-ASBR UPE Hierarchical PE Support inter-AS solutions: VRF-to-VRF MP-EBGP MP-Multihop EBGP SPE PE UPE MPLS network 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
PE
Support HoVPN to extend the VPN PE-ASBR
Support MPLS VPN over GRE and MPLS VPN over TE tunnel Provide the VPN manager to manage VPNs among devices of different vendors
VPN3 site1
VPN3 site2
As a PE router, it supports access of CE routers through interfaces such as Ethernet and VLAN, Remote Access and Tunnel 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 L3VPN 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 L3VPN 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 first 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.
5-28
Issue 01 (2010-03-01)
5 Service Features
Inter-AS VPN
The NE40E supports the following inter-AS VPN solutions explained in RFC 2547bis: VPN instance to VPN instance: ASBRs manage VPN routes in between through 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 NE40E supports multicast BGP/MPLS L3VPN. Multicast services are deployed in the network shown in Figure 5-14. VPN users at various sites receive multicast traffic from the local VPN. The PE in the public network supports multi-instance. As shown in Figure 5-14, the public network instances on each PE and the P implement public network multicast. VPN multicast data is multicast in the public network. Figure 5-14 Networking diagram of applying public network multicast
PE1_public-instance
P1 P2 PE3_public-instance
P3
PE2_public-instance
As shown in Figure 5-15, the VPN A instances on each PE and the sites that belong to VPN A implement VPN A multicast.
Issue 01 (2010-03-01)
5-29
5 Service Features
Figure 5-15 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-16, the VPN B instances on PEs and the sites that belong to VPN B implement VPN B multicast. Figure 5-16 Networking diagram of applying VPN B multicast
CE4 PE1_vpnB-instance VPN B site4 CE5 MD B VPN B site5
PE2_vpnB-instance CE6
VPN B site6
Take VPN A instances as an example. Multicast VPN can be summarized as follows: The multicast source S1 belongs to VPN A. S1 sends multicast data to G, a multicast group.
5-30
Issue 01 (2010-03-01)
5 Service Features
Among all possible data receivers, only members of VPN A can receive multicast data from S1. Multicast data is multicast at various sites and on the public network. To implement multicast VPN, the following network conditions should be met: Each site that supports multicast based on VPN instance A public network that supports multicast based on public instances A PE device that supports the following multi-instance multicast: Connecting sites through the 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
As an enhancement of IPv4, IPv6 is an Internet protocol of the next generation. IPv6 provides the enhanced address space, configuration, maintenance, and security functions, and supports more access users and devices in the Internet than IPv4. The VPN is a virtual private communication network built over share links or public networks such as the Internet. Users located in different areas can exchange data through the public networks. Thus, the users can enjoy services similar to private P2P links. An IPv6 VPN refers to a VPN where each site has the IPv6 capability and is connected to the PE of the SP and then to the SP backbone network through an interface or a sub-interface by using IPv6 addresses. To put it simply, an IPv6 VPN indicates that a PE router receives IPv6 packets from a CE router, which is different from an IPv4 VPN. At present, IPv6 VPN services are implemented over the IPv4 backbone network of the SP. In this case, the PE must support IPv4/IPv6 dual stack because the backbone network is an IPv4 network and the client sites use the IPv6 address family, as shown in Figure 5-17. Any network protocol that can bear IPv6 traffic can run between the CEs and the PEs. PE interfaces connected to the client run IPv6; PE interfaces connected to the public network run IPv4.
Issue 01 (2010-03-01)
5-31
5 Service Features
Figure 5-17 Networking diagram of the IPv6 VPN over the IPv4 public 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
Through Multiprotocol Extensions for Border Gateway Protocol version 4 (MP BGPv4), the IPv6 VPN advertises IPv6 VPN routing information in the backbone network, triggers MPLS to allocate labels for IPv6 packets to mark the packets, and uses tunnels such as LDP LSPs, MPLS TE tunnels to transmit private network data in the backbone network. An IPv6 VPN is implemented in the same way as that of a BGP/MPLS L3VPN. The NE40E supports the following IPv6 VPN networking solutions: 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, provides the following functions: 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 become a bottleneck. To solve this problem, Huawei launches the Hierarchy of VPN (HoVPN) solution. In HoVPN, the 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. The basic architecture of HoVPN is shown in Figure 5-18. The device that is directly connected to users is called the Underlayer PE or User-end PE (hereinafter referred to as the
5 Service Features
UPE). The device that is connected to the UPE in the internal network is called the Superstratum PE or Service Provider-end PE (hereinafter referred to as the SPE). Multiple UPEs and an SPE form a hierarchical PE, functioning together as a traditional PE router. Figure 5-18 Basic architecture of HoVPN
VPN1 site HoVPN
VPN2 site
PE
VPN1 site
UPE 1
SPE 1 MPLS Network
VPN1 site
SPE 2
UPE 2 VPN2 site
PE
VPN2 site
In the networking of HoVPN, functions of PE routers are implemented hierarchically. Therefore, the solution is also called the Hierarchy of PE (HoPE).
SPEs and UPEs provide the following functions: UPEs implement user access. UPEs maintain the routes of their directly connected VPN sites. UPEs do not maintain the routes of other remote sites in the VPN, or UPEs maintain only their summary routes. UPEs assign inner labels to the routes of their directly connected sites, and advertise the labels to an SPE along with VPN routes through MP-BGP. SPEs manage and advertise VPN routes. They maintain the routes of all the VPNs that are connected through UPEs, including the routes of local and remote sites. The SPEs do not advertise routes of remote sites to UPEs. SPEs advertise only the default routes of VPN instances or summary routes to UPEs carrying the label. There are different requirements for SPEs and UPEs because they play different roles. SPEs have large-capacity routing tables and high forwarding performance with few interfaces. UPEs have small-capacity routing tables and low forwarding performance, whereas they possess high access capabilities. HoVPN makes full use of the performance of SPEs and the access capabilities of UPEs.
Issue 01 (2010-03-01)
5-33
5 Service Features
An HoPE is the same as a traditional PE in appearance. HoPEs and common PEs can coexist in an MPLS network. HoVPN supports the embedding of HoPEs: An HoPE can act as a UPE, and compose a new HoPE with an SPE. An HoPE can act as an SPE, and compose a new HoPE with multiple UPEs. The embedding of HoPEs can be repeated. The embedding of HoPEs 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 Host
In a BGP/MPLS L3VPN, the VPN attributes of the packets received by PEs from CEs are determined by the VPN instance bound to the outbound interface on the PEs. Thus, all the CEs whose packets are forwarded by the same PE interface belong to the same VPN. In practical scenarios, some servers or terminals need to access multiple VPNs. These servers or terminals are called multi-role hosts. For example, a server in a financial system in VPN 1 and a server in an accounting system in VPN 2 need to communicate. 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. A multi-role host generally fulfils the following functions: Ensures that the data stream of the multi-role host reaches the destination VPN network. Ensures that the data stream from the destination VPN network reaches the multi-role host. As shown in Figure 5-19, the multi-role host (PC) belongs to VPN 1. If VPN 1 and VPN 2 on PE1 cannot import routes from each other, PC can access VPN 1 only. The data stream sent from PC to VPN 2 only reaches the routing table of VPN 1 on PE1. If PE1 finds no route to the destination address of the packet, which belongs to VPN 2, in the routing table of VPN 1, PE1 discards the packet. To ensure that the data stream of PC reaches VPN 2, you can configure policy-based routing (PBR) on PE1 interfaces that connect CE1. After the configuration, if PE1 cannot find the destination address of a packet from CE1 in the routing table of VPN 1, it searches the routing table of VPN 2 for the route and then forwards the packet. The PBR is generally based on IP addresses and can guide data streams to access different VPNs.
5-34
Issue 01 (2010-03-01)
5 Service Features
Figure 5-19 Implementation of a multi-role host
VPN1 PC Static-Route Backbone CE1 PE1 Policy-Based Routing PE2 CE2
VPN1
PE3 VPN2 CE3
To ensure that the data stream replied from VPN 2 reaches PC, routes of the replied data stream must exist in the routing table of VPN 1 on PE1. As a result, you need to add a static route destined for PC to the routing table of VPN 2 on PE1. The outbound interface of the static route must be the outbound interface that connects CE1 in VPN 1 to PE1. The functions of a multi-role host are mainly implemented on the PE that connects the CE to which the multi-role host is connected. Through the PBR on a PE, the PE can search the routing tables of different VPNs for routes of the data streams from the same VPN. Static routes can be added to the routing table of the destination VPN on a PE. The outbound interfaces of the static routes are the interfaces bound to the instances of the VPN where the multi-role host resides. Note that the IP addresses of the VPN where a multi-role host resides and the VPNs 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. The UPE terminates and accesses the L2VPN (VLL and VPLS). The NPE terminates and accesses the L3VPN.
Issue 01 (2010-03-01)
5-35
5 Service Features
Figure 5-20 Traditional access network

The UPE terminates the L2VPN and accesses the L3VPN DSLAM The NPE accesses the L3VPN and sets up the L3VPN tunnel DSLAM
The UPE and the NPE run as the CE for each other
Users access the UPE L2VPN through ACs User Switch
UPE MPLS L2VPN
NPE
NPE
UPE MPLS L2VPN
UPE
MPLS L3VPN
UPE The UPE accesses the L2VPN and sets up the L2VPN tunnel
UPE
NPE
NPE
UPE
UPE User Switch
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 operation 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 type 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 S-switches. 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 capabilities of the PE-AGG, networking cost can be saved and networking is simplified. The VE interface, which is supported by the NE40E 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 NE40E can run as the NPE and PE-AGG at the same time.
5-36
Issue 01 (2010-03-01)
5 Service Features
Figure 5-21 L2VPN accessing the L3VPN

The UNPE terminates the L2VPN, accesses the L3VPN, and sets up the L2VPN and L3VPN tunnels DSLAM UPE DSLAM
Users access the UPE L2VPN through the AC User Switch UPE The UPE accesses the L2VPN and sets up the L2VPN tunnel L2VPN
UNPE
UNPE
MPLS L3VPN L2VPN User Switch UPE
UNPE
UNPE
AC for user access Users access the L3VPN through the L2VPN L2VPN tunnel L3VPN tunnel
Without a dedicated board, the NE40E can associate Layer 2 with Layer 3 VE interfaces by using a VE group. The NE40E 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 MPLS HQoS

The ISP provides L2VPN or L3VPN access services for a VPN user and signs the SLA with the user. The SLA includes the following: 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. 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. MPLS HQoS 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 01 (2010-03-01)
5-37
5 Service Features
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: 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, MPLS HQoS has the following functions: On the ingress PE router, MPLS HQoS 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. Traffic classification and scheduling support uniform and pipe or short pipe mode. MPLS HQoS performs differentiated queue scheduling according to the MPLS EXP field on the P router. On the egress PE router, MPLS HQoS performs differentiated queue scheduling based on the EXP field and limit and shape traffic on the outbound interface. MPLS HQoS with DiffServ has the innate defect of the DiffServ model. That is, only the QoS action is performed according to the predefined PHB on the transit node. This fails to guarantee 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. The P routers, however, 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. QoS parameters are based on the peer PE on the VPN and the peer PE is associated with the TE tunnel. 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.
5-38
Issue 01 (2010-03-01)
5 Service Features
Figure 5-22 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 solution is that the P router and PE routers on the MPLS network reserve bandwidth through the Differentiated Service-Traffic Engineering (DS-TE) signaling protocol for various types of services. In this manner, the network is free from blocking, providing end-to-end bandwidth guarantee. In addition, services transmitted on the tunnel are differentiated. In this scheme, the ingress PE binds the VPN to the DS-TE tunnel and QoS parameters are configured based on the peer PE on the VPN. 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 guarantees the total bandwidth of the DS-TE tunnel. The P router guarantees the bandwidth of the DS-TE tunnel.
Issue 01 (2010-03-01)
5-39
5 Service Features
Figure 5-23 L2VPN/L3VPN with MPLS DS-TE
Backbone network PE2 PE1
VPNA site 3
VPNA site 1
PE3
VPNA site 2 VPNA carries three types of services, ensuring the QoS for each service in the same VPN
VPN-based QoS on the Network Side in an L2VPN/L3VPN

Bandwidths are restricted and guaranteed for different types of services in the VPNs on the network side of the ingress PE. In this manner, services are differentiated and processed. In this scheme, QoS parameters and scheduling models are configured for the VPN of the ingress PE. Queue scheduling is then performed based on VPNs on the network side of the ingress PE. Therefore, the bandwidth of the VPNs is restricted and guaranteed.
5-40
Issue 01 (2010-03-01)
5 Service Features
Figure 5-24 VPN-based QoS on the network side in an L2VPN/L3VPN

flow1 flow2 flow3 flow4 flow5 flow6 flow7 flow8
Scheduler
classfier
port
VSIA : 20
VPN-A:30M VPN-A CE-1 VSI-A PE-1
Interface Interface -based -based PE-2
CE-2 VPN-A VSI-A CE-4
P-2 CE-5 VPN-A P-3 CE-7 VSI-A CE-8 PE-3 CE-6 VPN-A
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 Telephony Network (IPTN) solution to satisfy 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-25 shows the scenario in which the NE40E serves as a service router (SR) in an IPTN network.
Issue 01 (2010-03-01)
5-41
5 Service Features
Figure 5-25 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: Location of the user, namely, 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 NE40E provides the following functions: 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 NE40E provides the QoS features of integrated services including real-time services. In particular, the NE40E supports the following DiffServ functions: Traffic classification Traffic policing Traffic shaping Congestion management Queue scheduling The NE40E 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 NE40E, network operators can provide users with differentiated QoS guarantee,
5-42
Issue 01 (2010-03-01)
5 Service Features
and make the Internet an integrated network that can carry data, voice, and video services at the same time. The following describes the QoS features of the NE40E. 5.7.1 5.7.2 5.7.3 5.7.4 5.7.5 5.7.6 5.7.7 5.7.8 5.7.9 DiffServ Model Traffic Classification Traffic Policing Queue Scheduling Congestion Management Traffic Shaping HQoS QPPB Ethernet QoS
5.7.1 DiffServ Model

When entering a network, services are classified, regulated, and distributed to different behavior aggregates (BAs). A BA is identified by a DSCP code. At the core of the network, packets are forwarded in accordance with the per-hop behavior (PHB) identified by the DSCP code. The advantage of DiffServ is that many service flows converge at a BA and are forwarded according to the same PHB on the router. In this manner, the service processing and storage are simplified. On the DiffServ core network, packet-based QoS ignores the signaling processing.
5.7.2 Traffic Classification

Traffic classification consists of the following steps: 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: No QoS needs to be ensured. No traffic classification is carried out. No rules in the traffic classification are matched by the packets. The NE40E supports simple and complex traffic classification. Complex traffic classification is usually configured on the router at the network edge; simple traffic classification is configured on the core router.
Issue 01 (2010-03-01)
5-43
5 Service Features
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. At present, the NE40E supports traffic classification on the following interfaces: 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 NE40E supports: Classification 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 Classification 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 NE40E supports complex traffic classification on: 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 either discarded or resent after their precedence is re-marked. CAR uses token buckets (TBs) to implement traffic policing. Figure 5-26 shows the procedure of traffic policing with CAR.
5-44
Issue 01 (2010-03-01)
5 Service Features
Figure 5-26 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
The tokens are put into the TB at the rate preset by the user. The capacity of the TB is also preset by users. If the token bucket is full, no more tokens can be added. On arrival, the packets are classified according to the IP precedence, source address, or destination address of packets. The packets that conform to the preset rule go into the TB for further processing. If there are enough tokens in the bucket, packets are forwarded. At the same time, the number of tokens in the bucket decreases based on the length of the packets. If the TB contains insufficient tokens or is empty, the packets not assigned enough tokens are discarded or re-marked with the IP precedence, DSCP, or EXP values before being resent. 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 mark or re-mark packets. CAR is used to limit the traffic rate. With the CAR technology, a TB is used to measure the data traffic that flows through the interfaces on a router so that only the packets assigned tokens go through the router in the specified time period. In this manner, the traffic rate is limited. CAR specifies 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 priority. The traffic not conforming to the conditions is not limited in rate; such traffic is forwarded at the original rate. CAR is mainly applied at the network edge to ensure that the core device can process data normally. The NE40E supports CAR for both the incoming and outgoing traffic.
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 LAN. As a result, when a computer in a 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. Thus, some packets cannot be sent by the router between the LAN and the WAN. The network is congested. As shown in Figure 5-27, when LAN 1 sends packets to LAN 2 at a rate of 10 Mbit/s, traffic congestion occurs on Serial 1 of Router 1.
Issue 01 (2010-03-01)
5-45
5 Service Features
Figure 5-27 Networking diagram of traffic congestion
Frame Relay serial 1 2M PC1 serial 1
ME602
PC2
Ethernet 10M
ME601 Ethernet 10M 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. The 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, delay, 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 FIFO queues. Commonly-used queue scheduling mechanisms are as follows: First In First Out (FIFO) queuing Priority Queuing (PQ) Custom Queuing (CQ) Weighted Fair Queuing (WFQ) Class-Based WFQ (CBWFQ) Low Priority Queuing (LPQ) The NE40E supports FIFO, PQ and WFQ to implement queue scheduling on interfaces.
5.7.5 Congestion Management

The NE40E adopts the Weighted Random Early Detection (WRED) congestion control mechanism. The congestion control mechanism can be configured on each port based on the priority of the queue. The NE40E uses a microsecond-level timer to trace the occupation of the shared memory with the first-order weighted iteration method. In this manner, the NE40E can sense congestion in a timely manner and prevent network flapping. The NE40E drops the packets of
5-46
Issue 01 (2010-03-01)
5 Service Features
different drop priorities with different probabilities within the same traffic. This can effectively prevent and control network congestion.
5.7.6 Traffic Shaping

When network congestion occurs, traffic policing (CAR technology) is used to control the traffic features of the packets and restrain the traffic. Thus, the packets that do not conform to the traffic features are discarded. Sometimes, to decrease 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 decreases the number of lost packets and satisfies the traffic requirement of the packets. A typical application of TS is to control the burst of outgoing traffic based on the network connection. Thus the packets can be transmitted at a uniform rate. The traffic shaping adopts 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 QoS technology that can control users' traffic and support scheduling according to the priorities of user services. The HQoS of the NE40E has the following functions: Five levels of scheduling is provided for services. Configures parameters such as the maximum queue length, WRED, low delay, SP/WRR, CBS, PBS, and statistics. The system supports the configuration of parameters such as the CIR, PIR, number of queues, and scheduling algorithms between queues for each user. Provides the traffic statistics function. The user can view the bandwidth usage of services and properly distribute the bandwidth by analyzing the traffic. The system supports HQoS of VPLS, L3VPN, VLL, BRAS user, and TE.
5.7.8 QPPB
QPPB propagates the QoS policy through BGP. The receiver of BGP routes can perform the following functions: Sets QoS parameters for BGP routes, such as the IP precedence and traffic behavior, based on the attributes of the 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. The receiver of the BGP route can set the IP precedence and the related specific traffic behavior based on the following attributes: ACL AS path list of routing information Community attribute list of routing information Route cost of routing information
Issue 01 (2010-03-01)
5-47
5 Service Features
Address prefix list Figure 5-28 Networking diagram of applying QPPB
Configure a QoS policy
Advertise routing information AS200 Packets filtered by the QoS policy
AS100
In the complex networking where routing policies need to be modified dynamically, QPPB can applied to simplify the modification of policies on the route receiver. You can modify the routing policy on the BGP route sender to achieve this purpose.
5.7.9 Ethernet QoS

Layer 2 Simple Traffic Classification
The NE40E 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 Diff-Serv 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 senses the 802.1p priority in the inner VLAN tag during QinQ encapsulation. The classes of services are thus not distinguished. 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 to sense the 802.1p value: 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-29, QinQ supports 802.1p re-marking in the following modes: 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.
5-48
Issue 01 (2010-03-01)
5 Service Features
Figure 5-29 Networking diagram of 802.1p re-marking supported by QinQ
Q-in-Q Supports 802.1p Remark ISP Network CE PE
5.8 Load Balancing

In a scenario where there are multiple equal-cost routes to the same destination, the NE40E can perform load balancing on traffic among these routes. The NE40E 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 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 5.8.2 Equal-Cost Load Balancing Unequal-Cost Load Balancing
5.8.1 Equal-Cost Load Balancing

The NE40E 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 the same destination, the NE40E 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.
5.8.2 Unequal-Cost Load Balancing

The NE40E supports the following unequal-cost load balancing modes: 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 NE40E 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
Issue 01 (2010-03-01)
5-49
5 Service Features
bandwidth of logical interfaces changes, traffic is automatically balanced based on the new bandwidth proportion.
5.9 Traffic Statistics

The NE40E provides multiple traffic statistics functions. It can collect statistics on access traffic of different users. The traffic statistics functions are as follows: Helps carriers to analyze the traffic model of the network. Provides reference data for carriers to deploy and maintain DiffServ TE. Supports traffic-based accounting for users that are not monthly-free. 5.9.1 URPF Traffic Statistics
5.9.2 ACL Traffic Statistics 5.9.3 5.9.4 5.9.5 5.9.6 5.9.7 CAR Traffic Statistics HQoS Traffic Statistics Interface-based Traffic Statistics VPN Traffic Statistics TE Tunnel Traffic Statistics
5.9.1 URPF Traffic Statistics

The NE40E collects statistics either on the overall traffic that complies with URPF or on the discarded traffic that does not comply with URPF.
5-50
Issue 01 (2010-03-01)
5 Service Features
Figure 5-30 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 NE40E supports the ACL traffic statistics function. When the created ACLs are applied to QoS and policy-based routing, the NE40E 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 NE40E provides numerous QoS features such as traffic classification, traffic policing CAR, and queue scheduling. Directed at these QoS features, the NE40E provides the relevant QoS traffic statistics function. In traffic classification, the system can collect statistics on the traffic that matches rules and fails to match rules.
Issue 01 (2010-03-01)
5-51
5 Service Features
Figure 5-31 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 the collection of statistics on the following traffic: Total traffic that matches the CAR rule Traffic that is permitted or discarded by the CAR rule Figure 5-32 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.
5-52
Issue 01 (2010-03-01)
5 Service Features
When the same traffic policy is applied to various interfaces, the CAR traffic statistics collection in the traffic policy is based on the interface.
5.9.4 HQoS Traffic Statistics

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

The NE40E supports traffic statistics on interfaces and sub-interfaces.
5.9.6 VPN Traffic Statistics

In a VPLS network, the NE40E can collect statistics on incoming and outgoing traffic of the access L2VPN user when it runs as a PE router. In an L3VPN, the NE40E 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 When MPLS HQoS services are configured, the NE40E, as an ingress PE, can collect statistics on the traffic that is sent on the network side.
5.9.7 TE Tunnel Traffic Statistics

When the NE40E runs as a PE router in an MPLS TE network, it supports the collection of 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 Security Features

Serving as the security gateway for system service access, the NE40E has the following features: Advanced security system structure Abundant security protocols Strict service access control The following section describes the security features that the NE40E supports. 5.10.1 Security Authentication
Issue 01 (2010-03-01)
5-53
5 Service Features
5.10.2 RPF/URPF 5.10.3 5.10.4 5.10.5 5.10.6 5.10.7 5.10.8 5.10.9 5.10.10 MAC Limit Unknown Traffic Suppression DHCP Snooping Local Defense attack GTSM ARP Attack Defense Mirroring Lawful Interception
5.10.1 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. LDP and RSVP support MD5 encrypted text authentication. SNMP supports SNMPv3 encryption and authentication.
5.10.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 manner, URPF can effectively prevent malicious attacks that are launched through the change of the source address.
5.10.3 MAC Limit

With abundant MAC limit functions, the NE40E 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 initiate MAC attacks on the network. MAC address limit supported by the NE40E 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
5-54
Issue 01 (2010-03-01)
5 Service Features
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 prevent attacks. The NE40E supports the following types of limit to MAC address learning: 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 PW-based MAC address learning Limit to MAC address learning based on the combination of the VLAN and port Limit to MAC address learning based on the combination of the port and 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 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 an 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 NE40E provides the following types of MAC address entry deletion: Deletion of MAC address entries based on the combination of the port and VSI Deletion of MAC address entries based on the combination of the port and VLAN Deletion of MAC address entries based on the trunk interface Deletion of MAC address entries based on the outbound QinQ interface
5.10.4 Unknown Traffic Suppression

In the VPLS or Layer 2 network, unknown traffic limit supported by the NE40E functions as follows: Manages users' traffic. Allocates bandwidth to users. In this manner, the network bandwidth is efficiently used and network security is guaranteed.
5.10.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.
Issue 01 (2010-03-01)
5-55
5 Service Features
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-1. Table 5-1 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
5.10.6 Local Defense attack

The NE40E provides a uniform local defense attack module to maintain and manage the defense attack policy of the whole system. An all-around defense 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, with a low priority, sent to the CPU. 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 NE40E 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 a
5-56
Issue 01 (2010-03-01)
5 Service Features
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 prevent the packets from affecting each other to protect the CPU. The NE40E provides convenient methods for configuring CAR parameters: Uniform configuration of CAR parameters for different LPUs Uniform user interface for configuration Configuration of CAR parameters with granularity at the protocol level This makes the configuration interface more user-friendly.
Smallest Packet Compensation

The NE40E 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. 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 NE40E 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 to users are generally non-management interfaces.
5 Service Features
To prevent the devices from being controlled by hackers through non-management interfaces or by flooding management packets, the NE40E 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 NE40E provides the following defense measures against attacks on TCP/IP networks: 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. 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 . 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 NE40E 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 limit, for example, 20000 packets on each LPU, the previous packets are overridden when more packets are cached.
5-58
Issue 01 (2010-03-01)
5 Service Features
5.10.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 prevent the preceding attacks, the NE40E 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 the TCP/IP-based control layer such as the routing protocol from the type of CPU-utilization attacks such as CPU overload. The NE40E supports the following types of GTSM: BGP GTSM OSPF GTSM
5.10.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. 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 to 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 manner, 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.
5 Service Features
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. 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. 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 NE40E filters out the following types of ARP packets: 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 You can configure the system to filter out one or more types 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 NE40E 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. The device implements level-one CAR for packets before they are sent to a CPU. If the sending rate of the ARP packets exceeds the level-one CAR, the ARP packets that exceed the configured threshold are discarded. The device then compares the rate of the ARP packets surviving level-one CAR with the level-two CAR. If the rate exceeds the configured threshold, these ARP packets are limited. If ARP packets do not exceed the configured threshold of level-one CAR, all ARP packets are sent to the CPU.
5.10.9 Mirroring
Mirroring means that the system copies the forwarding 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 to the observing port to
5 Service Features
observe the traffic. In local mirroring, the observing port and mirroring port reside on the same device. In remote mirroring, the observing port and mirroring port reside on different devices. The NE40E 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: 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. Mirroring is divided into the following types according to the direction in which the packets are copied: 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-33 shows the networking diagram of applying local mirroring. Figure 5-33 Networking diagram of applying local mirroring
ME60 Network 1 Port A Incoming packets PortC Port B Outgoing packets Mirroring packets Network 2
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 to 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.
Issue 01 (2010-03-01)
5-61
5 Service Features
When local mirroring is implemented, inter-LPU mirroring is supported.
Remote Mirroring
Compared with local mirroring, remote mirroring features the following: 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-34 shows the networking diagram of applying remote mirroring. Figure 5-34 Networking diagram of applying remote mirroring
ME60C IP/MPLS backbone network Customer1
Packet analysis equipment
ME60A ME60D Customer2
ME60B
Router A and Router B are edge routers on the IP/MPLS backbone network. Customer 1 and Customer 2 access the backbone network through Router C and Router D respectively. To maintain the network, analyze attacks, and locate faults, you need to check whether the protocol packets sent from or received by Router A are correct; or you need to check whether the sub-interfaces of a VPN user bound to Router C are attacked. In this manner, you need to copy a type of protocol packets received by Router A, protocol packets sent from Router A to Router C, or packets received by sub-interfaces on Router A to Router B. Router 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 NE40E provides MPLS LSPs, MPLS TE tunnels for remote mirroring. In remote mirroring, multiple observing ports and mirroring ports can be configured on an LPU. In remote mirroring, the mirroring packets can be intercepted.
5-62
Issue 01 (2010-03-01)
5 Service Features
5.10.10 Lawful Interception

Lawful interception indicates that law enforcement agencies lawfully intercept user information after being authorized. In lawful interception, the following information is intercepted: Contents of Communication (CC): indicates the contents of the communication such as emails and VoIP packets. Intercept Related Information (IRI): indicates information related to the communication, including the address, time, and network location. The CC and IRI can be obtained through the network devices of the carrier. The IRI is generally obtained through the AAA server. The CC is obtained through the interception device, for example, the NE40E. Figure 5-35 shows the scenario for lawful interception.
In this scenario, the IRI is provided by the AAA server and the CC is provided by the NE40E.
Figure 5-35 Scenario of lawful interception
LIG management system AAA Server

HI1
Interception center 1
HI2
L1 X1,X2
Internet
X1,X3
Interception center 2
HI3
LIG Interception center N
ME60
Lawful interception involves the following roles: 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:

Defines the intercepted target. Initiates or terminates the interception. Receives and records the interception result. Analyzes the interception result.
Interception management center
Issue 01 (2010-03-01)
5-63
5 Service Features
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 L1 and HI1 interfaces. Delivers the configuration of interception to network devices and obtains intercepted contents through X interfaces. Sends the intercepted contents to the interception management center through HI2 and HI3 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 an L1 interface. The LIG is located on 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.11 Network Reliability

The NE40E supports comprehensive reliability technologies, which satisfy the requirements of the carrier-class network.
5-64
Issue 01 (2010-03-01)
5 Service Features
Figure 5-36 Reliability technologies
Backup
Interface backup
Link reliability
NSF
BFD
Routing optimization
FRR
Device reliability
99.999%
Network reliability
Ative/standby Eth Trunk Customized Grace IP Trunk alarm damping Restart MPUs Multiple SFUs Inter-board Ethernet OAM port binding Active/standby power modules
Fast route IP FRR Fast convergence TE FRR detection LDP FRR ECMP of link VLL FRR NSR fault VPN FRR ISSU
5.11.1 5.11.2 5.11.3 5.11.4 5.11.5 5.11.6 5.11.7 5.11.8
Backup of Key Modules High Reliability of the LPU Transmission Alarm Customization and Suppression VRRP GR BFD Auto FRR NSR
5.11.1 Backup of Key Modules

The NE40E can be installed with a single SRU/MPU or two SRU/MPUs in backup mode. The SRU/MPU of the NE40E supports hot backup. If the NE40E is installed with two SRU/MPUs, the master SRU/MPU works in the active state and the slave SRU/MPU works in the standby state. Users cannot access the MEth interface on 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 backup data) with only the master SRU/MPU rather than other boards or devices. The system supports two switchover modes: failover and manual switchover. The failover is triggered by serious faults or resetting of the master SRU/MPU. The manual switchover is triggered by commands that are run on the console interface. You can forcibly prohibit the active/standby switchover of the SRU/MPU by using related commands. The NE40E supports backup of the management bus and 1+1 backup of the power supply modules. The LPUs, power supply modules, and fan modules are hot swappable. In this manner, when a critical fault occurs on the device or network, the system can quickly recover and respond. This reduces the Mean Time between Failure (MTBF) and minimizes the impact of unreliable factors on normal services.
Issue 01 (2010-03-01)
5-65
5 Service Features
5.11.2 High Reliability of the LPU

The NE40E supports the backup of protocols on key service interfaces of the same type. The NE40E supports the Virtual Router Redundancy Protocol (VRRP) on Ethernet interfaces. With the extended VRRP, two interfaces located on one router or different routers can back up each other, thus ensuring high reliability of the interfaces. The Eth-Trunk and IP-Trunk support backup between member interfaces within or outside a group. The NE40E supports inter-board trunk bundling.

Users can access different LPUs over double links for inter-board bundling. This ensures high reliability of services. The NE40E implements the inter-board bundling through the high-performance engine and forwards packets in load balancing mode at 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.
Provided with protocol extensions, the NE40E implements backup for key service interfaces. This 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 does not affect the routing table and the services on the interface can be restored quickly.
5.11.3 Transmission Alarm Customization and Suppression

At present, the carrier-class network requires higher reliability on the IP network. Thus, the device on the network is required to rapidly detect the fault. After fast detection is enabled on the interface, the interface frequently alternates between Up and Down states because alarm reporting becomes faster. As a result, the network frequently flaps. Thus, alarms need to be filtered and suppressed to prevent frequent flapping of the network. Transmission alarm suppression can efficiently filter and suppress the alarm signals. This prevents the interface from frequently flapping. In addition, transmission alarm customization controls the impact on the interface status by alarms. Transmission alarm customization and suppression implement the following functions: Customizes alarms. This specifies the alarms that can cause the status change of interfaces. Suppresses alarms. This filters the burr and prevent the network from frequently flapping.
5.11.4 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 a LAN that supports multicast or broadcast, such as Ethernet. VRRP uses logical gateways to ensure high availability of transmission links. This prevents service interruption that results from a gateway device failure, without changing the configuration of routing protocols.
5-66
Issue 01 (2010-03-01)
5 Service Features
VRRP groups routers on a LAN into a backup group that functions as a virtual router. Hosts on the LAN know the IP address of only this virtual router rather 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. In this manner, hosts on the LAN can access other networks through the virtual router. In the backup group, only one router is active and is called the master router; other routers are in the backup state with different priorities and are called the backup routers. Figure 5-37 shows the networking diagram of a VRRP backup group consisting of three routers. Figure 5-37 Networking diagram of VRRP
10.100.10.2/24 PC
Master RouterA
10.100.10.3/24 Backup RouterB Server Internal network Backup 10.100.10.0/24 Backup group RouterC Virtual IP Address 10.100.10.1/24 10.100.10.4/24 Internet
VRRP dynamically associates the virtual router with a physical router that transmits services. VRRP can select a new router to take over the services when the physical router fails. The entire process is transparent to users, and implements non-blocking communication between the internal network and the external network.
mVRRP
The Management Virtual Router Redundancy Protocol (mVRRP) specifies an mVRRP group. The only difference between an mVRRP group and a common VRRP group is that the mVRRP group can be bound to service VRRP groups and can determine the status of the bound service VRRP groups. An mVRRP group can be bound to multiple service VRRP groups but cannot function as a service VRRP group to be bound to other mVRRP groups. An mVRRP backup group can join a VRRP Group Management Protocol (VGMP) group as a member. After an mVRRP group joins a VGMP group, the mVRRP group can be configured to monitor the status of both the peer and link BFD sessions. The state machine of the mVRRP group, however, loses its independence. Except for the Initialize state, the Backup and Master states are determined by the status of the VGMP group that the mVRRP group joins.
Issue 01 (2010-03-01)
5-67
5 Service Features
VGMP
Some applications require the session with the same come-and-go path. That is, the packets of the same session must pass through the same device. In this case, VRRP has its own limitations. If the active/standby switchover is performed, the come-and-go paths of the same session may be inconsistent. To prevent the preceding problem, Huawei develops the VGMP on the basis of VRRP. The VRRP management group set up on the basis of VGMP manages the status of joining VRRP groups. On a router, the interfaces that belong to different VRRP groups are thus kept active or standby simultaneously. In this manner, the VRRP status of the router is kept consistent. VGMP is required in the following scenarios: The system is configured with a large number of VRRP groups. The system processes the VRRP protocol packets on the SRU/MPU. A large number of VRRP groups may generate a large number of VRRP protocol packets. These protocol packets compete with other protocol packets for CPU resources and the channel as well as the bandwidth of the inter-board communication. In this case, the system is overloaded. To decrease the system resources occupied by protocol packets, you can configure a VRRP management group to control these VRRP backup groups. Thus, the VRRP backup groups do not send packets by themselves and occupy less system resources. The routers are enabled with the firewall, NAT gateway, or policy server. These functions require the same come-and-go path of the same session. Configuring a VRRP management group to uniformly manage the VRRP groups ensures that the status of the VRRP groups is consistent.
E-VRRP
E-VRRP is designed to improve reliability on a network that is not enabled with multi-homed Stream Control Transmission Protocol (SCTP) or load balancing.
5-68
Issue 01 (2010-03-01)
5 Service Features
Figure 5-38 E-VRRP networking
G9 Bearer Network
ME60
ME60
MSoft
UMG
HLR Media interface
Singaling interface
As shown in Figure 5-38, the MsoftX, Universal Media Gateway (UMG), and Home Location Register (HLR) are dual-homed to the master and backup routers on a VRRP network. You can ensure the reliability on the media plane by connecting UMG to the VRRP network and the reliability on the signaling plane through dual-homed SCTP. If the devices do not support SCTP, you can configure E-VRRP to ensure the reliability.
VRRP for IPv6

In VRRP for IPv6, VRRP is applied to an IPv6 network with the VRRP principles unchanged.
Issue 01 (2010-03-01)
5-69
5 Service Features
Figure 5-39 Networking diagram of VRRP for IPv6
Virtual IP Address: 2002::1

2002::2 HostA
ME60A
Master
ME60B
2002::3 HostB Backup
Network ME60C
2002::4 Backup
HostC
Ethernet
As shown in Figure 5-39, IPv6 runs on each host and each router on an IPv6 network. A VRRP group, consisting of a group of routers on a LAN, functions as a virtual router. The hosts on the LAN set the IPv6 address of the virtual router as the default gateway. In this manner, the hosts only need to obtain the IPv6 address of the virtual router rather than that of a specific router and use the default gateway to communicate with external networks. To ensure reliability and utilize routers, you can create multiple VRRP groups to balance traffic on the network.
5.11.5 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 routing information from the routing table or the FIB nor resets the board during the switchover when faults occur. This prevents services interruption of the entire system. GR has the following advantages: 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. 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. The NE40E supports system-based GR and protocol-based GR. The protocol-based GR includes: BGP GR OSPF GR
5-70
Issue 01 (2010-03-01)
5 Service Features
IS-IS GR MPLS LDP GR L3VPN GR RSVP GR PIM GR
5.11.6 BFD
BFD is a detection mechanism used on the entire network. It can quickly detect and monitor the connection of links and forwarding state of the IP route on the network. Detection packets are transmitted from both ends of a bidirectional link. The NE40E tests the link status from both directions to detect failures in milliseconds. The NE40E supports single-hop BFD and multi-hop BFD. The following describes the BFD features supported by the NE40E.
BFD for VRRP

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

BFD for LDP FRR BFD can detect the protected interfaces that can trigger LDP FRR switching. BFD for IP FRR and BFD for VPN FRR On the NE40E, 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 a detection mechanism. When the network fails, an administrator is required to reconfigure static routes. With this feature, the BFD session can be used to detect the status of the IPv4 static route on 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 NE40E 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 IPv6 IS-IS

The NE40E supports IPv6 IS-IS to dynamically set up and delete a BFD session. When a routing protocol sets up a neighbor relationship, the routing protocol notifies BFD through the routing management (RM) module to establish sessions. The neighbor
Issue 01 (2010-03-01)
5-71
5 Service Features
relationship of the routing protocol is rapidly detected. The detection parameters of BFD sessions are negotiated by both ends through the routing protocol. When detecting a fault, a BFD session goes Down. BFD triggers route convergence through the RM module.
Generally, routing protocols implement detection in seconds through the Keepalive mechanism of Hello messages, whereas BFD carries out detection in milliseconds. When the detection interval is 10 ms and the detection multiplier is 3, BFD can report protocol failures within 50 ms. This speeds up route convergence.
When a routing protocol sets up a neighbor relationship, the routing protocol notifies BFD through the RM module to establish sessions. The neighbor relationship of the routing protocol is rapidly detected. The detection parameters of BFD sessions are negotiated by both ends through the routing protocol. When the neighbor is unreachable, the routing protocol notifies BFD to delete the session through the RM module.
BFD for OSPF/BGP

The NE40E supports OSPF and BGP to dynamically set up and delete a BFD session. When a routing protocol successfully sets up a neighbor relationship, the routing protocol notifies BFD to establish sessions through the RM module and fast detects the neighbor relationship of the routing protocol. The detection parameters of the BFD session are set by the routing protocol. When a BFD session detects the fault, the BFD session goes Down. BFD triggers route convergence through the RM module.
Generally, routing protocols implement detection in seconds through the Keepalive mechanism of Hello messages, whereas BFD carries out detection in milliseconds. When the detection interval is 10 ms and the detection multiplier is 3, BFD can report protocol failures within 50 ms. This speeds up route convergence.
When the neighbor is unreachable, the routing protocol notifies BFD to delete the session through the RM module.
BFD for OSPFv3/BGP4+

The NE40E supports OSPFv3 and BGP4+ to dynamically set up and delete a BFD session. When a routing protocol sets up a neighbor relationship, the routing protocol notifies BFD to establish BFD sessions through the RM module and fast detects the neighbor relationship of the routing protocol. The detection parameters of BFD sessions are negotiated by both ends through the routing protocol. When detecting a fault, a BFD session goes Down. BFD triggers route convergence through the RM module.
Generally, routing protocols implement second-level detection through the Keepalive mechanism of Hello messages, whereas BFD carries out millisecond-level detection. When the detection interval is 10 ms and the detection multiplier is 3, BFD can report protocol failures within 50 ms. This speeds up route convergence.
When the neighbor is unreachable, the routing protocol notifies BFD to delete the session through the RM module.
5-72
Issue 01 (2010-03-01)
5 Service Features
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. A trunk can be Up only when the number of its member links in the Up states reaches a certain value. On the NE40E, BFD can detect the connectivity of a trunk and a member interface of the trunk independently.
BFP for LSP

BFD for LSP indicates that BFD packets are transmitted along a static LSP, a dynamic LSP, an RSVP-TE tunnel, or a PW. By fast transmitting and receiving BFD packets, fast detection of the link fault can be carried out. The carried services can thus be fast switched for service protection in the case of a failure. BFD for LSP performs fast detection of faults on LSPs, TE tunnels, and PWs. In this manner, BFD for LSP implements fast switchover of MPLS services such as VPN FRR, TE FRR, and VLL FRR services.
5.11.7 Auto FRR

The NE40E provides multiple FRR features. You can deploy FRR as required to improve network reliability.
IP FRR
FRR can minimize data loss caused by network faults. The switching time can be achieved in 50 ms. The NE40E 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 reduces the Mean Time Between Failures (MTBF) and the amount of lost packets.
LDP FRR
The traditional IP FRR cannot effectively protect traffic on the MPLS network. The NE40E provides LDP FRR 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.
Issue 01 (2010-03-01)
5-73
5 Service Features
Normally, a packet is forwarded through the primary LSP. When the outgoing interface of the primary LSP goes Down, the packet is forwarded through the backup LSP. This ensures the transmission of traffic before network convergence.
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 50 ms. 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. With different protected objects, TE FRR is classified into the following types: Link protection: There is a direct link between the PLR and MP, and the primary LSP passes through this link. When this link is invalidated, the traffic can be switched to the bypass LSP. In Figure 5-40, the primary LSP is R1->R2->R3->R4; the bypass LSP is R2->R6->R3. Figure 5-40 Diagram of TE FRR link protection
PLR
MP
R1
R2 Primary LSP Bypass LSP R6
R3
R4
Node protection: In Figure 5-41, the PLR and the MP are connected through R3, and the primary LSP passes through R3. The primary LSP is R1->R2->R3->R4->R5; the bypass LSP is R2->R6->R4; R3 is the protected router. When R3 fails, the traffic can be switched to the bypass LSP.
5-74
Issue 01 (2010-03-01)
5 Service Features
Figure 5-41 Diagram of TE FRR node protection
PLR
MP
R 1
R 2
Primary LSP Bypass LSP
R 3
R 4
R 5
R 6
VLL FRR
VLL FRR implements network protection on an L2VPN. It fast switches user traffic to the backup link after a fault occurs on the network. This improves the reliability of the L2VPN. VLL FRR is also called VLL redundancy. VLL FRR on the L2VPN includes fault detection, fault notification, and active/standby switchover of links. The NE40E provides various types of features that can be combined to implement VLL FRR. Fault detection. BFD for PW can fast detect the fault of the PW at the network side on an L2VPN. Ethernet OAM can fast detect the fault at the attachment circuit (AC) side on an L2VPN. Fault notification LDP, BGP, or RSVP can notify the remote PE of the fault on the LSP/PW or the AC. BFD for LSP/PW can notify the remote PE of the fault on the LSP/PW or the AC. Ethernet OAM can notify the local CE of the fault. Active/standby switchover of links. On a symmetric network, CEs perform the active/standby switchover. On an asymmetric network, PEs work with CEs to perform active/standby switchover.
IPv6/IPv4 VPN FRR

On the traditional L3VPN, a local PE senses the fault of a remote PE by transmitting BGP Hello packets. The time taken to sense the fault defaults to 90 seconds. That is, VPN routes on the local PE converge after the fault of the remote PE router lasts 90 seconds. IPv6/IPv4 VPN FRR supported by the NE40E can solve the preceding problem. When a CE is dual-homed to two PEs, IPv6/IPv4 VPN FRR can fast switch VPN services to the backup tunnel and backup PE after the link between the CE and the PE is disconnected or after the PE restarts. In this manner, services are restored within a short period. The forwarding engine of the local PE keeps not only the outer labels of the remote active PE and the inner labels distributed to VPN routes, but also the outer labels of the remote standby PE and the inner labels distributed to VPN routes.
Issue 01 (2010-03-01)
5-75
5 Service Features
With the end-to-end fault detection mechanisms such as BFD, the local PE senses the fault of the remote active PE within 200 milliseconds and then switches the outer and inner labels of the remote active and standby PEs at the same time. VPN FRR switches the inner labels. Its switching priority level is lower than that of LDP/MPLS TE FRR. In this case, the time to sense the fault is longer than the protection switching time of LDP/MPLS TE FRR.
5.11.8 NSR
Non-Stop Routing (NSR) ensures that the control plane of a neighbor does not sense the fault on the control plane of a router that provides a slave control plane. In this process, the neighbor relationships set up through specific routing protocols, MPLS, and other protocols that carry services are not interrupted. As an HA solution, NSR ensures that user services are not affected or least affected in the case of device failures.
IS-IS NSR
IS-IS NSR ensures that the real-time data is highly synchronized between the master and slave MPU/SRUs. In this manner, in the case of the master/slave switchover, the slave MPU/SRU can rapidly take over services on the master MPU/SRU with neighbors not sensing router failures.
BGP NSR
During the master/slave switchover, BGP NSR ensures the continuous forwarding at the lower layer and continuous advertisement of BGP routes. In this process, the neighbor relationships are not affected, with neighbors not knowing the switchover on the local router. This ensures uninterrupted transmission of BGP services.
5-76
Issue 01 (2010-03-01)
6 Application Scenarios
6
About This Chapter
6.1 Application on a Metro Ethernet
Application Scenarios
6.1 Application on a Metro Ethernet

As shown in Figure 6-1, the metro Ethernet consists of the core layer, edge layer, aggregation layer, and access layer. The core layer is responsible for the high-speed forwarding of service data. The edge layer and aggregation layer serve as the access points of various services. The services are transmitted to the network through the BRAS, the centralized PE, or the aggregation node, based on the service type. The access layer is responsible for user access, and the devices at the access layer include the Digital Subscriber Line Access Multiplexer (DSLAM), convergence switch, AG, and Node B. Figure 6-1 Networking diagram of a Metro Ethernet
Access
Ethernet Aggregation Distribution node
Edge
Core
Applicatio
I n t e rnet
BRAS DSLAM CMTS Aggregafion Node VoD ES Distribution node AccSwitch PE P/PE P/PE P/PE
Internet
SoftX
VoD CS
Issue 01 (2010-03-01)
6-1
The aggregation layer device accesses and forwards services through IP/MPLS. Individual services are converged to the aggregation node through the DSLAM; corporate services are converged at Layer 2 through a switch or are directly converged to the aggregation node. DSLAM: accesses individual services through permanent virtual circuits (PVCs). The DSLAM adds VLAN or QinQ tags to services 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 VLAN or QinQ user services, forwards Layer 3 services or VPN services, or transparently transmits services to the BRAS or the centralized PE through IP/MPLS. Distribution node: converges services on the metro Ethernet. The distribution node terminates IP/MPLS and transparently transmits services to the BRAS or the centralized PE. BRAS: 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 backbone network. A P or a PE rapidly forwards or converge services to the backbone network. The NE40E can be applied to the aggregation node and the distribution node to guarantee the access of individual services and corporate services.
Individual Services
HSI service: The DSLAM adds QinQ tags to distinguish user services. The outer VLAN tag indicates the service type. The NE40E at the aggregation node transparently transmits the services to the distribution node that can be the NE40E through EoMPLS (VLL or VPLS). The distribution node terminates the transmission and then transparently transmits the QinQ data to the BRAS. VOD/VoIP: The NE40E at the aggregation node terminates the VLAN or QinQ tags added by the DSLAM, and forwards the services to the Layer 3 network or converges the services to the L3VPN for transmission. BTV: The NE40E 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 PIM, and then sends the data to the DSLAM through multicast VLAN. The user joins or quits a group through IGMP, and the popular channels send data to the DR through a static route.
Corporate Services
Corporate dedicated line: The corporate dedicated line is connected to the Layer 3 network through the NE40E at the aggregation node. E-LINE: The PW, an end-to-end L2VPN tunnel, is set up between the NE40E at the aggregation node and the peer end. 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 NE40E at the aggregation node creates VSIs, and forwards service data to different VSIs for forwarding after the VLAN or QinQ tag is identified. The service data can also be converged to the E-LAN services through HVPLS, during which VSIs are created by the distribution node.
L3VPN: Services are converged to the Virtual Route Forwarding (VRF) at the aggregation node, or converged to the centralized service node for VRF forwarding through HoVPN.
IP RAN Solutions
Services of a 2G RAN network, mainly a small volume of voice services, are transmitted over TDM links. Usually one to three E1 interfaces on a BTS are connected to a BSC. Some wireless carriers do not have fixed network infrastructure, and have to lease E1 lines of fixed-line networks, which costs a lot. Services between the BTSs and BSCs in the same city can be transparently transmitted over TDM links on a Metro Ethernet network. For a 2G RAN network, a Packet Switching Network (PSN) is constructed through NE40Es between the BTSs and a BSC. The NE40E is connected to the BTSs in the downstream through E1/T1 links, and to the BSC in the upstream through n x E1/T1 links or 155-Mbit/s links, as shown in Figure 6-2. Mobile carriers in worldwide construct RANs one after another. The 2G RAN network is based on TDM/SDH, and thus it has a lower bandwidth usage, is hard to expand, and is inflexible to configure. Therefore, IP RAN is a trend. UMTS R99/R4 defines ATM as the protocol used during the transmission of services between the Node B and RNC, with E1 IMA interfaces connecting the two ends. Figure 6-2 shows the networking diagram. Figure 6-2 2G/3G RAN solutions
E1 T
DM *N
CX600
CX600 E1 TDM*N
E1 TDM
BSC MPLS over SDH/ME N *E1(ATM IMA) FE Node B

A) IM
N *E1(ATM IMA) GE CX600 RNC
CX600
M AT 1( FE *E
Transparent transmission of ATM cells through PWE3 Transparent transmission of TDM services
Node B
Deploying routers on an metro Ethernet MPLS network can solve the problem of bandwidth multiplexing. Node B is connected to the NE40E that supports E1 IMA interfaces. After the NE40E terminates IMA, the high-speed ATM cell flows are transparently transmitted through ATM PWE3 to the NE40E at the RNC side. Then, The NE40E at the RNC side classifies the high-speed ATM cell flows into n x E1 links, and sends multiple channels of low-speed cells to the RNC. For the Node B and RNC, the NE40E and MPLS network are transparent. It
Issue 01 (2010-03-01)
6-3
functions as if multiple E1 interfaces on the Node B and RNC were directly connected through the TDM link.
1588v2 Clock Synchronization

As shown in Figure 6-3, the bearer network synchronizes its time through GPS or external time sources, and then provides the clock or time externally. The nodes on the bearer network can trace a BITS clock. All the nodes on the network serve as boundary clocks (BCs), and all the BCs support the peer delay mechanism to meet the requirement of fast switchover of links. The BCs encapsulate the clock information in multicast packets, and then send the multicast packets to the Node B. The nodes that do not support IEEE 1588 can be configured to support GPS if these nodes are connected through POS links. The Node B that does not support IEEE 1588 synchronizes frequency through Ethernet clock synchronization or WAN interfaces. Figure 6-3 Clock synchronization in IEEE 1588v2
GPS
GPS
BC 1588v2 GE BC
POS 1588v2 GE BC
BC
FE 1588v2
E1
E1
FE 1588v2
NodeB NodeB with 1588v2 without 1588v2
NodeB without 1588v2
NodeB with 1588v2
6-4
Issue 01 (2010-03-01)
7 Operation and Maintenance
7
About This Chapter
7.1 Benefits 7.2
Operation and Maintenance
Network Management System
7.1 Benefits
7.1.1 7.1.2 7.1.3 7.1.4 7.1.5 7.1.6 7.1.7 7.1.8 7.1.9 System Configuration Mode System Management and Maintenance HGMP System Service and Status Tracking System Test and Diagnosis In-Service Debugging Upgrade Features GTL Miscellaneous Features
7.1.1 System Configuration Mode

The NE40E provides two configuration modes: command line configuration and NMS configuration. Command line configuration supports: Local configuration through the console port Remote configuration through the AUX port with a Modem Remote configuration through Telnet NMS configuration supports the configuration through the SNMP-based NMS.
Issue 01 (2010-03-01)
7-1
7.1.2 System Management and Maintenance

The NE40E provides the following system management and maintenance functions: In-service board detection, hot swap detection, Watch Dog, board reset, control over running and debugging indicators, fan monitoring, power monitoring, active/standby switchover, 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 comments for command lines Multi-user operation Collection of multi-layer information, including information about ports, Layer 2, and Layer 3 Hierarchical management, alarm classification, and alarm filtering
7.1.3 HGMP
The NE40E 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 NE40E 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 the external communication, simplifying device management and saving IP addresses.
7.1.4 System Service and Status Tracking

The NE40E can track the system service and status as follows: 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 through debugging. Monitors and clears the statistics about abnormal packets. Displays notification when the processing of the abnormality takes effect. Collects the statistics about the resources occupied by each feature.
7.1.5 System Test and Diagnosis

The NE40E provides debugging for running services. It can in-service record key events, packet processing, packet resolution, and state switchover in a 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 NE40E 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
7-2
Issue 01 (2010-03-01)
information to locate faults. 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 NE40E classify information. The sensitive information of different classes is directed to different output destinations based on the user configuration. The output destinations include the console display, Syslog server, and SNMP Traps. The NE40E also provides the Network Quality Analysis (NQA) function. NQA measures the performance of each protocol that runs on 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 incorrect 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 on the network.
7.1.6 In-Service Debugging

The NE40E provides port mirroring which is used to map the specified traffic to a monitored port so that maintenance personnel can debug and analyze the operation status of the network.
7.1.7 Upgrade Features

In-Service Upgrade
The system supports in-service upgrading and patching of software. You can upgrade only the features that require modification.
System Upgrade
The system upgrade optimizes the upgrade process. You can use one command to complete the upgrade, which saves time for users. During the upgrade process, the progress is displayed. After the upgrade is complete, you can view the results.
Rollback
During the upgrade 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 upgrade.
7.1.8 GTL
The NE40E 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: 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 NE40E provides flexible authorization of service features.
Issue 01 (2010-03-01)
7-3
The NE40E provides a management platform of license authorization through the Global Trotter License (GTL). This achieves the authorization of service features. In this mode, the following are achieved: 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 GTL, the NE40E manages the features of L3VPN, MVPN, 1588v2.
7.1.9 Miscellaneous Features

The NE40E provides the following additional configuration features: Hierarchical protection for configuration commands, ensuring that the unauthorized users cannot access the router. Online help available if you type a question mark (?). 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 keyword "disp" for the display command.
7.2 Network Management System

NMS
The NE40E adopts the Huawei iManager U2000 NMS. It supports SNMP V1/V2c/V3 and the client/server model. The NMS can operate on multiple operating systems such as Windows NT/2000/XP and UNIX (SUN, HP, and IBM). The NMS provides graphic user interfaces in multiple languages. The iManager U2000 NMS can be seamlessly integrated with the NMS of other Huawei fixed network telecommunication equipment for centralized management. The U2000 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 allows the U2000 NMS to perform the unified management on the devices of multiple vendors. The U2000 NMS provides the follow management functions: Real-time management on the topology Fault Performance Configuration tool Equipment log Security and users QoS policy VPN service In addition, it can be used to download, save, modify, and upload configuration files, as well as upgrade system software.
7-4
Issue 01 (2010-03-01)
LLDP
At present, the Ethernet technology is extensively used on 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 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 they connect 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 in a timely manner.
Issue 01 (2010-03-01)
7-5
8 Technical Specifications
8
About This Chapter
8.1 8.2 8.3 Physical Specifications System Configuration System Features
Technical Specifications
8.1 Physical Specifications

8.1.1 8.1.2 NE40E-X2 NE40E-X1
8.1.1 NE40E-X2
Table 8-1 Parameters of the NE40E-X2 Item Dimensions (W x D x H) Installation Weight Maximum power Heat dissipation DC input voltage Rated voltage Maximum voltage range Ambient Long-term Description 442 mm x 220 mm x 222 mm (5 U height) Mounted in an N63E cabinet, a standard 19-inch cabinet, or a 23-inch North American open rack Full configurations: 21 kg 740 W 2401 BTU/hour -48 V -72 V to -38 V
0C to 45C
Issue 01 (2010-03-01)
8-1
Item temperature Short-term
Description -5C to 55C (Short-term means that the continuous working time does not exceed 48 hours and the accumulated time per year does not exceed 15 days. Long-term refers to the contrary situation.) Limit of the temperature change rate: 30C/hour -40C to +70C 5% RH to 85% RH, no coagulation 5% RH to 95% RH, no coagulation 0% RH to 95% RH, no coagulation Lower than 3000 m Lower than 5000 m
Remarks Storage temperature Relative humidity Long-term Short-term
Storage humidity Long-term altitude Storage altitude
8.1.2 NE40E-X1
Table 8-2 Parameters of the NE40E-X1 Item Dimensions (W x D x H) Installation Weight Maximum power Heat dissipation DC input voltage Rated voltage Maximum voltage range Ambient temperature Long-term Short-term Description 442 mm x 220 mm x 132 mm (3 U height) Mounted in an N63E cabinet, a standard 19-inch cabinet, or a 23-inch North American open rack Full configurations: 13 kg 470 W 1525 BTU/hour -48V -72V to -38V
0C to 45C -5C to 55C (Short-term means that the continuous working time does not exceed 48 hours and the accumulated time per year does not exceed 15 days. Long-term refers to the contrary situation.) Limit of the temperature change rate: 30C/hour -40C to +70C 5% RH to 85% RH, no coagulation
Remarks Storage temperature Relative Long-term
8-2
Issue 01 (2010-03-01)
Item humidity Short-term
Description 5% RH to 95% RH, no coagulation 0% RH to 95% RH, no coagulation Lower than 3000 m Lower than 5000 m
Storage humidity Long-term altitude Storage altitude
8.2 System Configuration

8.2.1 8.2.2 NE40E-X2 NE40E-X1
8.2.1 NE40E-X2
Table 8-3 Default configurations on the NE40E-X2 Item Processor SDRAM CF card Default Configuration Dominant frequency: 1 GHz 2 GB 1 GB Remarks The CF card within the MPU stores system files and does not support hot swap. The USB2.0 interface is hot swappable and used for software upgrade or temporary data access. -
USB interface
USB2.0 Host
Switching capacity User interface capacity Number of subcard slots Number of MPU slots Number of NPU slots
80 G (bi-directional) 75.2 G 8 2 2
Issue 01 (2010-03-01)
8-3
8.2.2 NE40E-X1
Table 8-4 Default configurations on the NE40E-X1 Item Processor SDRAM CF card Default Configuration Dominant frequency: 1 GHz 2 GB 1 GB Remarks The CF card within the MPU stores system files and does not support hot swap. The USB2.0 interface is hot swappable and used for software upgrade or temporary data access. Slots for the LPUs (optional)
USB interface
USB2.0 Host
Switching capacity User interface capacity Number of subcard slots Number of MPU slots Number of NPU slots
40 G (bi-directional) 52 G 4 2 1
8.3 System Features

Table 8-5 System features Feature Interworking Description LAN protocols Ethernet_II IEEE802.1Q IEEE802.1p Link layer protocols PPP or MP RRPP TDM
8-4
Issue 01 (2010-03-01)
Feature
Description 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
Network protocol
IPv4
Static routing protocol Dynamic unicast routing protocols: RIP-1/RIP-2 OSPF IS-IS BGP Multicast protocols: IGMP IGMP snooping PIM-DM PIM-SM PIM-SSM MBGP MSDP Multicast VLAN Multicast VPN Multicast flow control Multicast CAC Routing policies
Issue 01 (2010-03-01)
8-5
Feature
Description IPv6 IPv4-to-IPv6 transition technologies: Manually configured tunnel Automatic tunnel 6to4 tunnel 6PE and 6VPE tunnel IPv6 static unicast routing IPv6 dynamic unicast routing BGP4+ RIPng OSPFv3 IS-ISv6 IPv6 multicast protocols: MLD PIM-IPv6-DM PIM-IPv6-SM PIM-IPv6-SSM DHCPv6
MPLS
Basic MPLS 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 H-VPLS CES
L3VPN
BGP/MPLS L3VPN (with the device functioning as a PE or a P) HoVPN Multicast VPN Inter-VPN Carrier's carrier RRVPN Multi-role host
8-6
Issue 01 (2010-03-01)
Feature
Description IPv6 L3VPN IPv6 BGP/MPLS L3VPN (with the device functioning as a PE or a P) Inter-VPN Carrier's carrier
Hierarchical commands to defend against unauthorized users' login System reliability Hot backup 1:1 backup of MPUs n+1 load balancing and backup of SFUs n+n backup of power modules 1+1 backup of the system management bus and data bus GR Protocol-level GR: IS-ISv4, OSPF, BGP4, LDP, PIM, and VPN System-level GR Others NSR IP FRR LDP FRR TE FRR VLL FRR VPNv4/v6 FRR IPv4/IPv6 VRRP BFD BFDv6 for routing protocol Dampening control to support Up/Down of interfaces Transmission alarm customization and suppression Hot backup between devices E-APS E-Trunk PW redundancy E-STP
Issue 01 (2010-03-01)
8-7
Feature
Description
QoS
Traffic classification Traffic policing and shaping
Simple traffic classification Complex traffic classification: based-on ports or 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 PQ/WFQ WRED Route redirection, MPLS LSP explicit route distribution IP precedence Specific traffic behavior 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 L3VPN Supports traffic classification, traffic shaping, and queue scheduling in L2VPN and L3VPN Supports the combination of MPLS HQoS and MPLS DiffServ/MPLS TE/MPLS DS-TE
Congestion management Congestion avoidance Policy-based routing QPPB BGP accounting MPLS HQoS
QinQ QoS
802.1p re-marking supported by QinQ 802.1p and DSCP re-marking during QinQ termination 802.1p and EXP re-marking during QinQ termination
8-8
Issue 01 (2010-03-01)
Feature
Description HQoS 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
Configuration management
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 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 ISSU
Information center
Providing three types of information: alarm, log, and debugging Providing 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
Issue 01 (2010-03-01)
8-9
Feature
Description Network management SNMP v1/v2c/v3 RMON NetStream Traffic statistics
8-10
Issue 01 (2010-03-01)
9 Compliant Standards
9
About This Chapter
9.1 9.2 9.3 9.4 9.5 Standards and Telecom Protocols Safety Standards Environmental Standards Other Standards
Compliant Standards
Electromagnetic Compatibility Standards
9.1 Standards and Telecom Protocols

AAA RFC2903 RFC2904 RFC2906 ARP RFC1027 BFD draft-ietf-bfd-base-05 draft-ietf-bfd-v4v6-1hop-05 draft-ietf-bfd-multihop-06 draft-ietf-bfd-mpls-02 BGP RFC1105 Border Gateway Protocol BGP Bidirectional Forwarding Detection BFD for IPv4 and IPv6 (Single Hop) BFD for Multihop Paths BFD For MPLS LSPs Using ARP to implement transparent subnet gateways Generic AAA Architecture AAA Authorization Framework AAA Authorization Requirements
Issue 01 (2010-03-01)
9-1
RFC1163 RFC1164 RFC1265 RFC1266 RFC 1267 RFC 1268 RFC1269 RFC1321 RFC1397 RFC1403 RFC1654 RFC1655 RFC1656 RFC1657 RFC1771 RFC1772 RFC1773 RFC1774 RFC1930 RFC1965 RFC1966 RFC1997 RFC1998 RFC2270 RFC2283 RFC2385 RFC2439
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) Application of the Border Gateway Protocol in the Internet Definitions of Managed Objects for the Border Gateway Protocol:Version 3 The MD5 Message-Digest Algorithm 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 basic BGP4 MIB (BGP-4) BGP basic functions support obsoletes RFC 1656 BGP-4 Protocol Analysis 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
9-2
Issue 01 (2010-03-01)
RFC2519 RFC2545 RFC2547 RFC2796 RFC2842 RFC2858 RFC2918 RFC3065 RFC3392 RFC3562 RFC4271 RFC4272 RFC4273 RFC4274 RFC4275 RFC4276 RFC4277 RFC4360 RFC4364 RFC4382 RFC4456 RFC4486 RFC4724 RFC4760 RFC4781 RFC4798 Clock
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 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 information 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)
Issue 01 (2010-03-01)
9-3
IEEE1588
Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems Timing characteristics of SDH equipment slave clocks (SEC) Timing characteristics of SDH equipment slave clocks (SEC) Timing and Synchronization Aspects in Packet Timing characteristics of synchronous Ethernet equipment slave clock (EEC) Distribution of Timing through Packet Networks The control of jitter and wander within digital networks which are based on the 1544 kbit/s hierarchy.
ITU-T G.813 ITU-T G.8261 ITU-T G.8262 ITU-T G.8264 ITU-T G.823 ITU-T G.824
Ethernet RFC0826 Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware (ARP) 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 802.1D Maintenance Rapid Reconvergence of Spanning Tree (RSTP) Provider Backbone Bridges Management Information Base (MIB) definitions for VLAN Bridges Resilient Packet Ring 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 Port Trunk, LACP 10 Gbit/s Ethernet Standard Link Aggregation Control Protocol Connectivity Fault Management
RFC1042 IEEE802.1q IEEE802.1t IEEE802.1w IEEE802.1ah IEEE802.1ap IEEE802.17 IEEE802.2 IEEE802.3
IEEE802.3ad IEEE802.3ae IEEE802.3af IEEE802.1ag
9-4
Issue 01 (2010-03-01)
IEEE802.3ah IEEE802.3z FTP RFC0959 IPv6 RFC1886 RFC1887 RFC1970 RFC2023 RFC2373 RFC2374 RFC2375 RFC2452 RFC2454 RFC2460 RFC2461 RFC2462 RFC2463
Ethernet First Mile Gigabit fiber
File Transfer Protocol (FTP)
DNS Extensions to Support IP version 6 An Architecture for IPv6 Unicast Address Allocation Neighbor Discovery for IP Version 6 (IPv6) IP Version 6 over PPP 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 Transmission of IPv6 Packets over Token Ring Networks IP Version 6 over PPP Generic Packet Tunneling in IPv6 Specification MIB for TCP6 MIB for UDP6 Transmission of Ipv6 over Ipv4 Domains without Explicit Tunnels Transition Mechanisms for Ipv6 Hosts and Routers Connection of Ipv6 Domains via Ipv4 Clouds
RFC2464 RFC2470 RFC2472 RFC2473 RFC2452 RFC2454 RFC2529 RFC2893 RFC3056
Issue 01 (2010-03-01)
9-5
RFC3363 RFC3493 RFC3513 RFC3542 RFC3587 RFC3775 ISIS RFC1142 ISO10598 RFC1195 RFC2104 RFC2763 RFC2966 RFC2973 RFC3277 RFC3359
Representing Internet Protocol version 6 (Ipv6) Addresses in the Domain Name System (DNS). Basic Socket Interface Extensions for IPv6 IP Version 6 Addressing Architecture Advanced Sockets API for Ipv6 An Aggregatable Global Unicast Address Format Mobility Support in IPv6
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 Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System 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 Restart signaling for IS-IS Management Information Base for Intermediate System to Intermediate System (IS-IS) IS-IS intra-domain routing protocol
RFC3373
RFC3567 RFC3719 RFC3784 RFC3786 RFC3787 RFC3847 RFC4444 ISO10589
9-6
Issue 01 (2010-03-01)
L2 protocol RFC1216 RFC1619 RFC1717 RFC2285 RFC2665 RFC2674 Gigabit network economics and paradigm shifts PPP over SONET/SDH prior to insertion into SPE The PPP Multilink Protocol (MP) Benchmarking Terminology for LAN Switching Devices Definitions of Managed Objects for the Ethernet-like Interface Types Definitions of Managed Objects for Bridges with Traffic Classes,Multicast Filtering and Virtual LAN Extensions The Interfaces Group MIB MIB for FRF.16 UNI/NNI MFR Circuit to Interface MIB Definitions of Managed Objects for the Ethernet-like Interface Types IP Tunnel MIB Physical/electrical characteristics of hierarchical digital interfaces Synchronous frame structures used at 1544, 6312,2048, 8448 and 44 736 kbit/s hierarchical levels. Network node interface for the synchronous digital hierarchy (SDH) The control of jitter and wander within digital networks which are based on the synchronous digital hierarchy (SDH). The control of jitter and wander within digital networks which are based on the 2048 kbit/s hierarchy. The control of jitter and wander within digital networks which are based on the 1544 kbit/s hierarchy. Synchronous Optical Network(SONET) Basic Description Including Multiplex Structures, Rates, and Formats ANSI T1.105.02 Synchronous Optical Network(SONET) Payload Mappings
RFC2863 RFC3020 RFC3201 RFC3635 RFC4087 ITU-T G.703 ITU-T G.704
ITU-T G.707 ITU-T G.825
ITU-T G.823
ITU-T G.824
ANSI T1.105
Issue 01 (2010-03-01)
9-7
L3 protocol RFC2544 RFC2668 MPLS RFC2205 RFC2209 RFC2210 RFC2702 RFC2747 RFC2961 RFC3031 RFC3032 RFC3035 RFC3036 RFC3037 RFC3063 RFC3107 RFC3209 RFC3210 RFC3212 RFC3214 RFC3215 RFC3270 RFC3272 RFC3443 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 Requirements for Traffic Engineering Over MPLS RSVP Cryptographic Authentication RSVP Refresh Overhead Reduction Extensions Multiprotocol Label Switching Architecture MPLS Label Stack Encoding MPLS using LDP and ATM VC Switching LDP Specification LDP Applicability MPLS Loop Prevention Mechanism Support BGP carry Label for MPLS RSVP-TE Extensions to RSVP for LSP Tunnels Benchmarking Methodology for Network Interconnect Devices Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs).
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
9-8
Issue 01 (2010-03-01)
RFC3469 RFC3478 RFC3479 RFC3496
Framework for Multi-Protocol Label Switching (MPLS)-based Recovery Graceful Restart Mechanism for LDP Fault Tolerance for the Label Distribution Protocol (LDP) Protocol Extension for Support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP) 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 Generalized MPLS Signaling - RSVP-TE Extensions 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 Multiprotocol Label Switching (MPLS) Management Overview Operations and Management (OAM) Requirements for MPLS A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM). 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
RFC3612 RFC4090 RFC4124 RFC4125
RFC4126
RFC4127 RFC4182 RFC4197
RFC4221 RFC4377 RFC4378 RFC4379 RFC4446 RFC4447 RFC4448
Issue 01 (2010-03-01)
9-9
RFC4558 RFC4874 RFC4905 RFC4906 draft-ietf-mpls-lsp-ping-version-09 draft-ietf-ccamp-inter-domain-framew ork-04 draft-minei-diffserv-te-multi-class-02 ITU-T Y.1710 ITU-T Y.1711 ITU-T Y.1720 MSTP IEEE802.1s IEEE802.1ad Multicast RFC1112 RFC2236 RFC2362 RFC3446
Node-ID Based Resource Reservation Protocol (RSVP) Hello Exclude Routes - Extension to RSVP-TE Encapsulation Methods for Transport of Layer 2 Frames Over MPLS Networks Transport of Layer 2 Frames Over MPLS Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures Mechanisms for Inter-AS or Inter-Domain Traffic Engineering Extensions for Differentiated Services-aware Traffic Engineered LSPs 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 Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP) An Overview of Source-Specific Multicast (SSM) Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address 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
RFC3569 RFC3956 RFC3973 RFC4541
9-10
Issue 01 (2010-03-01)
RFC4601 RFC4604
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 A "traceroute" facility for IP Multicast Considerations for Internet Group Management Protocol (IGMP)and Multicast Listener Discovery (MLD) Snooping Switches
draft-fenner-traceroute-ipm-01 draft-ietf-magma-snoop-12
NTP RFC1305 OSPF RFC1131 RFC1242 RFC1245 RFC1246 RFC1247 RFC1248 RFC1252 RFC1253 RFC1583 RFC1587 RFC1765 RFC1850 RFC2178 RFC2328 RFC2329 RFC2370 RFC2740 RFC3101 RFC3137 RFC3623 RFC3630 OSPF specification Benchmarking terminology for network interconnection devices 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) The OSPF NSSA Option OSPF Stub Router Advertisement OSPF Graceful Restart Traffic Engineering Extensions to OSPF Network Time Protocol (Version 3)
Issue 01 (2010-03-01)
9-11
RFC4167 RFC4970 PPP RFC1332 RFC1334 RFC1377 RFC1471
Graceful OSPF Restart Implementation Report Extensions to OSPF for Advertising Optional Router
The PPP Internet Protocol Control Protocol (IPCP) PPP Authentication Protocols The PPP OSI Network Layer Control Protocol (OSINLCP). 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) The PPP Multilink Protocol (MP) The PPP Connection Control Protocol PPP Link Quality Monitoring PPP Challenge Handshake Authentication Protocol (CHAP PPP over AAL5 (PPPoA) IP Header Compression over PPP PPP over SONET/SDH
RFC1473
RFC1570 RFC1661 RFC1990 RFC1915 RFC1989 RFC1994 RFC2364 RFC2509 RFC2615 QoS RFC1144 RFC1349 RFC2309 RFC2386 RFC2474 RFC2475 RFC2597
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 An Architecture for Differentiated Services Assured Forwarding PHB Group
9-12
Issue 01 (2010-03-01)
RFC2598 RFC2697 RFC2698 RFC3086 RFC3246 RFC3247 RFC3260 RFC3290 IEEE802.1p RIP RFC1058 RFC1389 RFC2080 RFC2081 RFC2082 RFC2091 RFC2453 RMON RFC2021 RFC2819 Security RFC1519 RFC2085 RFC2267
An Expedited Forwarding PHB A Single Rate Three Color Marker. A Two Rate Three Color Marker Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification An Expedited Forwarding PHB (Per-Hop Behavior) Supplemental Information for the New Definition of the EF PHB New Terminology and Clarifications for Diffserv An Informal Management Model for Diffserv Routers LAN Layer 2 QoS/CoS Protocol for Traffic Prioritization
Routing Information Protocol (RIP) RIP Version 2 MIB Extension RIPng support RIPng Protocol Applicability Statement RIP-2 MD5 Authentication Triggered Extensions to RIP to Support Demand Circuits RIP Version 2
Remote Network Monitoring Management Information Base Version 2 using SMIv2? Remote Network Monitoring Management Information Base
Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy HMAC-MD5 IP Authentication with Replay Prevention Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing Virtual Router Redundancy Protocol
RFC2338
Issue 01 (2010-03-01)
9-13
RFC2365 RFC2787 RFC2827
Administratively Scoped IP Multicast 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 IANA Considerations for RADIUS (Remote Authentication Dial In User Service) The Generalized TTL Security Mechanism (GTSM) Virtual Router Redundancy Protocol (VRRP)
RFC2865 RFC2866 RFC2867 RFC2868 RFC2869 RFC2903 RFC2904 RFC2906 RFC3575 RFC3682 RFC3768 SNMP RFC1155 RFC1157 RFC1212 RFC1214 RFC1215 RFC1901 RFC1902
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)
RFC1903
9-14
Issue 01 (2010-03-01)
RFC1904
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
RFC1905 RFC1906 RFC1907
RFC2570 RFC2571 RFC2572 RFC2573 RFC2574
RFC2575
RFC2576
RFC2578 RFC2579 RFC2580 RFC3410
RFC3411
RFC3412 RFC3413
Issue 01 (2010-03-01)
9-15
RFC3414
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) 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).
RFC3415
RFC3416 RFC3418 RFC3512 SSHV2 RFC4245 RFC4250 RFC4251 RFC4252 RFC4253 RFC4254 System Management RFC0135 RFC1200 RFC1350 RFC1493 RFC1814 RFC2096 RFC2213 RFC2233 RFC2493
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
Conventions for using an IBM 2741 terminal as a user console for access to network server hosts IAB official protocol standards The TFTP Protocol (Revision 2) Definitions of Managed Objects for Bridges Requirements for IP Version 4 Routers IP Forwarding Table MIB Integrated Services Management Information Base using SMIv2 The Interfaces Group MIB using SMIv2 Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals Entity MIB (Version 2). Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations.
RFC2737 RFC2925
9-16
Issue 01 (2010-03-01)
RFC3592
Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Type Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs). IANA Guidelines for the Registry of Remote Monitoring (RMON) MIB modules Alarm Management Information Base (MIB). -
RFC3636 RFC3737 RFC3877 RFC3954 TCP/IP RFC0768 RFC0791 RFC0792 RFC0793 RFC0813 RFC0950 RFC1034 RFC1035 RFC1071 RFC1122 RFC1141 RFC1219 RFC1256 RFC1323 RFC1533 RFC1534 RFC1542 RFC1624 RFC1878
User Datagram Protocol INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION INTERNET CONTROL MESSAGE PROTOCOL TRANSMISSION CONTROL PROTOCOL Window and Acknowledgement Strategy in TCP/IP Internet Standard Subnetting Procedure Domain Names - Concepts and Facilities Domain Names - Implementation and Specification Computing the Internet Checksum Requirements for Internet Hosts -Communication Layers Incremental Updating of the Internet Checksum On the assignment of subnet numbers. ICMP Router Discovery Messages TCP Extensions for High Performance? DHCP Options and BOOTP Vendor ExtensionsClass-identifier Interoperation Between DHCP and BOOTP? Clarifications and Extensions for the Bootstrap Protocol Computation of the Internet Checksum via Incremental Update Variable Length Subnet Table For IPv4
Issue 01 (2010-03-01)
9-17
RFC2131 RFC2132 RFC2507 RFC2508 RFC2581 RFC2644 RFC2694 RFC3046 RFC3396 TELNET RFC0854 RFC0857 RFC0858 RFC1091 VPN RFC1702 RFC2764 RFC2983 RFC3916 RFC3985 RFC4110 RFC4364 RFC4385 RFC4618 RFC4659
Dynamic Host Configuration Protocol DHCP Options and BOOTP Vendor Extensions IP Header Compression Compressing IP/UDP/RTP Headers for Low-Speed Serial Links TCP Congestion Control 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)
TELNET PROTOCOL SPECIFICATION TELNET ECHO OPTION TELNET SUPPRESS GO AHEAD OPTION Telnet Terminal-Type Option
Generic Routing Encapsulation over IPv4 networks A Framework for IP Based Virtual Private Networks Differentiated Services and Tunnels 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 IP Virtual Private Networks (VPNs) Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN Encapsulation Methods for Transport of PPP/HDLC over MPLS Networks BGP-MPLS VPN Extension for IPv6 VPN
9-18
Issue 01 (2010-03-01)
RFC4664 RFC4665 RFC4684
Framework for Layer 2 Virtual Private Networks (L2VPNs) Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs) Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN) Control Protocol Extensions for the Setup of Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks 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 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 -
RFC4761 RFC4762 RFC5085
RFC5086
RFC5287
draft-ietf-pwe3-hdlc-ppp-encap-mpls09 draft-ietf-pwe3-vccv-10 draft-raggarwa-rsvpte-pw-00 draft-ietf-pwe3-vccv-10 draft-ietf-pwe3-vccv-10 draft-ietf-l2vpn-vpls-bgp-06 draft-ietf-l2vpn-vpls-ldp-02 draft-kompella-l2vpn-l2vpn-00 draft-ietf-pwe3-cell-transport-04 draft-ietf-pwe3-hdlc-ppp-encap-mpls07 draft-ietf-pwe3-vccv-07 draft-ietf-l2vpn-l2-framework-05
Issue 01 (2010-03-01)
9-19
draft-ietf-l2vpn-vpls-bgp-05 draft-ietf-l2vpn-requirements-04 draft-ietf-l2vpn-vpls-ldp-07 draft-ietf-pwe3-congestion-frmwk-01 draft-ietf-pwe3-dynamic-ms-pw-08 draft-ietf-pwe3-ms-pw-arch-04 draft-ietf-pwe3-ms-pw-requirements-0 7 draft-ietf-pwe3-oam-msg-map-07 draft-ietf-pwe3-redundancy-00 draft-ietf-pwe3-redundancy-bit-00 draft-ietf-pwe3-segmented-pw draft-ietf-pwe3-vccv-bfd-02
9.2 Electromagnetic Compatibility Standards

CISPR22 Class B CISPR24 EN55022 Class A EN50024 ETSI EN 300 386 Class A ETSI ETS 300 132-2 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
9.3 Safety Standards

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 IEC GR-1089-CORE
9.4 Environmental Standards

RoHS GR-63 GB/T13543-92 ETS 300 019-2 GB2423-89 IEC 60068-2 GB 4789 ISTA
9.5 Other Standards

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 01 (2010-03-01)
9-21
A Acronyms and Abbreviations
A
A AAA AAL5 AC ACL AF ANSI
Acronyms and Abbreviations
Authentication, Authorization and Accounting ATM Adaptation Layer 5 Alternating Current
Access Control List Assured Forwarding American National Standard Institute
ARP ASBR ASIC ATM AUX
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 Committed Access Rate
Issue 01 (2010-03-01)
A-1
A CBR CE CHAP CoS CPU CR-LDP Constant Bit Rate Customer Edge Challenge Handshake Authentication Protocol Class of Service Center Processing Unit Constrained Route - Label Distribution Protocol
DC DHCP DNS DS
Direct Current Dynamic Host Configuration Protocol Domain Name Server Differentiated Services
E EACL EF EMC Enhanced Access Control List Expedited Forwarding ElectroMagnetic Compatibility
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 Gigabit Ethernet Generic Routing Encapsulation
A-2
Issue 01 (2010-03-01)
A GTS Generic Traffic Shaping
H HA HDLC HTTP High availability High level Data Link Control Hyper Text Transport Protocol
ICMP IDC IEEE IETF IGMP IGP IP IPoA IPTN
Internet Control Message Protocol 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
IPv4 IPv6 IPX IS-IS ISP ITU
IP version 4 IP version 6 Internet Packet Exchange Intermediate System-to-Intermediate System Interim inter-switch Signaling Protocol International Telecommunication Union - Telecommunication Standardization Sector
L L2TP LAN Layer 2 Tunneling Protocol Local Area Network
Issue 01 (2010-03-01)
A-3
A LCD LCP LDP LER LPU LSP LSR M MAC MBGP MD5 MIB MP MPLS MSDP MSTP MTBF MTTR MTU Media Access Control Multiprotocol Border Gateway Protocol Message Digest 5 Management Information Base Multilink PPP Multi-protocol Label Switch Multicast Source Discovery Protocol Multiple Spanning Tree Protocol Mean Time Between Failures Mean Time To Repair Maximum Transmission Unit Liquid Crystal Display Link Control Protocol Label Distribution Protocol Label switching Edge Router Line Processing Unit Label Switched Path Label Switch Router
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
A-4
Issue 01 (2010-03-01)
A PAP PE PFE PIC PIM-DM PIM-SM POP POS PPP PQ PT PVC 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
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
Issue 01 (2010-03-01)
A-5
A 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
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 Unspecified Bit Rate User Datagram Protocol User Network Interface Unshielded Twisted Pair
A-6
Issue 01 (2010-03-01)
A 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 Wide Area Network Weighted Fair Queuing
WRED WRR
Weighted Random Early Detection Weighted Round Robin
Issue 01 (2010-03-01)
A-7

NE40E X1&amp;NE40E X2 Product Description

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

NE40E X1&amp;NE40E X2 Product Description

Încărcat de

Drepturi de autor:

Formate disponibile

HUAWEI NetEngine40E Universal Service Router V600R002C03

HUAWEI TECHNOLOGIES CO., LTD.

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

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine40E Universal Service Router Product Description

About This Document

About This Document

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

About This Document

HUAWEI NetEngine40E Universal Service Router Product Description

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine40E Universal Service Router Product Description

About This Document

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

About This Document

HUAWEI NetEngine40E Universal Service Router Product Description

Updates in Issue 01(2010-03-01)

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine40E Universal Service Router Product Description

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine40E Universal Service Router Product Description 4.2.2 PPP/TDM.............................................................................................................................................4-3

5 Service Features ..........................................................................................................................5-1

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine40E Universal Service Router Product Description

6 Application Scenarios ...............................................................................................................6-1

7 Operation and Maintenance ....................................................................................................7-1

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

7.2 Network Management System ......................................................................................................................7-4

8 Technical Specifications ...........................................................................................................8-1

A Acronyms and Abbreviations............................................................................................... A-1

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine40E Universal Service Router Product Description

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine40E Universal Service Router Product Description

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine40E Universal Service Router Product Description

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine40E Universal Service Router Product Description

1.2 Product Features

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine40E Universal Service Router Product Description

Diverse LPU Types

Powerful Forwarding Capability

Perfect QoS Mechanism

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine40E Universal Service Router Product Description

Excellent Security Design

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine40E Universal Service Router Product Description

Complete IPv4/IPv6 Solutions

Good Compatibility and Scalability

High Reliability and Manageability

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine40E Universal Service Router Product Description

Fault tolerance design

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine40E Universal Service Router Product Description

Item Operation security

Operation and maintenance center

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine40E Universal Service Router Product Description

NE40E X1&NE40E X2 Product Description

NE40E X1&NE40E X2 Product Description