NE40E X1 NE40E X2 Product Description

HUAWEI NetEngine40E Universal Service Router
V600R002C03
Product Description
Issue 01
Date 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: http://www.huawei.com
Email: support@huawei.com
Huawei Proprietary and Confidential

Issue 01 (2010-03-01) i
Copyright © Huawei Technologies Co., Ltd.
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 Version
HUAWEI NetEngine40E Universal V600R002C03

Service Router
Intended Audience
The intended audiences of this document are:
z On-site maintenance engineer
z Commissioning engineer
z System maintenance engineer
Organization
This document consists of nine chapters and is organized as follows.
Chapter Description
1 Introduction This chapter introduces the product positioning and

features of the NE40E.
2 Architecture This chapter describes the physical, logical, and software
architecture of the NE40E.
Issue 01 (2010-03-01) Huawei Proprietary and Confidential iii

About This Document Product Description
Chapter Description
3 Hardware Architecture This chapter describes the chassis, fans, power modules,
and board types of the NE40E.
4 Link Features This chapter describes the link features of the NE40E.
5 Service Features This chapter describes the service features of the NE40E
6 Application Scenarios This chapter describes the networking applications of the
NE40E.
7 Operation and Maintenance This chapter describes the operation and maintenance,
and network management of the NE40E.
8 Technical Specifications This chapter describes the technical specifications of the
NE40E.
9 Compliant Standards This chapter describes the compliant standards of the
NE40E.
A Acronyms and This appendix lists the acronyms and abbreviations
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 Huawei Proprietary and Confidential Issue 01 (2010-03-01)

Product Description About This Document
General Conventions
The general conventions that may be found in this document are defined as follows.
Convention Description
Times New Roman Normal paragraphs are in Times New Roman.

Boldface Names of files, directories, folders, and users are in
boldface. For example, log in as user root.
Italic Book titles are in italics.
Courier New 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.
Boldface The keywords of a command line are in boldface.

Italic Command arguments are in italics.
[] Items (keywords or arguments) in brackets [ ] are optional.
{ x | y | ... } Optional items are grouped in braces and separated by
vertical bars. One item is selected.
[ x | y | ... ] Optional items are grouped in brackets and separated by
vertical bars. One item is selected or no item is selected.
{ x | y | ... }* 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.
[ x | y | ... ]* Optional items are grouped in brackets and separated by
vertical bars. Several items or no item can be selected.
&<1-n> The parameter before the & sign can be repeated 1 to n
times.
# A line starting with the # sign is comments.
GUI Conventions
The GUI conventions that may be found in this document are defined as follows.
Boldface Buttons, menus, parameters, tabs, window, and dialog titles

are in boldface. For example, click OK.
Issue 01 (2010-03-01) Huawei Proprietary and Confidential v

About This Document Product 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 Description
Key Press the key. For example, press Enter and press Tab.
Key 1+Key 2 Press the keys concurrently. For example, pressing
Ctrl+Alt+A means the three keys should be pressed
concurrently.
Key 1, Key 2 Press the keys in turn. For example, pressing Alt, A means
the two keys should be pressed in turn.
Mouse Operation
The mouse operations that may be found in this document are defined as follows.
Action Description
Click Select and release the primary mouse button without

moving the pointer.
Double-click Press the primary mouse button twice continuously and
quickly without moving the pointer.
Drag 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 Huawei Proprietary and Confidential Issue 01 (2010-03-01)

Product Description 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) Huawei Proprietary and Confidential vii

HUAWEI NetEngine40E Universal Service
Router
Contents 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 Huawei Proprietary and Confidential Issue 01 (2010-03-01)

Product Description 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) Huawei Proprietary and Confidential ix

Router
Contents 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
x Huawei Proprietary and Confidential Issue 01 (2010-03-01)

Product Description 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) Huawei Proprietary and Confidential xi

Router
Figures Product Description
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 Huawei Proprietary and Confidential Issue 01 (2010-03-01)

Product Description 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) Huawei Proprietary and Confidential xiii

Product Description 1 Introduction
1 Introduction
About This Chapter

1.1 Positioning
1.2 Product Features
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) Huawei Proprietary and Confidential 1-1

1 Introduction Product Description
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:
z 155 M CPOS interface
z Low-speed E1 interface
z 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:
z 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.
z 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.
z 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.
z Traffic policing: The NE40E-X1 and NE40E-X2 can control the traffic by monitoring all
the traffic or specific traffic on a specified interface.
z 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.
z 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 Huawei Proprietary and Confidential Issue 01 (2010-03-01)

NE40E-X1 and NE40E-X2 provide five levels of scheduling to meet the requirements of
different service combinations.
z The NE40E-X1 and NE40E-X2 support the PQ and WFQ, realizing fair scheduling and
preferentially guaranteeing services of high priorities.
z 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.
z Flow-based scheduling: The NE40E-X1 and NE40E-X2 support DiffServ and Integrated
Service (InterServ), facilitating the implementation of MPLS TE.
z 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:
z Three user authentication modes: local authentication, RADIUS authentication, and
HWTACACS authentication
z Hardware-based packet filtering and attack packet sampling, which guarantees high
performance and high scalability
z 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)
z ACL based on the forwarding plane and control plane
z 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.
z Supports lawful interception and Unicast Reverse Path Forwarding (URPF). URPF
checks the source IP addresses of received packets and then discards illegal packets.
z Supports DHCP snooping and MAC address limit.
z Supports Generalized TTL Security Mechanism (GTSM).
z Supports ARP attack defense.
z Supports attack self suppression.

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.
z Supports IPv6 over IPv4 tunnels.
z 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.
z 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.
z 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.
z 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.
z 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 Description
System Hot-swappable boards, power modules, and fans.

protection
mechanism 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.

Item Description
The key components such as the clocks and management buses work in
backup mode.
Protections The system can automatically restart and recover when
against abnormalities occur.
abnormalities
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 The system provides alarm prompt, alarm indication,
monitoring running status query, and alarm status query.
Voltage and The system provides alarm prompt, alarm indication,
environment running status query, and alarm status query.
temperature
monitoring
Reliability The control channel is separated from the service channel to provide a
Design non-blocking control channel.
The system provides fault detection for the system and boards, indicators,
and the Network Management System (NMS) alarm function.
Reliable Supports online patching.
upgrade
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 Data backup The system supports hot backup of the data between the
tolerance active and standby units. When the active unit fails, the
design 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.

Item Description
Operation The system provides password protection for system operations.

security
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 The system adopts the generic integrated NMS platform developed by
and Huawei.
maintenance
center

Product Description 2 Architecture
2 Architecture
About This Chapter

2.1 Physical Architecture
2.2 Logical Architecture
2.3 Software Architecture
2.4 Data Forwarding Process
2.1 Physical Architecture

The physical architecture of the NE40E and NE40E-X2 are shown in Figure 2-1, including
the following systems:
z Power distribution system
z Functional host system
z Heat dissipation system
z Network management system

2 Architecture Product Description
Figure 2-1 Physical architecture
-48 V -48 V RTN

Power distribution
system
Heat dissipation
Functional host system
system
Monitorbus
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.

Figure 2-2 Structure of the functional host system
Control Bus Control Bus

-48 VA PSU-A GE/Console/
(Power Support Monitor Bus Monitor Bus FAN Bits/USB
Unit)

-48 VB PSU-B MPU GE/Console/
(Power Support Monitor Bus Monitor Bus Bits/USB
(Master)
Unit)
Backplane
Control Bus Control Bus GE/Console/
2*10G MPU
Monitor Bus Monitor Bus (Slave) Bits/USB
NPU
Data Bus

2*10G Monitor Bus Monitor Bus PIC 0-7
NPU GE/FE/E1
Data Bus Data Bus (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:
z Data plane
z Control and management plane
z Monitoring plane
Figure 2-3 shows the logical architecture .

Figure 2-3 Logical architecture
MPU MPU
Monitoring System System

plane monitoring unit monitoring unit
System System
Control and monitoring unit monitoring unit
management
plane
Managemeng PIC
Managemeng unit managemeng
unit unit
Data Forwarding
plane unit
NPUI
Forwarding Data channel
unit
NPUI Pic *N
z 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.
z 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.
z 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.

Figure 2-4 Software architecture
Power Fan
monitoring monitoring
RPS RPS
SNMP
Active Standby
IPC
FSU FSU FSU
EFU EFU EFU
LPU LPU 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).
z 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.
z The FSU implements the functions of the link layer and IP protocol stacks on interfaces.
z The EFU performs hardware-based IPv4/IPv6 forwarding, multicast forwarding, MPLS
forwarding, and statistics.

2.4 Data Forwarding Process

Figure 2-5 Data forwarding process
PIC
Datagram Datagram
Processing on the incoming Processing on the outgoing

interface interface
Downstream traffic
Upstream traffic classification
classification
PFE IPv4 unicast Searching the Packet

IPv4 unicast
IPv4 multicast routing table to encapsulation
IPv4 multicast
MPLS forward packets and forwarding
MPLS
IPv6 in the
IPv6
MAC downstream
Congestion Queue
QoS in the management scheduling QoS in the
upstream Queue Congestion downstream
scheduling management
TM Multicast replication
Packet fragmentation Packet reassembly
Micro cell Micro cell

SFU
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

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.

Product Description 3 Hardware Architecture
3 Hardware Architecture
About This Chapter

3.1 NE40E-X2
3.2 NE40E-X1
3.3 Subcard
3.1 NE40E-X2
3.1.1 Chassis
3.1.2 Heat Dissipation System
3.1.3 Power Supply System
3.1.4 Introduction to the Board Cage
3.1.5 MPU
3.1.6 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.

3 Hardware Architecture Product Description
Figure 3-1 Appearance and components of the NE40E-X2

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 Value
Weight 1.7 kg
Maximum 180 W
power
consumption

Parameter Value
Maximum 477.2 Pa
wind
pressure
Maximum 64.4 CFM
air volume
Noise 64.3 dB

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:
z Protection against overcurrent of output power
z Protection against overvoltage of output power
z Protection against under-voltage of input power
z Protection against over-temperature
z Protection against short circuit
z Alarm function
Table 3-2 Technical parameters of the DC power supply module on the NE40E-X2
Item Parameter
Dimensions (W x D x H) 196 mm x 184 mm x 19.8 mm

Weight 1 kg
Input voltage range –72 V DC to –38 V DC
Maximum input current 24.5 A
Maximum output power 905 W
Current of the customer's air circuit breaker 32 A
At present, the NE40E-X2 supports the DC power supply only.


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 14 PWR
11 PIC 12 PIC
9 PIC 10 PIC
8 NPU
15
FAN
7 NPU
5 PIC 6 PIC
3 PIC 4 PIC
1 MPU 2 MPU
Table 3-3 Description of the slots on the NE40E-X2
Slot Number Quanti Remarks

ty
Slots 3 to 6, slots 8 Indicates the slots for subcards. Slots 5, 6, 9, and 10 can be
9 to 12 equipped with both high-speed and low-speed subcards.
Slots 3, 4, 11, and 12 support only low-speed subcards.
Slots 7 and 8 2 Indicates the slots for the NPUs.
Slots 1 and 2 2 Indicates the slots for the MPUs. Two MPUs work in 1:1
backup mode.
Slots 13 and 14 2 Indicates the slots for DC power supply modules. Two DC
power supply modules work in 1+1 backup mode.
Slot 15 1 Indicates the slot for the fan module.
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

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.
z 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.
z 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.
z 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 Interface Type Description

Name
Ethernet RJ45 One Ethernet interface, for system

interface maintenance
(10M/100M/10
00M Base-TX
auto-sensing)


Name
Console RJ45 One console interface, used to connect to

interface the console for on-site configurations
AUX interface RJ45 One AUX interface, used to connect to a
Modem for remote maintenance through a
dial-up connection
USB interface USB 2.0 One hot swappable USB2.0 interface, for
software upgrade or temporary data access
CLK RJ45 Two RJ45 interfaces, for receiving and
sending 1588v2 time signals
RS485 RJ45 -
interface
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:
z 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.
z 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 Description Remarks
Forwarding capability Bi-directional 20 Gbit/s forwarding -

capability
Interface Two 10G Ethernet XFP optical -
interfaces, supporting WAN and
LAN modes

3.2 NE40E-X1
3.2.1 Chassis
3.2.5 MPU
3.2.6 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

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

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 Value
Weight 1.1 kg
Maximum 120 W
power
consumption
Maximum 477.2 Pa
wind
pressure
Maximum 64.4 CFM
air volume
Noise 64.3 dB

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:
z Protection against overcurrent of output power
z Protection against overvoltage of output power
z Protection against under-voltage of input power
z Protection against over-temperature
z Protection against short circuit
z Alarm function
Table 3-7 Technical parameters of the DC power supply module on the NE40E-X1
Item Parameter
Dimensions (W x D x H) 196 mm x 184 mm x 19.8 mm

Weight 1 kg
Input voltage range –72 V DC to –38 V DC
Maximum input current 24.5 A
Maximum output power 905 W
Current of the customer's air circuit breaker 32 A

At present, the NE40E-X1 supports the DC power supply only.

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 9 PWR
6 MPU 7 MPU
10 4 PIC 5 PIC
FAN 2 PIC 3 PIC
1 NPU
Table 3-8 Description of the slots on the NE40E-X1
Slot Number Quanti Remarks

ty
Slot 1 2 Indicates the slot for the NPU.

Slots 2, 3, 4, and 5 4 Indicates the slots for subcards. These slots can be
equipped with both high-speed subcards and low-speed
subcards.
Slots 6 and 7 2 Indicates the slots for the MPUs. Two MPUs work in 1:1
backup mode.
Slots 8 and 9 2 Indicates the slots for DC power supply modules. Two DC
power supply modules work in 1+1 backup mode.
Slot 10 1 Indicates the slot for the fan module.
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

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.
z 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.
z 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.
z 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

Name
Ethernet RJ45 One Ethernet interface, for system

interface maintenance
(10M/100M/10
00M Base-TX
auto-sensing)


Name
Console RJ45 One console interface, used to connect to

interface the console for on-site configurations
AUX interface RJ45 One AUX interface, used to connect to a
Modem for remote maintenance through a
dial-up connection
USB interface USB 2.0 One hot swappable USB2.0 interface, for
software upgrade or temporary data access
CLK RJ45 Two RJ45 interfaces, for receiving and
sending 1588v2 time signals
RS485 RJ45 -
interface
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:
z 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.
z 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 Description Remarks
Forwarding capability Bi-directional 20 Gbit/s forwarding -

capability
Interface Two 10G Ethernet XFP optical -
interfaces, supporting WAN and
LAN modes

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 Description Remarks
8-port Supports synchronization Subcards of this type can be

100/1000Base-X-SFP Ethernet feature and multiple inserted in the slots 5, 6, 9, and
Flexible Plug-in Card types of optical modules, and 10 on the NE40E-X2, and the
(FPIC) (1588v2) complies with the 1588v2 slots 2 and 5 on the NE40E-X1.
standard.
z Supports the GE optical
module to provide GE optical
interfaces.
z Supports the FE optical
module to provide FE optical
interfaces.
z 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.)
z Supports the mixed use of the
preceding modules.
8-port Supports the synchronization Subcards of this type can be
100/1000Base-X-SFP Ethernet feature and multiple inserted in the slots 5, 6, 9, and
FPIC types of optical modules. 10 on the NE40E-X2, and the
z Supports the GE optical slots 2 and 5 on the NE40E-X1.
module to provide GE optical
interfaces.
z Supports the FE optical
module to provide FE optical
interfaces.
z Supports the SFP electrical
module to provide the
features of 100 M/1000 M
auto-sensing electrical
interfaces.
z Supports the mixed use of the
preceding modules.

Interface Name Description Remarks
Auxiliary interface Supports on-site ambient The subcards installed in the

and 4-line FE FPIC monitoring, including the slots 5, 6, 9, and 10 on the
monitoring of burglarproof NE40E-X2 support both 4-line
switches and smoke sensors. 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 Subcards of this type can be
FPIC (electrical inserted in the slots 3, 4, 5, 6, 9,
interface) 10, 11, and 12 on the
NE40E-X2, and in the slots 2
and 5 on the NE40E-X1.
8-port 100Base-X Subcards of this type can be
SFP FPIC (optical inserted in the slots 3, 4, 5, 6, 9,
interface) 10, 11, and 12 on the
1-port channelized Supports hot swapping, the Subcards of this type can be
STM-1 FPIC synchronization Ethernet inserted in the slots 3, 4, 5, 6, 9,
feature, and three protocols: 10, 11, and 12 on the
Circuit Emulation Service NE40E-X2, and in the slots 2
(CES), Inverse Multiplexing for and 5 on the NE40E-X1.
ATM (IMA), and Multi-link
Point-to-Point Protocol
(ML-PPP).
16-port E1 FPIC (75 Supports hot swapping. Subcards of this type can be
ohm) inserted in the slots 3, 4, 5, 6, 9,
10, 11, and 12 on the
16-port E1 FPIC (120 Supports hot swapping. Subcards of this type can be
ohm) inserted in the slots 3, 4, 5, 6, 9,
10, 11, and 12 on the

Product Description 4 Link Features
4 Link Features
About This Chapter

4.1 Ethernet Link Features
4.2 CPOS Link Features
4.3 TDM Link Feature
4.4 E1 Link Features
4.5 ATM E1 IMA
4.6 E-Trunk
4.7 APS
4.1 Ethernet Link Features

4.1.1 Basic Features
4.1.2 Eth-Trunk
4.1.1 Basic Features

The Ethernet link provided by the NE40E has the following features:
z VLAN trunk
z VLANIF interfaces
z VLAN aggregation
z Inter-VLAN interface isolation
z Ethernet sub-interfaces
z VLAN aggregation sub-interfaces
z 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 Product Description
Eth-Trunks of the NE40E function as follows:

z Supports the bundling of up to 16 physical Ethernet interfaces. Eth-Trunks function the
same as normal Ethernet interfaces.
z Supports the bundling of interfaces with different rates.
z 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:
z VLANIF interfaces
z Inter-VLAN interface isolation
z VLAN aggregation
z VLAN trunk
z VLAN mapping
z QinQ and VLAN stacking
z 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:
z IPv4/IPv6 forwarding
z MPLS forwarding
z Multicast forwarding
z L3VPN
z L2VPN
z 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

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 Channelization
4.2.2 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:
z PPP
z TDM
PPP on CPOS interfaces supports the following:
z LCP
z IPCP
z MPLSCP
z MP
z PAP
z 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

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:

z 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.
z In this mode, the equipment detects the frame structure, framing scheme, and timeslot
information in the TDM circuit.
z 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.
z 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.
z 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:
z PPP
z ATM supported on CE1/CT1 interfaces
z TDM supported on CE1/CT1 interfaces

PPP on serial interfaces supports the following:

z LCP
z IPCP
z MPLSCP
z MP
z PAP
z 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 IMA Group

Physical Link #0
PHY PHY
Physical Link #1
PHY PHY
Single ATM Cell Stream Original ATM Cell

from ATM Layer Physical Link #2 Stream to ATM Layer
PHY PHY
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.

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 E-Trunk Provider

(Sub-group) Network
CPE
Trunk 1
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.
z 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.

z 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:
z 1+1 unidirectional mode and 1:1 bidirectional mode.
z Manual switching of APS groups.
z Forcible switching of APS groups.
z Locking of APS groups.
z APS implemented on interfaces.
z APS implemented on the same SIC or inter-SIC APS.
z E-APS.
z Adding the working and protection interfaces of an APS group to a trunk and configuring
services on the trunk.

Product Description 5 Service Features
5 Service Features
About This Chapter

5.1 Ethernet Features
5.2 IP Features
5.3 Routing Protocols
5.4 MPLS
5.5 VPN Features
5.6 IPTN Features
5.7 QoS Features
5.8 Load Balancing
5.9 Traffic Statistics
5.10 Security Features
5.11 Network Reliability
5.1 Ethernet Features

5.1.1 Switched Ethernet Features
5.1.2 Routed Ethernet Features
5.1.3 QinQ
5.1.4 RRPP Link Features
5.1.5 RSTP/MSTP
5.1.6 BPDU Tunnel

5 Service Features Product Description
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.

Ethernet Sub-interfaces
A common Ethernet sub-interface, which can belong to a VLAN only, has the following
functions:
z Terminating enterprise services
z Supporting complete routing protocols
z 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:
z DHCP relay
z DHCP binding
z URPF
z 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:
z Packets from different users in the same VLAN are not transmitted transparently.
z Private networks are separated from the public network.
z 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.

Figure 5-1 Networking diagram of applying interface-based QinQ
VLAN100
ME60
100 100 300
ISP
Network
200 200 300
VLAN200
Interface-based QinQ provides the following functions:

z Access to the VPLS to transparently transmit private VLAN packets
z 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:
z VLANs 1000-1999: broadband access services
z VLANs 2000-2999: VoIP services
z VLANs 3000-3999: IPTV services

Figure 5-2 Networking diagram of applying VLAN-based QinQ
iManager N2000
IP backbone/MAN VOIP access

VLAN200 VLAN3xxx
Broadband access
IPTV access
VLAN100 VLAN1xxx
VLAN300 VLAN2xxx
Service gateway
VLAN2001 VLAN2002
VLAN 3001 VLAN 3002
VLAN 1001 LAN Switch VLAN 1002
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:
z 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.
z 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.
z 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

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:
z In interface-based QinQ mode, user packets from the same user side are added with the
same outer VLAN tag on the PE.
z 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:
z Access to the VPLS through the sub-interfaces for VLAN stacking
z 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:
z IP forwarding
z L3VPN/PWE3/VLL/VPLS access
z Proxy ARP
z Unicast routing protocols
z VRRP
z DHCP server and DHCP relay

Sub-interfaces for QinQ VLAN tag termination terminate double VLAN tags in the following
manners:
z Exact termination
Double VLAN tags of specified VLAN IDs are terminated.
z 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
1 00
0x9
0x9100 Switch A
IP/MPLS
Core 0x 81
Router A ME60 00
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.

Figure 5-4 Networking diagram of applying multicast QinQ
Internet
/Intranet PE1
Multicast source 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.

Figure 5-5 Network diagram of the VLAN swapping feature based on QinQ
UPE PE-AGG
Metro
Ethernet
VLAN Swap Network
Service-POP
Service
VLAN/Customer Customet
VLAN 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.

Figure 5-6 Application of tangent RRPP rings in the MAN
RRPP Domain
Master
Node ME60B
Edge Node
SwitchA RRPP Sub-Ring 1 Transit Node
Router A
RRPP Major-Ring
ME60C Master Node

Master Assistant Node
Transit Node
Node
RRPP Sub-Ring 2
SwitchB
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

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:
z Each branch of the same user network can receive its own BPDUs.
z The BPDUs of a user network cannot be processed by the CPU of devices on the ISP
network.
z 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:
z Interface-based BPDUs

z VLAN-based BPDUs
z QinQ-based BPDUs
5.2 IP Features
5.2.1 IPv4/IPv6 Dual Stack
5.2.2 IPv4 Features
5.2.3 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:
z TCP/IP protocol suite, including ICMP, IP, TCP, UDP, socket (TCP/UDP/Raw IP), and
ARP
z Static DNS and DNS server
z FTP server/client and TFTP client
z DHCP relay agent and DHCP server
z 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.
z IP policy-based routing to specify the next hop based on the attribute of packets without
searching the routing table

5.2.3 IPv6 Features

The NE40E supports the following IPv6 features:
z IPv6 neighbor discovery (ND)
z Path MTU (PMTU) discovery
z TCP6, ping IPv6, tracert IPv6, and socket IPv6
z Static IPv6 DNS and specified IPv6 DNS server
z TFTP IPv6 client
z IPv6 policy-based routing
z 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 Fast Convergence of BGP Routes
5.3.2 Unicast Routing
5.3.3 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:
z 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.
z 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:
z IPv4 routing protocols: RIP, OSPF, IS-IS, and BGPv4
z IPv6 routing protocols: RIPng, OSPFv3, IS-ISv6, and BGP4+
z Static routes to simplify network configuration and improve network performance
z Large-capacity routing table to support MAN operation effectively

z Routing policy to select the optimal route

z 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:
z 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).
z 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.
z PIM-SSM: If the multicast source is specified, a host can join the multicast source
directly, without registering with the Rendezvous Point (RP).
z 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.
z IPv6 multicast routing protocols: PIM-IPv6-DM, PIM-IPv6-SM, and PIM-IPv6-SSM.
z 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.
z Multicast static routes.
z Configuration of multicast protocols on physical interfaces such as Ethernet, and
IP-Trunk and Eth-Trunk interfaces.
z When receiving, importing, and advertising multicast routes or forwarding IP packets,
the multicast routing module can filter routes or packets based on routing policies.
z Multicast VPN: The NE40E adopts the Multicast Domain (MD) scheme to implement
centralized processing.
z Addition and deletion of dummy entries.
z 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.
z 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,

and the DSLAMs do not need to be upgraded in large scale. This cuts the costs of initial
investment in IPTV services.
z 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.
z 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.
z 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:
z Discards the packets directly after receiving them.
z 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.

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 Basic Functions
5.4.2 MPLS TE
5.4.3 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).

The NE40E supports the following MPLS functions:

z Basic MPLS functions, forwarding, and LDP
LDP distributes labels, sets up LSPs, and transfers parameters used for setting up LSPs.
z 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
z MPLS ping and tracert
MPLS Echo Request packets and MPLS Echo Reply packets are transmitted to detect the
availability of an LSP.
z Traffic statistics for LSPs
z LSP loop detection mechanism
z 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
z Static configuration of LSPs and label forwarding based on traffic classification
z MPLS trap
The NE40E can serve as a Label Edge Router (LER) or an LSR.
z 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.
z 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:
z Processing of static LSPs
MPLS TE creates and deletes static LSPs, which require bandwidth but are manually
configured.
z Processing of Constrained Route-Label Switched Path (CR-LSP)
MPLS TE processes various types of CR-LSPs.
The processing of static LSPs is easier. CR-LSPs are classified into the types described in the
following sections.

RSVP-TE
RSVP is designed for the Integrated Service (IntServ) model and used on each node of a path
for resource reservation.
To put it simply, RSVP has the following characteristics:
z Unidirectional.
z Receiver-oriented: The receiver initiates a request for resource reservation and maintains
the resource reservation information.
z 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:
z IGP shortcut: The LSP is not advertised to the neighboring router. So, other routers
cannot use this LSP.
z 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.

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:
z 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.
z 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 10
R3
R1 R2 R5 R6
20 10
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:
z Route between physical interfaces connecting R2 and R3
z Route between TE tunnel interfaces connecting R2 and R5

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:
z Detects the LSP connectivity.
z Measures the network utility and performance.
z 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:
z 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
CV
FD /F
FD
/F
CV
Ingress Egress
LSR LSR
I
BD
I BD
z OAM auto protocol function.

z Protection switching: 1:1, 1+1, sharing protection, and packet-level protection are
supported.
5.5 VPN Features

5.5.1 Tunnel Policy
5.5.2 VPN Tunnel
5.5.3 MPLS L2VPN
5.5.4 BGP/MPLS L3VPN

5.5.5 L2VPN Accessing L3VPN

5.5.6 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:
z 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.
z 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:
z 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.
z 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.

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,
VPN1 site1 PE
Eth/VLAN, and Q-in-Q
VPN2 site2 PE
Support interworking
MPLS network
PE VPN1 site3
VPN1 site2
PE-ASBR
VPN2 site2
PE
Support inter-AS
solutions:
VRF-to-VRF
MP-Multihop EBGP
PE-ASBR
Support MPLS VPN over GRE

and MPLS VPN over TE tunnel
Provide the VPN manager

to manage VPNs among
VPN3 site1 VPN3 site2 devices of different vendors
z 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.
z 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.

z 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.
z 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.
z 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 a VLL connection is established, the IP packets are processed as follows:
− 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.
z 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

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 VS2 VLAN2

PE PE
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:
z QinQ VPLS

QinQ is a tunnel protocol based on IEEE 802.1Q. In QinQ, the VLAN tag of private
networks is encapsulated in the VLAN tag of public networks. The packets carry double
tags when being transmitted across the ISP's backbone network. This saves VC resources
and provides users with an L2VPN tunnel that is easy to implement.
z 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
SPE
AC SPE PW
PW PW
UPE PW
AC SPE
CE
z 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.
z IGMP snooping

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.
z 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.
z 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.
z 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.
z 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
z 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.

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.

Figure 5-13 BGP/MPLS L3VPN

Support access to MPLS VPN
VPN2 site3 through PPP, HDLC, ATM, Eth/
UPE VLAN, and remote dial-in/tunnel
VPN1 site1 access
MPLS Support routing protocols between
VPN2 site2 network PEs and CEs, such as static
PE
routing, BGP, RIP, OSPF, and
MP-BGP ISIS
MPLS SPE PE VPN1 site3
network
VPN1 site2
PE-ASBR
VPN2 site2 UPE
Hierarchical
PE Support inter-AS
solutions:
Support HoVPN to
VRF-to-VRF
extend the VPN
MP-EBGP
MP-Multihop EBGP
PE-ASBR
Support MPLS VPN over GRE

and MPLS VPN over TE tunnel
Provide the VPN manager

to manage VPNs among
devices of different
VPN3 site1 VPN3 site2 vendors
z As a PE router, it supports access of CE routers through interfaces such as Ethernet and

VLAN, Remote Access and Tunnel interfaces.
z It supports static routes and dynamic routing protocols such as BGP, RIP, OSPF, and
IS-IS between CE routers and PE routers.
z 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.

Inter-AS VPN
The NE40E supports the following inter-AS VPN solutions explained in RFC 2547bis:
z VPN instance to VPN instance: ASBRs manage VPN routes in between through
sub-interfaces, which is also called Inter-Provider Backbones Option A.
z 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.
z 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.

Figure 5-15 Networking diagram of applying VPN A multicast
VPNA
site1
CE1
PE1_vpnA-instance
PE3_vpnA-instance MD A
CE2
CE3
VPN A PE2_vpnA-instance VPN A
site3 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 VPN B
site4 site5
CE5
MD B
PE2_vpnB-instance
CE6
VPN B
site6
Take VPN A instances as an example. Multicast VPN can be summarized as follows:

z The multicast source S1 belongs to VPN A. S1 sends multicast data to G, a multicast
group.

z Among all possible data receivers, only members of VPN A can receive multicast data
from S1.
z Multicast data is multicast at various sites and on the public network.
To implement multicast VPN, the following network conditions should be met:
z Each site that supports multicast based on VPN instance
z A public network that supports multicast based on public instances
z A PE device that supports the following multi-instance multicast:
z Connecting sites through the VPN instance to support multicast based on VPN instances
z Connecting the public network by using public network instances and supporting
multicast based on public network instances
z 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.

Figure 5-17 Networking diagram of the IPv6 VPN over the IPv4 public network
IPv6
VPN site2
IPv4 VPN backbone CE

P PE CE
PE IPv6
CE VPN site1
P
IPv6
VPN site1
PE
CE
CE
IPv6 IPv6
VPN site2 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:
z Intranet VPN
z Extranet VPN
z Hub&Spoke
z Inter-AS or multi-AS backbones VPN
z Carriers' carrier
HoVPN
In BGP/MPLS VPN solutions, the key device, PE router, provides the following functions:
z Provides access functions for users. To achieve this, a PE router needs a great number of
interfaces.
z 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

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 PE VPN2 site

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:

z 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.
z 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.

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:
z An HoPE can act as a UPE, and compose a new HoPE with an SPE.
z 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:
z Ensures that the data stream of the multi-role host reaches the destination VPN network.
z 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.

Figure 5-19 Implementation of a multi-role host
VPN1
PC
Static-Route CE2
PE2
Backbone
VPN1
CE1 PE1
Policy-Based PE3
Routing 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.
z 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.
z 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.
z The UPE terminates and accesses the L2VPN (VLL and VPLS).
z The NPE terminates and accesses the L3VPN.

Figure 5-20 Traditional access network
The UPE terminates The NPE accesses

the L2VPN and the L3VPN and sets
accesses the L3VPN The UPE and the up the L3VPN tunnel
DSLAM NPE run as the CE DSLAM
for each other
Users access the UPE UPE NPE NPE UPE UPE

L2VPN through ACs
MPLS L2VPN MPLS L3VPN MPLS L2VPN
User Switch
UPE UPE NPE NPE UPE UPE

The UPE accesses the
L2VPN and sets up the User Switch
L2VPN tunnel AC for user access
Users access the L3VPN through the L2VPN
L2VPN tunnel
L3VPN tunnel
MPLS is widely applied on the access network of the ISP because it features high reliability
and security and sound IP-based 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.

Figure 5-21 L2VPN accessing the L3VPN
The UNPE terminates the L2VPN,

accesses the L3VPN, and sets up
the L2VPN and L3VPN tunnels
DSLAM DSLAM
UPE
Users access the UPE UNPE UNPE

L2VPN through the AC
MPLS L3VPN
L2VPN L2VPN
User Switch User Switch
UPE UNPE UNPE UPE
The UPE accesses the

L2VPN and sets up
the L2VPN tunnel AC for user access
Users access the L3VPN through the L2VPN
L2VPN tunnel
L3VPN tunnel
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:
z Total bandwidth used by the user to access the MPLS VPN
z 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.
z The bandwidth for the user traffic to a specified peer PE router is guaranteed.
z 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.

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:
z Sets QoS parameters for BGP routes based on the attributes of BGP routes.
z Classifies traffic by matching QoS parameters and sets the QoS policy for the classified
traffic.
z 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:
z 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.
z MPLS HQoS performs differentiated queue scheduling according to the MPLS EXP
field on the P router.
z 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.
z 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.
z 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.

Figure 5-22 L2VPN/L3VPN with MPLS TE
PE2 VPNA
Backbone
site 3
network
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.

Figure 5-23 L2VPN/L3VPN with MPLS DS-TE
Backbone
network VPNA
site 3
PE2
PE1
VPNA
site 1 PE3
VPNA
site 2
VPNA carries three types of services,
ensuring the QoS for each service in
the same VPN
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.

Figure 5-24 VPN-based QoS on the network side in an L2VPN/L3VPN
flow1
flow2
Scheduler
classfier
flow3
flow4 port
flow5
flow6
flow7
flow8
CE-2
Interface
M
VPN-A:30M
A : 20
Interface -based
VPN-A
VPN-A -based PE-2
VSI-
CE-1 PE-1 VSI-A
VSI-A CE-4
P-2
CE-5 CE-6
PE-3
VPN-A VPN-A
P-3
CE-7
VSI-A
CE-8
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.

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:
z Location of the user, namely, CircuitId in the DHCP Option 82 field
z VPN to which the user belongs
z IP address of the user
z MAC address of the user
In addition, the NE40E provides the following functions:
z Supports the three-level limit to the number of users.
z Provides the detection of online users and the processing of the user getting offline.
z Checks the validity of IPTN users.
z 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:
z Traffic classification
z Traffic policing
z Traffic shaping
z Congestion management
z 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,

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 DiffServ Model
5.7.2 Traffic Classification
5.7.3 Traffic Policing
5.7.4 Queue Scheduling
5.7.5 Congestion Management
5.7.6 Traffic Shaping
5.7.7 HQoS
5.7.8 QPPB
5.7.9 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:
z Classifies the traffic based on certain rules.
z Associates the traffic of the same type with certain actions.
z 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:
z No QoS needs to be ensured.
z No traffic classification is carried out.
z 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.

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:
z Physical interfaces and sub-interfaces
z 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:
z 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
z 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:
z Physical interfaces
z 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.

Figure 5-26 Flowchart of traffic policing with CAR
...
Filling the bucket
Tokens
with tokens at a
specified rate
Classifying
Incoming packets Outgoing packets
Passed
Token bucket
Dropped
z 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.
z 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.
z 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.

Figure 5-27 Networking diagram of traffic congestion
Frame Relay ME602 PC2
serial 1
2M Ethernet
PC1 serial 1 10M
LAN 2
ME601
Ethernet Server2
10M
LAN 1
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:
z First In First Out (FIFO) queuing
z Priority Queuing (PQ)
z Custom Queuing (CQ)
z Weighted Fair Queuing (WFQ)
z Class-Based WFQ (CBWFQ)
z 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

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:
z Five levels of scheduling is provided for services.
z Configures parameters such as the maximum queue length, WRED, low delay, SP/WRR,
CBS, PBS, and statistics.
z The system supports the configuration of parameters such as the CIR, PIR, number of
queues, and scheduling algorithms between queues for each user.
z Provides the traffic statistics function. The user can view the bandwidth usage of services
and properly distribute the bandwidth by analyzing the traffic.
z 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:
z Sets QoS parameters for BGP routes, such as the IP precedence and traffic behavior,
based on the attributes of the routes.
z Classifies traffic by matching QoS parameters and sets the QoS policy for the classified
traffic.
z 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:
z ACL
z AS path list of routing information
z Community attribute list of routing information
z Route cost of routing information

z Address prefix list
Figure 5-28 Networking diagram of applying QPPB
Configure a
QoS policy Advertise routing
information
AS200
AS100
Packets filtered by
the QoS policy
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:
z Ignore the 802.1p value in the inner VLAN tag and set a new 802.1p value in the outer
VLAN tag.
z Automatically set the 802.1p value in the inner VLAN tag as the 802.1p value in the
outer VLAN tag.
z 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:
z Setting a value (Pipe mode).
z Using the 802.1p value in the inner VLAN tag (Uniform mode).
z Mapping the 802.1p priority in the inner VLAN tag to a value in the outer VLAN tag.
Multiple values in multiple inner VLAN tags can be mapped to the same value in the
outer VLAN tag, but a value in an inner VLAN tag cannot be mapped to values in
multiple outer VLAN tags.

Figure 5-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 Equal-Cost Load Balancing
5.8.2 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:
z 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.
z 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.
z 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

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:
z Helps carriers to analyze the traffic model of the network.
z Provides reference data for carriers to deploy and maintain DiffServ TE.
z 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 CAR Traffic Statistics
5.9.4 HQoS Traffic Statistics
5.9.5 Interface-based Traffic Statistics
5.9.6 VPN Traffic Statistics
5.9.7 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.

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.
z In traffic classification, the system can collect statistics on the traffic that matches rules
and fails to match rules.

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,
Perform the action TTL check
In traffic policing, the system supports the collection of statistics on the following traffic:
z Total traffic that matches the CAR rule
z Traffic that is permitted or discarded by the CAR rule
Figure 5-32 CAR traffic statistics
Packets Statistics
Allow the packets

Tokens in bucket C marked green to pass
Bucket C
are enough through
Tokens in
bucket C are
not enough
Process
Statistics packets
Re-mark the packets
according
marked yellow
to the color
marked
Bucket E Tokens in bucket E are
enough
Tokens in
bucket E are Statistics
not enough Discard the packets
marked red
Tokens in bucket E are not

enough
z The system supports interface-based traffic statistics.

z 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:
z Statistics on the number of forwarded packets, bytes, and discarded packets of the user
queues of eight priority levels
z Statistics on the number of forwarded packets, bytes, and discarded packets of the user
group queues
z 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:
z Users that access the network through interfaces including logical interfaces
z Multi-role hosts
z Users that access the network through the VPLS/VLL
z 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:
z Advanced security system structure
z Abundant security protocols
z Strict service access control
The following section describes the security features that the NE40E supports.
5.10.1 Security Authentication

5.10.2 RPF/URPF
5.10.3 MAC Limit
5.10.4 Unknown Traffic Suppression
5.10.5 DHCP Snooping
5.10.6 Local Defense attack
5.10.7 GTSM
5.10.8 ARP Attack Defense
5.10.9 Mirroring
5.10.10 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

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:
z Limit to the number of MAC addresses that can be learned
z Limit to the speed of MAC address learning
z Limit to interface-based MAC address learning
z Limit to PW-based MAC address learning
z Limit to MAC address learning based on the combination of the VLAN and port
z Limit to MAC address learning based on the combination of the port and VSI
z 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:
z Deletion of MAC address entries based on the combination of the port and VSI
z Deletion of MAC address entries based on the combination of the port and VLAN
z Deletion of MAC address entries based on the trunk interface
z 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:
z Manages users' traffic.
z 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.

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 Snooping Working Mode
DHCP exhaustion attack MAC address limit

Bogus DHCP server attack Trusted/Untrusted
Middleman attack and IP/MAC spoofing DHCP snooping binding table
attack
DoS attack by changing the value of the Check on the CHADDR field in DHCP
CHADDR 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

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:
z Uniform configuration of CAR parameters for different LPUs
z Uniform user interface for configuration
z 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.
z When the packet length is smaller than the preset minimum packet length, the system
calculates the sending rate with the preset minimum length.
z 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.

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:
z 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:
z IP packets with null load.
z Null IGMP packets.
z TCPSYN packets whose source and destination IP addresses are the same in LAND
attacks.
z ICMP Echo Request packets whose destination addresses are broadcast addresses or
subnet broadcast addresses in Smurf attacks.
z 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.
z 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.
z Attacks of a huge number of fragments or attacks of the packets that have a large offset
value.
z Repetitive fragmented packets.
z Tear Drop, syndrop, nesta, fawx, bonk, NewTear, Rose, Ping of death, and Jolt attacks
.
z TCP SYN: The system can identify TCP SYN packet flooding and implement CAR on
LPUs.
z 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.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:
z BGP GTSM
z 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.
z 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.
z 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.

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.
z 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.
z 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:
z 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
z Gratuitous ARP packets
z 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.
z 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.
z 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

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:
z Port mirroring: The packets received and sent by a mirroring port are completely copied
to a specific observing port.
z 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:
z Upstream mirroring: All packets or the packets that match specific rules received by a
mirroring port are copied to a specific observing port.
z 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
Port A Port B
Network 1 Network 2
Incoming Outgoing
packets PortC packets
Mirroring
packets
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.

When local mirroring is implemented, inter-LPU mirroring is supported.
Remote Mirroring
Compared with local mirroring, remote mirroring features the following:
z Network maintenance engineers can analyze mirroring packets from remote devices
rather than being on site.
z 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
Packet analysis
IP/MPLS backbone network
equipment
Customer1
ME60A ME60B
ME60D
Customer2
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.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:
z Contents of Communication (CC): indicates the contents of the communication such as
emails and VoIP packets.
z 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 L1
Interception center 1
X1,X2
HI2 Internet
Interception center 2
…… X1,X3
HI3
LIG ME60
Interception center N
Lawful interception involves the following roles:

z 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.
z Interception management center

The interception management center is the agent of the interception centers. The
interception management center receives the interception request from the interception
center, transforms the information in the request to the location and service identifier,
and then delivers the configuration of interception to the network devices of the carrier.
z 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.
z 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.
z 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.

Figure 5-36 Reliability technologies
Interface Link Routing

Backup NSF BFD FRR
backup reliability optimization
Device reliability 99.999% Network reliability
Ative/standby Eth Trunk Customized Grace Fast Fast route IP FRR

MPUs IP Trunk alarm damping Restart detectionconvergence TE FRR
Multiple SFUs Inter-board Ethernet OAM of link ECMP LDP FRR
port binding NSR VLL FRR
Active/standby fault
power modules ISSU VPN FRR
5.11.1 Backup of Key Modules

5.11.2 High Reliability of the LPU
5.11.3 Transmission Alarm Customization and Suppression
5.11.4 VRRP
5.11.5 GR
5.11.6 BFD
5.11.7 Auto FRR
5.11.8 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.

5.11.2 High Reliability of the LPU

The NE40E supports the backup of protocols on key service interfaces of the same type.
z 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.
z The Eth-Trunk and IP-Trunk support backup between member interfaces within or
outside a group.
z 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:
z Customizes alarms. This specifies the alarms that can cause the status change of
interfaces.
z 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.

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 Master
RouterA
PC
10.100.10.3/24
Backup Internet
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
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.

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:
z The system is configured with a large number of VRRP groups.
z 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.
z 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.
z The routers are enabled with the firewall, NAT gateway, or policy server.
z 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.

Figure 5-38 E-VRRP networking
G9 Bearer
Network
ME60 ME60
MSoft UMG HLR
Singaling interface Media 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.

Figure 5-39 Networking diagram of VRRP for IPv6
Virtual IP Address:
ME60A
2002::1
2002::2 Master
HostA
ME60B
2002::3 Backup
HostB Network
ME60C
Backup
2002::4
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:
z Simple and easy to implement. You only need to modify some protocols rather than
changing the current software.
z It does not need to back up the protocol status.
z 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.
z During the switchover, there is little probability of service interruption.
z The network converges rapidly in normal situations.
The NE40E supports system-based GR and protocol-based GR. The protocol-based GR
includes:
z BGP GR
z OSPF GR

z IS-IS GR
z MPLS LDP GR
z L3VPN GR
z RSVP GR
z 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

z BFD for LDP FRR
BFD can detect the protected interfaces that can trigger LDP FRR switching.
z 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.
z 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

relationship of the routing protocol is rapidly detected. The detection parameters of BFD
sessions are negotiated by both ends through the routing protocol.
z 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.
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
BFD for OSPF/BGP

The NE40E supports OSPF and BGP to dynamically set up and delete a BFD session.
z 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.
z 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.
z 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.
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.
z When detecting a fault, a BFD session goes Down. BFD triggers route convergence
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.
z When the neighbor is unreachable, the routing protocol notifies BFD to delete the
session through the RM module.

BFD for PIM

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

IP-Trunk and Eth-Trunk consist of member links, providing large bandwidth or high
reliability.
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.

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:
z 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 R3 R4
Primary LSP
Bypass LSP
R6
z 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.

Figure 5-41 Diagram of TE FRR node protection
PLR MP
R R R R R
1 2 3 4 5
Primary
LSP
Bypass
LSP
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.
z Fault detection.
z BFD for PW can fast detect the fault of the PW at the network side on an L2VPN.
z Ethernet OAM can fast detect the fault at the attachment circuit (AC) side on an L2VPN.
z Fault notification
z LDP, BGP, or RSVP can notify the remote PE of the fault on the LSP/PW or the AC.
z BFD for LSP/PW can notify the remote PE of the fault on the LSP/PW or the AC.
z Ethernet OAM can notify the local CE of the fault.
z Active/standby switchover of links.
z On a symmetric network, CEs perform the active/standby switchover.
z 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.
z 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.

z 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.
z 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.

Product Description 6 Application Scenarios
6 Application Scenarios
About This Chapter

6.1 Application on a Metro Ethernet
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 Edge Core Applicatio
Distribution I n t e rnet
node
BRAS Internet
DSLAM
CMTS Aggregafion P/PE
Node
P/PE SoftX
VoD ES
Distribution P/PE
node
AccSwitch PE VoD CS

6 Application Scenarios Product Description
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.
z 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.
z Switch: refers to the access switch that converges the Layer 2 corporate services to the
aggregation node.
z 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.
z 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.
z BRAS: processes PPPoE login services of individual users.
z 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.
z 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
z 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.
z 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.
z 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
z Corporate dedicated line: The corporate dedicated line is connected to the Layer 3
network through the NE40E at the aggregation node.
z 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.
z 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.

Product Description 6 Application Scenarios
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 E1 TDM*N
BSC
MPLS over SDH/ME
N *E1(ATM IMA) N *E1(ATM IMA)

FE GE
Node B A) CX600 CX600 RNC

IM
TM
1 (A E
*E F
N Transparent transmission
of ATM cells through PWE3
Node B Transparent transmission

of TDM services
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

6 Application Scenarios Product Description
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
POS
BC BC
1588v2 1588v2
GE GE
BC BC
FE E1 E1 FE
1588v2 1588v2
NodeB NodeB NodeB NodeB

with 1588v2 without 1588v2 without 1588v2 with 1588v2

Product Description 7 Operation and Maintenance
7 Operation and Maintenance
About This Chapter

7.1 Benefits
7.2 Network Management System
7.1 Benefits
7.1.1 System Configuration Mode
7.1.2 System Management and Maintenance
7.1.3 HGMP
7.1.4 System Service and Status Tracking
7.1.5 System Test and Diagnosis
7.1.6 In-Service Debugging
7.1.7 Upgrade Features
7.1.8 GTL
7.1.9 Miscellaneous Features
7.1.1 System Configuration Mode

The NE40E provides two configuration modes: command line configuration and NMS
configuration.
Command line configuration supports:
z Local configuration through the console port
z Remote configuration through the AUX port with a Modem
z Remote configuration through Telnet
NMS configuration supports the configuration through the SNMP-based NMS.

7 Operation and Maintenance Product Description
7.1.2 System Management and Maintenance

The NE40E provides the following system management and maintenance functions:
z 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
z Local and remote software upgrading and data loading, upgrade rollback, backup,
storage, and removal
z Hierarchical user authority management, operation log management, online help, and
comments for command lines
z Multi-user operation
z Collection of multi-layer information, including information about ports, Layer 2, and
Layer 3
z 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:
z Monitors the change of the state machine of routing protocols.
z Monitors the change of the state machine of MPLS LDP.
z Monitors the change of VPN-related state machine.
z Monitors the type of protocol packets sent by the NP to the CPU, and displays details
about the packets through debugging.
z Monitors and clears the statistics about abnormal packets.
z Displays notification when the processing of the abnormality takes effect.
z 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

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:
z Common users want to reduce the purchase cost.
z 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.

7 Operation and Maintenance Product Description
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:
z Common users can purchase the service features as required. The purchase cost is thus
reduced.
z 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:
z Hierarchical protection for configuration commands, ensuring that the unauthorized
users cannot access the router.
z Online help available if you type a question mark (?).
z Various debugging information for network troubleshooting.
z DosKey-like function for running a history command.
z 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:
z Real-time management on the topology
z Fault
z Performance
z Configuration tool
z Equipment log
z Security and users
z QoS policy
z VPN service
In addition, it can be used to download, save, modify, and upload configuration files, as well
as upgrade system software.

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.

Product Description 8 Technical Specifications
8 Technical Specifications
About This Chapter

8.1 Physical Specifications
8.2 System Configuration
8.3 System Features
8.1 Physical Specifications

8.1.1 NE40E-X2
8.1.2 NE40E-X1
8.1.1 NE40E-X2
Table 8-1 Parameters of the NE40E-X2
Item Description
Dimensions (W x D x H) 442 mm x 220 mm x 222 mm (5 U height)

Installation Mounted in an N63E cabinet, a standard 19-inch cabinet, or
a 23-inch North American open rack
Weight Full configurations: 21 kg
Maximum power 740 W
Heat dissipation 2401 BTU/hour
DC input Rated -48 V
voltage voltage
Maximum -72 V to -38 V
voltage
range
Ambient Long-term 0°C to 45°C

8 Technical Specifications Product Description
Item Description
temperature Short-term -5°C to 55°C (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.)
Remarks Limit of the temperature change rate: 30°C/hour
Storage temperature -40°C to +70°C
Relative Long-term 5% RH to 85% RH, no coagulation
humidity
Short-term 5% RH to 95% RH, no coagulation
Storage humidity 0% RH to 95% RH, no coagulation
Long-term altitude Lower than 3000 m
Storage altitude Lower than 5000 m
8.1.2 NE40E-X1
Table 8-2 Parameters of the NE40E-X1
Item Description
Dimensions (W x D x H) 442 mm x 220 mm x 132 mm (3 U height)

Installation Mounted in an N63E cabinet, a standard 19-inch cabinet, or
a 23-inch North American open rack
Weight Full configurations: 13 kg
Maximum power 470 W
Heat dissipation 1525 BTU/hour
DC input Rated -48V
voltage voltage
Maximum -72V to -38V
voltage
range
Ambient Long-term 0°C to 45°C
temperature
Short-term -5°C to 55°C (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.)
Remarks Limit of the temperature change rate: 30°C/hour
Storage temperature -40°C to +70°C
Relative Long-term 5% RH to 85% RH, no coagulation

Item Description
humidity Short-term 5% RH to 95% RH, no coagulation
Storage humidity 0% RH to 95% RH, no coagulation
Long-term altitude Lower than 3000 m
Storage altitude Lower than 5000 m
8.2 System Configuration

8.2.1 NE40E-X2
8.2.2 NE40E-X1
8.2.1 NE40E-X2
Table 8-3 Default configurations on the NE40E-X2
Item Default Remarks

Configuration
Processor Dominant -
frequency: 1 GHz
SDRAM 2 GB -
CF card 1 GB The CF card within the MPU stores
system files and does not support hot
swap.
USB interface USB2.0 Host The USB2.0 interface is hot swappable
and used for software upgrade or
temporary data access.
Switching capacity 80 G -
(bi-directional)
User interface capacity 75.2 G -
Number of subcard slots 8
Number of MPU slots 2 -
Number of NPU slots 2 -

8.2.2 NE40E-X1
Table 8-4 Default configurations on the NE40E-X1
Item Default Remarks

Configuration
Processor Dominant -
frequency: 1 GHz
SDRAM 2 GB -
CF card 1 GB The CF card within the MPU stores
system files and does not support hot
swap.
USB interface USB2.0 Host The USB2.0 interface is hot swappable
and used for software upgrade or
temporary data access.
Switching capacity 40 G -
(bi-directional)
User interface capacity 52 G -
Number of subcard slots 4 Slots for the LPUs (optional)
Number of MPU slots 2 -
Number of NPU slots 1 -
8.3 System Features

Table 8-5 System features
Feature Description
Interworking LAN protocols Ethernet_II

IEEE802.1Q
IEEE802.1p
Link layer PPP or MP
protocols RRPP
TDM

Feature Description
Ethernet Basic VLAN features

switching 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 IPv4 Static routing protocol
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

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 MPLS forwarding
functions 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

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 Hot backup 1:1 backup of MPUs
reliability 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

Feature Description
QoS Traffic Simple traffic classification

classification Complex traffic classification: based-on ports or on
Layer 2, Layer 3, or Layer 4 packets
Traffic Traffic policing and traffic shaping based on srTCM
policing and or trTCM
shaping DiffServ EF and AF services
GTS
Congestion PQ/WFQ
management
Congestion WRED
avoidance
Policy-based Route redirection, MPLS LSP explicit route
routing distribution
QPPB IP precedence
Specific traffic behavior
BGP BGP identifies and classifies the routes through BGP
accounting traffic index to account the traffic on the basis of
classification
MPLS HQoS 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
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

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 Command line Local configuration through the console port
management interface 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 In-service upload
upgrade In-service upgrade
In-service patching
ISSU
Information Providing three types of information: alarm, log, and
center 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

Feature Description
Network SNMP v1/v2c/v3

management RMON
NetStream
Traffic statistics

Product Description 9 Compliant Standards
9 Compliant Standards
About This Chapter

9.1 Standards and Telecom Protocols
9.2 Electromagnetic Compatibility Standards
9.3 Safety Standards
9.4 Environmental Standards
9.5 Other Standards
9.1 Standards and Telecom Protocols

AAA
RFC2903 Generic AAA Architecture
RFC2904 AAA Authorization Framework
RFC2906 AAA Authorization Requirements
ARP
RFC1027 Using ARP to implement transparent subnet
gateways
BFD
draft-ietf-bfd-base-05 Bidirectional Forwarding Detection
draft-ietf-bfd-v4v6-1hop-05 BFD for IPv4 and IPv6 (Single Hop)
draft-ietf-bfd-multihop-06 BFD for Multihop Paths
draft-ietf-bfd-mpls-02 BFD For MPLS LSPs
BGP
RFC1105 Border Gateway Protocol BGP

9 Compliant Standards Product Description
RFC1163 A Border Gateway Protocol (BGP)

RFC1164 Application of the Border Gateway Protocol in
the Internet
RFC1265 BGP Protocol Analysis
RFC1266 Experience with the BGP Protocol
RFC 1267 A Border Gateway Protocol 3 (BGP-3)
RFC 1268 Application of the Border Gateway Protocol in
the Internet
RFC1269 Definitions of Managed Objects for the Border
Gateway Protocol:Version 3
RFC1321 The MD5 Message-Digest Algorithm
RFC1397 Default Route Advertisement in BGP2 and BGP3
Version of the Border Gateway Protocol
RFC1403 BGP OSPF Interaction
RFC1654 A Border Gateway Protocol 4 (BGP-4).
RFC1655 Application of the Border Gateway Protocol in
the Internet
RFC1656 BGP-4 Protocol Document Roadmap and
Implementation Experience
RFC1657 basic BGP4 MIB
RFC1771 (BGP-4)
RFC1772 BGP basic functions support
RFC1773 obsoletes RFC 1656
RFC1774 BGP-4 Protocol Analysis
RFC1930 Guidelines for creation, selection, and registration
of an Autonomous System (AS)
RFC1965 Autonomous System Confederations for BGP
RFC1966 BGP Route-Reflection
RFC1997 BGP Community Attribute
RFC1998 An Application of the BGP Community Attribute
RFC2270 Using a Dedicated AS for Sites Homed to a
Single Provider
RFC2283 Multiprotocol Extensions for BGP-4
RFC2385 TCP MD5
RFC2439 BGP Route Flap Damping

RFC2519 A Framework for Inter-Domain Route

Aggregation
RFC2545 BGP suppor IPV6
RFC2547 BGP/MPLS VPNs
RFC2796 BGP Route Reflection
RFC2842 Capabilities Advertisement with BGP-4
RFC2918 Route Refresh Capability for BGP-4
RFC3065 Autonomous System Confederations for BGP
RFC3392 Support BGP capabliteis advertisement
RFC3562 Key Management Considerations for the TCP
MD5 Signature Option
RFC4271 A Border Gateway Protocol 4 (BGP-4)
RFC4272 BGP Security Vulnerabilities Analysis
RFC4273 Definitions of Managed Objects for the Fourth
Version of Border Gateway Protocol (BGP-4)
RFC4274 BGP-4 Protocol Analysis
RFC4275 BGP-4 MIB Implementation Survey
RFC4276 BGP 4 Implementation Report
RFC4277 Experience with the BGP-4 Protocol
RFC4360 BGP Extended Communities Attribute
RFC4364 BGP/MPLS IP Virtual Private Networks
RFC4382 MPLS/BGP Layer 3 Virtual Private Network
(VPN) Management information Base
RFC4456 BGP Route Reflection: An Alternative to Full
Mesh Internal BGP (IBGP)
RFC4486 Subcodes for BGP Cease Notification Message
RFC4724 Graceful Restart Mechanism for BGP
RFC4781 Graceful Restart Mechanism for BGP with MPLS
RFC4798 Connecting IPv6 Islands over IPv4 MPLS using
IPv6 Provider Edge Routers (6PE)
Clock

IEEE1588 Standard for a Precision Clock Synchronization

Protocol for Networked Measurement and
Control Systems
ITU-T G.813 Timing characteristics of SDH equipment slave
clocks (SEC)
ITU-T G.8261 Timing characteristics of SDH equipment slave
clocks (SEC)
ITU-T G.8262 Timing and Synchronization Aspects in Packet
ITU-T G.8264 Timing characteristics of synchronous Ethernet
equipment slave clock (EEC)
ITU-T G.823 Distribution of Timing through Packet Networks
ITU-T G.824 The control of jitter and wander within digital
networks which are based on the 1544 kbit/s
hierarchy.
Ethernet
RFC0826 Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit
Ethernet address for transmission on Ethernet
hardware (ARP)
RFC1042 A Standard for the Transmission of IP Datagrams
over IEEE 802 Networks
IEEE802.1q IEEE Standard for Local and Metropolitan Area
Networks: Virtual Bridged Local Area Networks
IEEE802.1t 802.1D Maintenance
IEEE802.1w Rapid Reconvergence of Spanning Tree (RSTP)
IEEE802.1ah Provider Backbone Bridges
IEEE802.1ap Management Information Base (MIB) definitions
for VLAN Bridges
IEEE802.17 Resilient Packet Ring
IEEE802.2 IEEE Standards for Local Area Networks:
Logical Link Control (LLC)
IEEE802.3 IEEE Standards for Local Area Networks: Carrier
Sense Multiple Access with Collision Detection
(CSMA/CD) Access,Method and Physical Layer
Specifications
IEEE802.3ad Port Trunk, LACP
IEEE802.3ae 10 Gbit/s Ethernet Standard
IEEE802.3af Link Aggregation Control Protocol
IEEE802.1ag Connectivity Fault Management

IEEE802.3ah Ethernet First Mile

IEEE802.3z Gigabit fiber
FTP
RFC0959 File Transfer Protocol (FTP)
IPv6
RFC1886 DNS Extensions to Support IP version 6
RFC1887 An Architecture for IPv6 Unicast Address
Allocation
RFC1970 Neighbor Discovery for IP Version 6 (IPv6)
RFC2023 IP Version 6 over PPP
RFC2373 IP Version 6 Addressing Architecture
RFC2374 An IPv6 Aggregatable Global Unicast Address
Format
RFC2375 IPv6 Multicast Address Assignments
RFC2452 MIB for TCP6
RFC2454 MIB for UDP6
RFC2460 Internet Protocol, Version 6 (IPv6) Specification
RFC2461 Neighbor Discovery for IP Version 6 (IPv6)
RFC2462 IPv6 Stateless Address Auto configuration
RFC2463 Internet Control Message Protocol (ICMPv6) for
the Internet Protocol Version 6
(IPv6)Specification
RFC2464 Transmission of IPv6 Packets over Ethernet
Networks
RFC2470 Transmission of IPv6 Packets over Token Ring
Networks
RFC2472 IP Version 6 over PPP
RFC2473 Generic Packet Tunneling in IPv6 Specification
RFC2452 MIB for TCP6
RFC2454 MIB for UDP6
RFC2529 Transmission of Ipv6 over Ipv4 Domains without
Explicit Tunnels
RFC2893 Transition Mechanisms for Ipv6 Hosts and
Routers
RFC3056 Connection of Ipv6 Domains via Ipv4 Clouds

RFC3363 Representing Internet Protocol version 6 (Ipv6)

Addresses in the Domain Name System (DNS).
RFC3493 Basic Socket Interface Extensions for IPv6
RFC3513 IP Version 6 Addressing Architecture
RFC3542 Advanced Sockets API for Ipv6
RFC3587 An Aggregatable Global Unicast Address Format
RFC3775 Mobility Support in IPv6
ISIS
RFC1142 OSI IS-IS Intra-domain Routing Protocol
ISO10598 IS-IS intra-domain routing protocol
RFC1195 Use of OSI Is-Is for Routing in TCP/IP and Dual
Environments
RFC2104 HMAC: Keyed-Hashing for Message
Authentication
RFC2763 Dynamic Name-to-systemID mapping support
RFC2966 route leak support
RFC2973 Support IS-IS Mesh Groups
RFC3277 IS-IS Transient Blackhole Avoidance
RFC3359 Reserved Type, Length and Value (TLV)
Codepoints in Intermediate System to
Intermediate System
RFC3373 Three-Way Handshake for Intermediate System
to Intermediate System (IS-IS) Point-to-Point
Adjacencies
RFC3567 Intermediate System to Intermediate System
(IS-IS) Cryptographic Authentication
RFC3719 Recommendations for Interoperable Networks
using IS-IS
RFC3784 ISIS TE support
RFC3786 Extending the Number of IS-IS LSP Fragments
Beyond the 256 Limit
RFC3787 Recommendations for Interoperable IP Networks
using IS-IS
RFC3847 Restart signaling for IS-IS
RFC4444 Management Information Base for Intermediate
System to Intermediate System (IS-IS)
ISO10589 IS-IS intra-domain routing protocol

L2 protocol
RFC1216 Gigabit network economics and paradigm shifts
RFC1619 PPP over SONET/SDH prior to insertion into
SPE
RFC1717 The PPP Multilink Protocol (MP)
RFC2285 Benchmarking Terminology for LAN Switching
Devices
RFC2665 Definitions of Managed Objects for the
Ethernet-like Interface Types
RFC2674 Definitions of Managed Objects for Bridges with
Traffic Classes,Multicast Filtering and Virtual
LAN Extensions
RFC2863 The Interfaces Group MIB
RFC3020 MIB for FRF.16 UNI/NNI MFR
RFC3201 Circuit to Interface MIB
Ethernet-like Interface Types
RFC4087 IP Tunnel MIB
ITU-T G.703 Physical/electrical characteristics of hierarchical
digital interfaces
ITU-T G.704 Synchronous frame structures used at 1544,
6312,2048, 8448 and 44 736 kbit/s hierarchical
levels.
ITU-T G.707 Network node interface for the synchronous
digital hierarchy (SDH)
networks which are based on the synchronous
digital hierarchy (SDH).
hierarchy.
hierarchy.
ANSI T1.105 Synchronous Optical Network(SONET) Basic
Description Including Multiplex Structures,
Rates,
and Formats
ANSI T1.105.02 Synchronous Optical Network(SONET) Payload
Mappings

L3 protocol
RFC2544 Benchmarking Methodology for Network
Interconnect Devices
RFC2668 Definitions of Managed Objects for IEEE 802.3
Medium Attachment Units (MAUs).
MPLS
RFC2205 Resource ReSerVation Protocol(RSVP)-Version
1 Functional Specification
RFC2209 Resource ReSerVation Protocol(RSVP)-Version
1 Message Processing Rules
RFC2210 The Use of RSVP with IETF Integrated Services
RFC2702 Requirements for Traffic Engineering Over
MPLS
RFC2747 RSVP Cryptographic Authentication
RFC2961 RSVP Refresh Overhead Reduction Extensions
RFC3031 Multiprotocol Label Switching Architecture
RFC3032 MPLS Label Stack Encoding
RFC3035 MPLS using LDP and ATM VC Switching
RFC3036 LDP Specification
RFC3037 LDP Applicability
RFC3063 MPLS Loop Prevention Mechanism
RFC3107 Support BGP carry Label for MPLS
RFC3209 RSVP-TE Extensions to RSVP for LSP Tunnels
RFC3210 Applicability Statement for Extensions to RSVP
for LSP-Tunnels
RFC3212 Constraint-Based LSP setup using LDP
(CR-LDP)
RFC3214 LSP Modification Using CR-LDP
RFC3215 LDP State Machine
RFC3270 Multi-Protocol Label Switching (MPLS) Support
of Differentiated Services
RFC3272 Overview and Principles of Internet Traffic
Engineering
RFC3443 Time To Live (TTL) Processing in Multi-Protocol
Label Switching (MPLS) Networks

RFC3469 Framework for Multi-Protocol Label Switching

(MPLS)-based Recovery
RFC3478 Graceful Restart Mechanism for LDP
RFC3479 Fault Tolerance for the Label Distribution
Protocol (LDP)
RFC3496 Protocol Extension for Support of Asynchronous
Transfer Mode (ATM) Service Class-aware
Multiprotocol Label Switching (MPLS) Traffic
Engineering
RFC3612 Applicability Statement for Restart Mechanisms
for the Label Distribution Protocol (LDP)
RFC4090 Fast Reroute Extensions to RSVP-TE for LSP
Tunnels
RFC4124 Protocol Extensions for Support of DS-TE
RFC4125 Maximum Allocation Bandwidth Constraints
Model for Diffserv-aware MPLS Traffic
Engineering
RFC4126 Max Allocation with Reservation Bandwidth
Constraints Model for Diffserv-aware MPLS
Traffic Engineering & Performance Comparisons
RFC4127 Generalized MPLS Signaling - RSVP-TE
Extensions
RFC4182 Removing a Restriction on the use of MPLS
Explicit NULL
RFC4197 Requirements for Edge-to-Edge Emulation of
Time Division Multiplexed (TDM) Circuits over
Packet Switching Networks
RFC4221 Multiprotocol Label Switching (MPLS)
Management Overview
RFC4377 Operations and Management (OAM)
Requirements for MPLS
RFC4378 A Framework for Multi-Protocol Label Switching
(MPLS) Operations and Management (OAM).
RFC4379 Detecting Multi-Protocol Label Switched (MPLS)
Data Plane Failures
RFC4446 IANA Allocations for Pseudowire Edge to Edge
Emulation (PWE3)
RFC4447 Pseudowire Setup and Maintenance Using the
Label Distribution Protocol (LDP)
RFC4448 Encapsulation Methods for Transport of Ethernet
over MPLS Networks

RFC4558 Node-ID Based Resource Reservation Protocol

(RSVP) Hello
RFC4874 Exclude Routes - Extension to RSVP-TE
RFC4905 Encapsulation Methods for Transport of Layer 2
Frames Over MPLS Networks
RFC4906 Transport of Layer 2 Frames Over MPLS
draft-ietf-mpls-lsp-ping-version-09 Detecting Multi-Protocol Label Switched (MPLS)
Data Plane Failures
draft-ietf-ccamp-inter-domain-framew Mechanisms for Inter-AS or Inter-Domain Traffic
ork-04 Engineering
draft-minei-diffserv-te-multi-class-02 Extensions for Differentiated Services-aware
Traffic Engineered LSPs
ITU-T Y.1710 Requirements for OAM functionality for MPLS
networks
ITU-T Y.1711 Operation and maintenance mechanism for MPLS
networks
ITU-T Y.1720 Protection switching for MPLS networks
MSTP
IEEE802.1s Multiple Spanning Trees
IEEE802.1ad Virtual Bridged Local Area Networks -
Amendment 4: Provider Bridges,QinQ
Multicast
RFC1112 Host Extensions for IP Multicasting
RFC2236 Internet Group Management Protocol, Version 2
RFC2362 Protocol Independent Multicast-Sparse Mode
(PIM-SM):Protocol Specification
RFC3446 Anycast Rendevous Point (RP) mechanism using
Protocol Independent Multicast (PIM) and
Multicast Source Discovery Protocol (MSDP)
RFC3569 An Overview of Source-Specific Multicast (SSM)
RFC3956 Embedding the Rendezvous Point (RP) Address
in an IPv6 Multicast Address
RFC3973 Embedding the Rendezvous Point (RP) Address
in an IPv6 Multicast Address
RFC4541 Considerations for Internet Group Management
Protocol (IGMP)and Multicast Listener
Discovery (MLD) Snooping Switches

RFC4601 Protocol Independent Multicast - Sparse Mode

(PIM-SM): Protocol Specification (Revised)
RFC4604 Using Internet Group Management Protocol
Version 3 (IGMPv3) and Multicast Listener
Discovery Protocol Version 2 (MLDv2) for
Source-Specific Multicast
draft-fenner-traceroute-ipm-01 A "traceroute" facility for IP Multicast
draft-ietf-magma-snoop-12 Considerations for Internet Group Management
Protocol (IGMP)and Multicast Listener
Discovery (MLD) Snooping Switches
NTP
RFC1305 Network Time Protocol (Version 3)
OSPF
RFC1131 OSPF specification
RFC1242 Benchmarking terminology for network
interconnection devices
RFC1245 OSPF Protocol Analysis
RFC1246 Experience with the OSPF Protocol
RFC1247 OSPF Version 2
RFC1248 OSPF Version 2 Management Information Base
RFC1587 The OSPF NSSA Option
RFC1765 OSPF Database Overflow
RFC2329 OSPF Standardization Report
RFC2370 The OSPF Opaque LSA Option
RFC2740 OSPF for IPv6 (OSPFv3)
RFC3101 The OSPF NSSA Option
RFC3137 OSPF Stub Router Advertisement
RFC3623 OSPF Graceful Restart
RFC3630 Traffic Engineering Extensions to OSPF

RFC4167 Graceful OSPF Restart Implementation Report

RFC4970 Extensions to OSPF for Advertising Optional
Router
PPP
RFC1332 The PPP Internet Protocol Control Protocol
(IPCP)
RFC1334 PPP Authentication Protocols
RFC1377 The PPP OSI Network Layer Control Protocol
(OSINLCP).
RFC1471 The Definitions of Managed Objects for the IP
Network Control Protocol of the Point-to-Point
Protocol
RFC1473 The Definitions of Managed Objects for the IP
Network Control Protocol of the Point-to-Point
Protocol.
RFC1570 PPP LCP Extensions
RFC1661 The Point-to-Point Protocol (PPP)
RFC1990 The PPP Multilink Protocol (MP)
RFC1915 The PPP Connection Control Protocol
RFC1989 PPP Link Quality Monitoring
RFC1994 PPP Challenge Handshake Authentication
Protocol (CHAP
RFC2364 PPP over AAL5 (PPPoA)
RFC2509 IP Header Compression over PPP
RFC2615 PPP over SONET/SDH
QoS
RFC1144 Compressing TCP/IP Headers for Low-Speed
Serial Links
RFC1349 Type of Service in the Internet Protocol Suite
RFC2309 Recommendations on Queue Management and
Congestion Avoidance in the Internet
RFC2386 A Framework for QoS-based Routing in the
Internet
RFC2474 Definition of the Differentiated Services Field
(DS Field) in the IPv4 and IPv6 Headers
RFC2475 An Architecture for Differentiated Services
RFC2597 Assured Forwarding PHB Group

RFC2598 An Expedited Forwarding PHB

RFC2697 A Single Rate Three Color Marker.
RFC2698 A Two Rate Three Color Marker
RFC3086 Definition of Differentiated Services Per Domain
Behaviors and Rules for their Specification
RFC3246 An Expedited Forwarding PHB (Per-Hop
Behavior)
RFC3247 Supplemental Information for the New Definition
of the EF PHB
RFC3260 New Terminology and Clarifications for Diffserv
RFC3290 An Informal Management Model for Diffserv
Routers
IEEE802.1p LAN Layer 2 QoS/CoS Protocol for Traffic
Prioritization
RIP
RFC1058 Routing Information Protocol (RIP)
RFC1389 RIP Version 2 MIB Extension
RFC2080 RIPng support
RFC2081 RIPng Protocol Applicability Statement
RFC2082 RIP-2 MD5 Authentication
RFC2091 Triggered Extensions to RIP to Support Demand
Circuits
RFC2453 RIP Version 2
RMON
RFC2021 Remote Network Monitoring Management
Information Base Version 2 using SMIv2?
RFC2819 Remote Network Monitoring Management
Information Base
Security
RFC1519 Classless Inter-Domain Routing (CIDR): an
Address Assignment and Aggregation Strategy
RFC2085 HMAC-MD5 IP Authentication with Replay
Prevention
RFC2267 Network Ingress Filtering: Defeating Denial of
Service Attacks which employ IP Source Address
Spoofing
RFC2338 Virtual Router Redundancy Protocol

RFC2365 Administratively Scoped IP Multicast

RFC2787 Definitions of Managed Objects for the Virtual
Router Redundancy Protocol
RFC2827 Network Ingress Filtering: Defeating Denial of
Service Attacks which employ IP Source Address
Spoofing.
RFC2865 Remote Authentication Dial In User Service
(RADIUS)
RFC2866 RADIUS Accounting
RFC2867 RADIUS Accounting Modifications for Tunnel
Protocol Support
RFC2868 RADIUS Attributes for Tunnel Protocol Support
RFC2869 RADIUS Extensions
RFC2903 Generic AAA Architecture
RFC2904 AAA Authorization Framework
RFC2906 AAA Authorization Requirements
RFC3575 IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)
RFC3682 The Generalized TTL Security Mechanism
(GTSM)
RFC3768 Virtual Router Redundancy Protocol (VRRP)
SNMP
RFC1155 Structure and identification of management
information for TCP/IP-based internets
RFC1157 Simple Network Management Protocol (SNMP)
RFC1212 Concise MIB definitions
RFC1214 Definitions of Managed Objects for Data Link
Switching using SMIv2.
RFC1215 A Convention for Defining Traps for use with the
SNMP
RFC1901 Introduction to Community-based SNMPv2
RFC1902 Structure of Management Information for Version
2 of the Simple Network Management Protocol
(SNMPv2)
RFC1903 Textual Conventions for Version 2 of the Simple
Network Management Protocol (SNMPv2)

RFC1904 Conformance Statements for Version 2 of the

Simple Network Management Protocol
(SNMPv2)
RFC1905 Protocol Operations for Version 2 of the Simple
RFC1906 Transport Mappings for Version 2 of the Simple
RFC1907 Management Information Base for Version 2 of
the Simple Network Management Protocol
(SNMPv2)
RFC2570 Introduction to Version 3 of the Internet-standard
Network Management Framework
RFC2571 An Architecture for Describing SNMP
Management Frameworks
RFC2572 Message Processing and Dispatching for the
Simple Network Management Protocol (SNMP)
RFC2573 SNMP Applications
RFC2574 User-based Security Model (USM) for version 3
of the Simple Network Management Protocol
(SNMPv3)
RFC2575 View-based Access Control Model (VACM) for
(SNMP)
RFC2576 Coexistence between Version 1, Version 2, and
Version 3 of the Internet-standard Network
Management Framework
RFC2578 Structure of Management Information Version 2
(SMIv2)
RFC2579 Textual Conventions for SMIv2
RFC2580 Conformance Statements for SMIv2
RFC3410 An Architecture for Describing Simple Network
Management Protocol (SNMP) Management
Frameworks
RFC3411 An Architecture for Describing Simple Network
Management Protocol (SNMP) Management
rameworks
RFC3412 Message Processing and Dispatching for the
Simple NetworkManagement Protocol SNMP)
RFC3413 Simple Network Management Protocol (SNMP)
Applications

RFC3414 User-based Security Model (USM) for version 3

of the Simple Network Management Protocol
(SNMPv3)
RFC3415 View-based Access Control Model (VACM) for
(SNMP)
RFC3416 Version 2 of the Protocol Operations for the
Simple Network Management Protocol (SNMP).
RFC3418 Management Information Base (MIB) for the
Simple Network Management Protocol (SNMP).
RFC3512 Configuring Networks and Devices with Simple
Network Management Protocol (SNMP).
SSHV2
RFC4245 Improved Arcfour Modes for the Secure Shell
(SSH) Transport Layer Protocol
RFC4250 Protocol Assigned Numbers
RFC4251 The Secure Shell (SSH) Protocol Architecture
RFC4252 The Secure Shell (SSH) Authentication Protocol
RFC4253 The Secure Shell (SSH) Transport Layer Protocol
RFC4254 The Secure Shell (SSH) Connection Protocol
System Management
RFC0135 Conventions for using an IBM 2741 terminal as a
user console for access to network server hosts
RFC1200 IAB official protocol standards
RFC1350 The TFTP Protocol (Revision 2)
RFC1493 Definitions of Managed Objects for Bridges
RFC1814 Requirements for IP Version 4 Routers
RFC2096 IP Forwarding Table MIB
RFC2213 Integrated Services Management Information
Base using SMIv2
RFC2233 The Interfaces Group MIB using SMIv2
RFC2493 Textual Conventions for MIB Modules Using
Performance History Based on 15 Minute
Intervals
RFC2737 Entity MIB (Version 2).
RFC2925 Definitions of Managed Objects for Remote Ping,
Traceroute, and Lookup Operations.


Synchronous Optical Network/Synchronous
Digital Hierarchy (SONET/SDH) Interface Type
RFC3636 Definitions of Managed Objects for IEEE 802.3
Medium Attachment Units (MAUs).
RFC3737 IANA Guidelines for the Registry of Remote
Monitoring (RMON) MIB modules
RFC3877 Alarm Management Information Base (MIB).
RFC3954 -
TCP/IP
RFC0768 User Datagram Protocol
RFC0791 INTERNET PROTOCOL DARPA INTERNET
PROGRAM PROTOCOL SPECIFICATION
RFC0792 INTERNET CONTROL MESSAGE
PROTOCOL
RFC0793 TRANSMISSION CONTROL PROTOCOL
RFC0813 Window and Acknowledgement Strategy in
TCP/IP
RFC0950 Internet Standard Subnetting Procedure
RFC1034 Domain Names - Concepts and Facilities
RFC1035 Domain Names - Implementation and
Specification
RFC1071 Computing the Internet Checksum
RFC1122 Requirements for Internet Hosts --
Communication Layers
RFC1141 Incremental Updating of the Internet Checksum
RFC1219 On the assignment of subnet numbers.
RFC1256 ICMP Router Discovery Messages
RFC1323 TCP Extensions for High Performance?
RFC1533 DHCP Options and BOOTP Vendor
ExtensionsClass-identifier
RFC1534 Interoperation Between DHCP and BOOTP?
RFC1542 Clarifications and Extensions for the Bootstrap
Protocol
RFC1624 Computation of the Internet Checksum via
Incremental Update
RFC1878 Variable Length Subnet Table For IPv4

RFC2131 Dynamic Host Configuration Protocol

RFC2132 DHCP Options and BOOTP Vendor Extensions
RFC2507 IP Header Compression
RFC2508 Compressing IP/UDP/RTP Headers for
Low-Speed Serial Links
RFC2581 TCP Congestion Control
RFC2644 Changing the Default for Directed Broadcasts in
Routers
RFC2694 DNS extensions to Network Address Translators
(DNS_ALG)
RFC3046 DHCP Relay Agent Information Option.
RFC3396 Encoding Long Options in the Dynamic Host
Configuration Protocol (DHCPv4)
TELNET
RFC0854 TELNET PROTOCOL SPECIFICATION
RFC0857 TELNET ECHO OPTION
RFC0858 TELNET SUPPRESS GO AHEAD OPTION
RFC1091 Telnet Terminal-Type Option
VPN
RFC1702 Generic Routing Encapsulation over IPv4
networks
RFC2764 A Framework for IP Based Virtual Private
Networks
RFC2983 Differentiated Services and Tunnels
RFC3916 Requirements for Pseudo-Wire Emulation
Edge-to-Edge (PWE3).
RFC3985 Pseudo Wire Emulation Edge-to-Edge (PWE3)
Architecture
RFC4110 A Framework for Layer 3 Provider-Provisioned
Virtual Private Networks (PPVPNs).
RFC4364 BGP/MPLS IP Virtual Private Networks (VPNs)
RFC4385 Pseudowire Emulation Edge-to-Edge (PWE3)
Control Word for Use over an MPLS PSN
RFC4618 Encapsulation Methods for Transport of
PPP/HDLC over MPLS Networks
RFC4659 BGP-MPLS VPN Extension for IPv6 VPN

RFC4664 Framework for Layer 2 Virtual Private Networks

(L2VPNs)
RFC4665 Service Requirements for Layer 2
Provider-Provisioned Virtual Private Networks
RFC4684 Constrained Route Distribution for Border
Gateway Protocol/MultiProtocol Label Switching
(BGP/MPLS) Internet Protocol (IP) Virtual
Private Networks (VPNs)
RFC4761 Virtual Private LAN Service (VPLS) Using BGP
for Auto-Discovery and Signaling
RFC4762 Virtual Private LAN Service (VPLS) Using Label
Distribution Protocol (LDP) Signaling
RFC5085 Pseudowire Virtual Circuit Connectivity
Verification (VCCV): A Control Channel for
Pseudowires
RFC5086 Structure-Aware Time Division Multiplexed
(TDM) Circuit Emulation Service over Packet
Switched Network (CESoPSN)
RFC5287 Control Protocol Extensions for the Setup of
Time-Division Multiplexing (TDM) Pseudowires
in MPLS Networks
draft-ietf-pwe3-hdlc-ppp-encap-mpls- Encapsulation Methods for Transport of
09 PPP/HDLC Over MPLS Networks
draft-ietf-pwe3-vccv-10 Pseudo Wire Virtual Circuit Connectivity
Verification (VCCV)
draft-raggarwa-rsvpte-pw-00 Setup and Maintenance of Pseudowires using
RSVP-TE
Verification (VCCV)
Verification (VCCV)
draft-ietf-l2vpn-vpls-bgp-06 Virtual Private LAN Service
draft-ietf-l2vpn-vpls-ldp-02 Virtual Private LAN Services over MPLS
draft-kompella-l2vpn-l2vpn-00 pseudo wires created using BGP as signalling and
auto-discovery protocol
draft-ietf-pwe3-cell-transport-04 -
draft-ietf-pwe3-hdlc-ppp-encap-mpls- -
07
draft-ietf-pwe3-vccv-07 -
draft-ietf-l2vpn-l2-framework-05 -

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

z CISPR22 Class B
z CISPR24
z EN55022 Class A
z EN50024
z ETSI EN 300 386 Class A
z ETSI ETS 300 132-2
z CFR 47 FCC Part 15 Class A
z ICES 003 Class A
z AS/NZS CISPR22 Class A
z GB9254 Class A
z VCCI Class A
z CNS 13438 Class A
9.3 Safety Standards

z IEC 60950-1
z IEC/EN41003
z EN 60950-1
z UL 60950-1
z CSA C22.2 No 60950-1

z AS/NZS 60950.1
z BS EN 60950-1
z ITU-T K.20
z GB4943
z FDA rules, 21 CFR 1040.10 and 1040.11
z IEC60825-1, IEC60825-2, EN60825-1, EN60825-2
z GB7247
z IEC GR-1089-CORE
9.4 Environmental Standards

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

z ICNIRP Guideline
z 1999-519-EC
z EN 50385
z OET Bulletin 65
z IEEE Std C95.1
z EN 60215
z ITU-T K.27
z ETSI EN 300 253

Product Description A Acronyms and Abbreviations
A Acronyms and Abbreviations
AAA Authentication, Authorization and Accounting

AAL5 ATM Adaptation Layer 5
AC Alternating Current
ACL Access Control List

AF Assured Forwarding
ANSI American National Standard Institute
ARP Address Resolution Protocol

ASBR Autonomous System Boundary Router
ASIC Application Specific Integrated Circuit
ATM Asynchronous Transfer Mode
AUX Auxiliary (port)
B
BE Best-Effort
BGP Border Gateway Protocol
BGP4 BGP Version 4
C
CAR Committed Access Rate
Issue 01 (2010-03-01) Huawei Proprietary and Confidential A-1

A Acronyms and Abbreviations Product Description
CBR Constant Bit Rate

CE Customer Edge
CHAP Challenge Handshake Authentication Protocol
CoS Class of Service
CPU Center Processing Unit
CR-LDP Constrained Route - Label Distribution Protocol
DC Direct Current
DHCP Dynamic Host Configuration Protocol
DNS Domain Name Server
DS Differentiated Services
E
EACL Enhanced Access Control List
EF Expedited Forwarding
EMC ElectroMagnetic Compatibility
FE Fast Ethernet
FEC Forwarding Equivalence Class
FIB Forward Information Base
FIFO First In First Out
FR Frame Relay
FTP File Transfer Protocol
G
GE Gigabit Ethernet
GRE Generic Routing Encapsulation
A-2 Huawei Proprietary and Confidential Issue 01 (2010-03-01)

GTS Generic Traffic Shaping
H
HA High availability
HDLC High level Data Link Control
HTTP Hyper Text Transport Protocol
ICMP Internet Control Message Protocol

IDC Internet Data Center
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IGMP Internet Group Management Protocol
IGP Interior Gateway Protocol
IP Internet Protocol
IPoA IP Over ATM
IPTN IP Telephony Network
IPv4 IP version 4
IPv6 IP version 6
IPX Internet Packet Exchange
IS-IS Intermediate System-to-Intermediate System
ISP Interim inter-switch Signaling Protocol
ITU International Telecommunication Union - Telecommunication
Standardization Sector
L
L2TP Layer 2 Tunneling Protocol
LAN Local Area Network

LCD Liquid Crystal Display

LCP Link Control Protocol
LDP Label Distribution Protocol
LER Label switching Edge Router
LPU Line Processing Unit
LSP Label Switched Path
LSR Label Switch Router
M
MAC Media Access Control
MBGP Multiprotocol Border Gateway Protocol
MD5 Message Digest 5
MIB Management Information Base
MP Multilink PPP
MPLS Multi-protocol Label Switch
MSDP Multicast Source Discovery Protocol
MSTP Multiple Spanning Tree Protocol
MTBF Mean Time Between Failures
MTTR Mean Time To Repair
MTU Maximum Transmission Unit
N
NAT Network Address Translation
NLS Network Layer Signaling
NP Network Processor
NTP Network Time Protocol
NVRAM Non-Volatile Random Access Memory
O
OSPF Open Shortest Path First

PAP Password Authentication Protocol

PE Provider Edge
PFE Packet Forwarding Engine
PIC Parallel Interference Cancellation
PIM-DM Protocol Independent Multicast-Dense Mode
PIM-SM Protocol Independent Multicast-Sparse Mode
POP Point Of Presence
POS Packet Over SDH/SONET
PPP Point-to-Point Protocol
PQ Priority Queue
PT Protocol Transfer
PVC Permanent Virtual Channel
QoS Quality of Service
R
RADIUS Remote Authentication Dial in User Service
RAM Random-Access Memory
RED Random Early Detection
RFC Requirement for Comments
RH Relative Humidity
RIP Routing Information Protocol
RMON Remote Monitoring
ROM Read Only Memory
RP Rendezvous Point
RPR Resilient Packet Ring
RSVP Resource Reservation Protocol
RSVP-TE RSVP-Traffic Engineering

S
SAP Service Advertising Protocol
SCSR Self-Contained Standing Routing
SDH Synchronous Digital Hierarchy
SDRAM Synchronous Dynamic Random Access Memory
SFU Switch Fabric Unit
SLA Service Level Agreement
SNAP SubNet Attachment Point
SNMP Simple Network Management Protocol
SONET Synchronous Optical Network
SP Strict Priority
SPI4 SDH Physical Interface
SSH Secure Shell
STM-16 SDH Transport Module -16
SVC Switching Virtual Connection
T
TCP Transfer Control Protocol
TE Traffic Engineering
TFTP Trivial File Transfer Protocol
TM Traffic Manager
ToS Type of Service
TP Topology and Protection packet
U
UBR Unspecified Bit Rate
UDP User Datagram Protocol
UNI User Network Interface
UTP Unshielded Twisted Pair

VBR-NRT Non-Real Time Variable Bit Rate

VBR-RT Real Time Variable Bit Rate
VC Virtual Circuit
VCI Virtual Channel Identifier
VDC Variable Dispersion Compensator
VLAN Virtual Local Area Network
VLL Virtual Leased Line
VPI Virtual Path Identifier
VPLS Virtual Private LAN Service
VPN Virtual Private Network
VRP Versatile Routing Platform
VRRP Virtual Router Redundancy Protocol
W
WAN Wide Area Network
WFQ Weighted Fair Queuing
WRED Weighted Random Early Detection

WRR Weighted Round Robin


NE40E X1 NE40E X2 Product Description

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

NE40E X1 NE40E X2 Product Description

Caricato da

Copyright:

Formati disponibili

HUAWEI NetEngine40E Universal Service Router

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Proprietary and Confidential

About This Document

Product Name Version

HUAWEI NetEngine40E Universal V600R002C03

1 Introduction This chapter introduces the product positioning and

Issue 01 (2010-03-01) Huawei Proprietary and Confidential iii

Indicates a hazard with a high level of risk, which if not

Indicates a hazard with a medium or low level of risk,

Indicates a potentially hazardous situation, which if not

iv Huawei Proprietary and Confidential Issue 01 (2010-03-01)

Times New Roman Normal paragraphs are in Times New Roman.

Boldface The keywords of a command line are in boldface.

Boldface Buttons, menus, parameters, tabs, window, and dialog titles

Issue 01 (2010-03-01) Huawei Proprietary and Confidential v

> Multi-level menus are in boldface and separated by the ">"

Click Select and release the primary mouse button without

Updates in Issue 01(2010-03-01)

vi Huawei Proprietary and Confidential Issue 01 (2010-03-01)

About This Document...................................................................................................................iii

Issue 01 (2010-03-01) Huawei Proprietary and Confidential vii

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

viii Huawei Proprietary and Confidential Issue 01 (2010-03-01)

5.7.7 HQoS .................................................................................................................................................5-47

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

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

Issue 01 (2010-03-01) Huawei Proprietary and Confidential ix

7.1.4 System Service and Status Tracking ....................................................................................................7-2

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

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

x Huawei Proprietary and Confidential Issue 01 (2010-03-01)

Figure 2-1 Physical architecture.........................................................................................................................2-1

Figure 2-4 Software architecture ........................................................................................................................2-3

Figure 3-2 Direction of air flow in the NE40E-X2.............................................................................................3-2

Figure 3-5 Direction of air flow in the NE40E-X1.............................................................................................3-6

Figure 5-2 Networking diagram of applying VLAN-based QinQ......................................................................5-5

Issue 01 (2010-03-01) Huawei Proprietary and Confidential xi

Figure 5-13 BGP/MPLS L3VPN......................................................................................................................5-28

Figure 5-14 Networking diagram of applying public network multicast..........................................................5-29

Figure 5-26 Flowchart of traffic policing with CAR........................................................................................5-45

Figure 5-29 Networking diagram of 802.1p re-marking supported by QinQ...................................................5-49

Figure 5-32 CAR traffic statistics.....................................................................................................................5-52

Figure 5-41 Diagram of TE FRR node protection............................................................................................5-75

Figure 6-3 Clock synchronization in IEEE 1588v2............................................................................................6-4

xii Huawei Proprietary and Confidential Issue 01 (2010-03-01)

Table 1-1 Reliability implementation .................................................................................................................1-4

Table 3-3 Description of the slots on the NE40E-X2 .........................................................................................3-3

Table 3-9 Description of the interfaces on the MPU ..........................................................................................3-9

Table 8-3 Default configurations on the NE40E-X2 ..........................................................................................8-3

Issue 01 (2010-03-01) Huawei Proprietary and Confidential xiii

About This Chapter

1.2 Product Features

Issue 01 (2010-03-01) Huawei Proprietary and Confidential 1-1

Diverse LPU Types

Powerful Forwarding Capability

Perfect QoS Mechanism

1-2 Huawei Proprietary and Confidential Issue 01 (2010-03-01)

Excellent Security Design

Issue 01 (2010-03-01) Huawei Proprietary and Confidential 1-3

Complete IPv4/IPv6 Solutions

Good Compatibility and Scalability