ZXA10 C600&C650&C620 (V2.0.10) Optical Access Convergence Equipment Feature Description

ZXA10 C600/C650/C620
Optical Access Convergence Equipment

Feature Description
Version: V2.0.10
ZTE CORPORATION
ZTE Plaza, Keji Road South, Hi-Tech Industrial Park,
Nanshan District, Shenzhen, P.R.China
Postcode: 518057
Tel: +86-755-26771900
URL: http://support.zte.com.cn
E-mail: [email protected]
LEGAL INFORMATION
Copyright 2023 ZTE CORPORATION.
The contents of this document are protected by copyright laws and international treaties. Any reproduction or
distribution of this document or any portion of this document, in any form by any means, without the prior written
consent of ZTE CORPORATION is prohibited. Additionally, the contents of this document are protected by con-
tractual confidentiality obligations.
All company, brand and product names are trade or service marks, or registered trade or service marks, of ZTE
CORPORATION or of their respective owners.
This document is provided as is, and all express, implied, or statutory warranties, representations or conditions are
disclaimed, including without limitation any implied warranty of merchantability, fitness for a particular purpose,
title or non-infringement. ZTE CORPORATION and its licensors shall not be liable for damages resulting from the
use of or reliance on the information contained herein.
ZTE CORPORATION or its licensors may have current or pending intellectual property rights or applications
covering the subject matter of this document. Except as expressly provided in any written license between ZTE
CORPORATION and its licensee, the user of this document shall not acquire any license to the subject matter
herein.
ZTE CORPORATION reserves the right to upgrade or make technical change to this product without further notice.
Users may visit the ZTE technical support website http://support.zte.com.cn to inquire for related information.
The ultimate right to interpret this product resides in ZTE CORPORATION.
Statement on the Use of Third-Party Embedded Software:

If third-party embedded software such as Oracle, Sybase/SAP, Veritas, Microsoft, VMware, and Redhat is deliv-
ered together with this product of ZTE, the embedded software must be used as only a component of this product.
If this product is discarded, the licenses for the embedded software must be void either and must not be trans-
ferred. ZTE will provide technical support for the embedded software of this product.
Revision History
Revision No. Revision Date Revision Reason

R1.0 2023-10-30 First edition
Serial Number: SJ-20230719162004-003
Publishing Date: 2023-10-30 (R1.0)

Contents
1 GPON Access Features.........................................................................................1

1.1 GPON Physical Characteristic.............................................................................................1
1.2 GPON Optical Layer Features............................................................................................ 4
1.3 GPON ONU Authentication and Registration......................................................................6
1.4 GPON DBA Features........................................................................................................ 10
1.5 GPON Ranging Features.................................................................................................. 12
1.6 GEM Port Features........................................................................................................... 13
1.7 GPON Data Encryption..................................................................................................... 16
1.8 GPON Protection............................................................................................................... 17
1.8.1 ITU-T Type B Protection Feature......................................................................... 18
1.8.2 ITU-T Type C Protection Feature.........................................................................19
1.8.3 Inter-OLT Protection Feature................................................................................20
2 XG-PON Access Features................................................................................... 23
2.1 XG-PON Physical Characteristic....................................................................................... 23
2.2 XG-PON Optical Layer Feature........................................................................................ 25
2.3 XG-PON ONU Authentication and Registration................................................................ 26
2.4 XG-PON DBA Feature...................................................................................................... 27
2.5 XG-PON Ranging Feature................................................................................................ 28
2.6 XGEM Port Feature...........................................................................................................29
2.7 XG-PON Data Encryption..................................................................................................31
2.8 XG-PON Protection........................................................................................................... 31
3 Combo PON Feature............................................................................................32
4 XGS-PON Access Features................................................................................. 35
4.1 XGS-PON Physical Characteristic.....................................................................................35
4.2 XGS-PON Optical Layer Feature...................................................................................... 38
4.3 XGS-PON ONU Authentication and Registration..............................................................39
4.4 XGS-PON DBA Feature.................................................................................................... 40
4.5 XGS-PON Ranging Feature.............................................................................................. 41
4.6 XGEM Port Feature...........................................................................................................42
4.7 XGS-PON Data Encryption............................................................................................... 43
4.8 XGS-PON Protection......................................................................................................... 44
5 P2P Access Feature.............................................................................................45
6 L2 Features........................................................................................................... 47
I
6.1 L2 Port Features............................................................................................................... 47
6.1.1 L2 Switch.............................................................................................................. 47
6.1.2 TPID Configuration Over the L2 Port................................................................... 48
6.1.3 L2 Port Access Mode........................................................................................... 49
6.1.4 MAC Address Filtering Over the L2 Port..............................................................50
6.1.5 VLAN Filtering Over the L2 Port.......................................................................... 50
6.1.6 VLAN Tag Conversion Over the L2 Port..............................................................50
6.1.7 VLAN Connect...................................................................................................... 52
6.1.8 PVID Configuration Over the L2 Port...................................................................53
6.1.9 Adding a VLAN Tag to the L2 Port...................................................................... 53
6.1.10 Traffic Mirroring Over the L2 Port...................................................................... 54
6.1.11 Traffic Statistics Over the L2 Port...................................................................... 54
6.2 MAC Address Management.............................................................................................. 55
6.2.1 Permanent MAC Address.....................................................................................55
6.2.2 MAC Learning.......................................................................................................56
6.2.3 MAC Address Aging............................................................................................. 57
6.2.4 Limitation of the Number of MAC Addresses....................................................... 58
6.2.5 MAC Address Query.............................................................................................58
7 IPv4 L3 Features.................................................................................................. 59
7.1 L3 Interfaces......................................................................................................................59
7.2 ARP....................................................................................................................................61
7.3 ARP Proxy......................................................................................................................... 62
7.4 DHCP.................................................................................................................................63
7.5 ICMP.................................................................................................................................. 68
7.6 Route................................................................................................................................. 69
7.7 GRE................................................................................................................................... 74
7.8 ECMP.................................................................................................................................77
7.9 VRF....................................................................................................................................77
8 IPv4 Routing Features......................................................................................... 80
8.1 OSPF................................................................................................................................. 80
8.1.1 OSPF Overview.................................................................................................... 80
8.1.2 Network Types of the OSPF................................................................................ 84
8.1.3 OSPF Route Calculation Process........................................................................ 87
8.1.4 Division of OSPF Areas....................................................................................... 92
8.1.5 External Communication of OSPF Beyond an AS............................................... 99
8.1.6 Other Common Functions of OSPF................................................................... 100
8.2 IS-IS................................................................................................................................. 102
II
8.2.1 IS-IS Overview....................................................................................................103
8.2.2 Establishing an IS-IS Neighbor.......................................................................... 106
8.2.3 IS-IS Link State Database Synchronization........................................................111
8.3 BGP................................................................................................................................. 116
8.3.1 BGP Overview.................................................................................................... 116
8.3.2 Message Types of BGP..................................................................................... 117
8.3.3 BGP Neighbor States and State Transition........................................................118
8.3.4 BGP Route Advertising Rules............................................................................ 119
8.3.5 BGP Route Attributes......................................................................................... 119
8.3.6 BGP Routing Rules............................................................................................ 124
8.3.7 Synchronization Between IBGP and IGP........................................................... 127
8.3.8 MP-BGP.............................................................................................................. 128
9 VXLAN Feature................................................................................................... 129
10 EVPN Feature................................................................................................... 132
11 Multicast Feature..............................................................................................135
11.1 Multicast Description......................................................................................................135
11.2 Multicast Application Scenario.......................................................................................137
11.3 Multicast Principle..........................................................................................................138
12 Synchronization Features............................................................................... 143
12.1 Clock Synchronization................................................................................................... 143
12.2 Synchronous Ethernet................................................................................................... 150
12.3 Time Synchronization.................................................................................................... 151
13 EOAM Features.................................................................................................159
13.1 802.3ah.......................................................................................................................... 159
13.2 802.1ag/Y.1731 (CFM).................................................................................................. 160
13.2.1 ETH-CCM..........................................................................................................162
13.2.2 ETH-RDI............................................................................................................163
13.2.3 ETH-LB............................................................................................................. 163
13.2.4 ETH-LT..............................................................................................................164
13.2.5 ETH-AIS............................................................................................................ 164
14 System Management Features....................................................................... 166
14.1 SSH................................................................................................................................166
14.2 SFTP..............................................................................................................................166
14.3 File System....................................................................................................................167
14.4 User Management......................................................................................................... 168
14.5 Command Privilege Level............................................................................................. 169
14.6 SNMP.............................................................................................................................169
III
15 System Security Features............................................................................... 170
15.1 Anti-DoS Attack............................................................................................................. 170
15.2 Anti-IP/ICMP/TCP Attack...............................................................................................171
15.3 ACL................................................................................................................................ 171
15.4 IP Spoofing Prevention..................................................................................................172
16 MAC Address Security Features.................................................................... 174
16.1 Preventing MAC Address Frauds..................................................................................176
16.2 Static MAC Binding....................................................................................................... 177
16.3 Static MAC Filtering.......................................................................................................178
16.4 Check of the Number of the MAC Addresses...............................................................178
16.5 MAC Address Validity Check........................................................................................ 178
17 Security Features............................................................................................. 180
17.1 RADIUS......................................................................................................................... 180
17.2 TACACS+...................................................................................................................... 182
17.3 DHCP Snooping............................................................................................................ 184
17.4 Port Identification........................................................................................................... 187
18 Networking Protection Features..................................................................... 191
18.1 LACP..............................................................................................................................191
18.2 BFD................................................................................................................................192
18.2.1 BFD Overview...................................................................................................192
18.2.2 BFD Application................................................................................................ 193
18.3 FRR Configuration......................................................................................................... 195
18.3.1 IP FRR.............................................................................................................. 195
18.3.2 Static Route FRR............................................................................................. 198
18.4 OAM Binding................................................................................................................. 199
19 NETCONF Feature............................................................................................ 202
20 ISSU Feature..................................................................................................... 204
21 Energy-Saving Features.................................................................................. 207
22 High Availability Features............................................................................... 209
22.1 Watchdog Monitoring Mechanism................................................................................. 209
22.2 System Exception Monitoring and Log Record............................................................. 211
22.3 System Resource Monitoring........................................................................................ 212
22.4 Internal Communication Verification.............................................................................. 214
22.5 Dual BOOT, Roll-back from Upgrade Failure and NSR................................................ 216
22.6 IP Graceful Restart........................................................................................................217
22.7 NSR............................................................................................................................... 219
22.8 Master/Slave Main Control Handover........................................................................... 221
IV
23 MPLS Features................................................................................................. 222
24 QoS Features.................................................................................................... 228
24.1 QoS Description.............................................................................................................228
24.2 QoS Application Scenario............................................................................................. 228
24.3 QoS Principle.................................................................................................................230
25 IPv6 Features.................................................................................................... 236
25.1 IPv6 Overview............................................................................................................... 236
25.2 IPv6 Address................................................................................................................. 237
25.2.1 Address Classification.......................................................................................239
25.2.2 Address Expression Way................................................................................. 246
25.2.3 IPv6 Address Auto Configuration Technology..................................................248
25.3 NDP............................................................................................................................... 250
25.4 DHCPv6......................................................................................................................... 251
25.5 ICMPv6.......................................................................................................................... 254
Figures.................................................................................................................... 257
Tables......................................................................................................................263
Glossary..................................................................................................................265
V
About This Manual
Purpose
This manual describes the features of the ZXA10 C600/C650/C620.
Intended Audience
This manual is intended for:

 Network management engineers
 Maintenance engineers
What Is in This Manual
This manual contains the following chapters.
Chapter 1, GPON Access Features Describes the GPON access features of ZXA10
C600/C650/C620.
Chapter 2, XG-PON Access Features Describes the XG-PON access features of ZXA10
C600/C650/C620.
Chapter 3, Combo PON Feature Describes the combo PON feature of ZXA10 C600/
C650/C620.
Chapter 4, XGS-PON Access Features Describes the XGS-PON access features of ZXA10
C600/C650/C620.
Chapter 5, P2P Access Feature Describes the P2P access feature of ZXA10 C600/
C650/C620.
Chapter 6, L2 Features Describes the L2 features of ZXA10 C600/C650/C620

.
Chapter 7, IPv4 L3 Features Describes the IPv4 L3 features of ZXA10 C600/C650/

C620.
Chapter 8, IPv4 Routing Features Describes the IPv4 Routing features of ZXA10 C600/
C650/C620.
Chapter 9, VXLAN Feature Describes the VXLAN feature of ZXA10 C600/C650/

C620.
Chapter 10, EVPN Feature Describes the EVPN feature of ZXA10 C600/C650/
C620.
Chapter 11, Multicast Feature Describes the multicast feature of ZXA10 C600/C650/
C620.
Chapter 12, Synchronization Features Describes the synchronization features of ZXA10

C600/C650/C620.
Chapter 13, EOAM Features Describes the EOAM features of ZXA10 C600/C650/
C620.
Chapter 14, System Management Features Describes the system management features of
ZXA10 C600/C650/C620.
Chapter 15, System Security Features Describes the system security features of ZXA10
C600/C650/C620.
Chapter 16, MAC Address Security Features Describes the MAC address security features of
ZXA10 C600/C650/C620.
Chapter 17, Security Features Describes the Security features of ZXA10 C600/
C650/C620.
Chapter 18, Networking Protection Features Describes the networking protection features of
ZXA10 C600/C650/C620.
Chapter 19, NETCONF Feature Describes the NETCONF feature of ZXA10 C600/
C650/C620.
Chapter 20, ISSU Feature Describes the ISSU feature of ZXA10 C600/C650/
C620.
Chapter 21, Energy-Saving Features Describes the energy-saving features of ZXA10

C600/C650/C620.
Chapter 22, High Availability Features Describes the high availability features of ZXA10
C600/C650/C620.
Chapter 23, MPLS Features Describes the MPLS features of ZXA10 C600/C650/
C620.
Chapter 24, QoS Features Describes the QoS features of ZXA10 C600/C650/
C620.
Chapter 25, IPv6 Features Describes the IPv6 features of ZXA10 C600/C650/
C620.
Conventions
This manual uses the following conventions.
Note: provides additional information about a topic.
VII
VIII
Chapter 1
GPON Access Features
Table of Contents
GPON Physical Characteristic..................................................................................................... 1
GPON Optical Layer Features..................................................................................................... 4
GPON ONU Authentication and Registration.............................................................................. 6
GPON DBA Features................................................................................................................. 10
GPON Ranging Features........................................................................................................... 12
GEM Port Features.................................................................................................................... 13
GPON Data Encryption.............................................................................................................. 16
GPON Protection........................................................................................................................17
1.1 GPON Physical Characteristic

Description
As one of PON technologies, the GPON is developed based on a Gigabit PON complying with
the ITU-T G.984.x recommendations. A GPON system consists of OLTs in offices, ONU/ONTs
in clients and ODNs. It uses a point-to-point network architecture, satisfying the high require-
ments of broadband subscribers.
The GPON has the following functions:
 Supports all-round services, such as voice and Ethernet.
 Uses 1490 nm wavelength in downstream transmission, and 1310 nm wavelength in up-
stream transmission.
 Supports multi-rate transmission. The downstream transmission supports 1244.16 Mbit/s,
2488.32 Mbit/s. The upstream transmission supports 155.52 Mbit/s, 622.08 Mbit/s, 1244.16
Mbit/s, and 2488.32 Mbit/s.
 Supports a physical distance of up to 20 km, a logical distance of up to 60 km and a differ-
ential distance of up to 20 km.
 The maximum optical split ratio is 1:128.
 Provides the OAM function.
 Provides a security protection mechanism on the protocol layer in accordance with the fea-
ture that the PON downstream traffic is transmitted through broadcast.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 1

ZXA10 C600/C650/C620 Feature Description
Application Scenario
With the explosion of broadband services, optical fibers are taking the place of copper cables
and operators have proposed higher requirements on transmission distance, bandwidth, relia-
bility and operation costs. The following GPON features satisfy these requirements:
 Further transmission distance: Uses optical transmission with an up to 20 km coverage ra-
dius of the access layer.
 Broader bandwidth: Supports a maximum of 2.5 Gbit/s downstream and a maximum of 1.25
Gbit/s upstream for each user.
 QoS guarantee for full service access. Transmits GEM frames with higher QoS
 Splitting feature: A single-fiber from a central office can be extended to multiple home fibers
after being split, saving fiber resources, decreasing the number of optical-electrical devices
in the office, and reducing the operation and maintenance costs.
Figure 1-1 shows a GPON network.
Figure 1-1 GPON Network
BSC: Base Station Controller RNC: Radio Network Controller
SFU: Single Family Unit HGU: Home Gateway Unit
SBU: Single Business Unit DPU: Distribution Point Unit
OTT: Over The Top BTS: Base Transceiver Station
SS: Soft Switch IMS: IP Multimedia Subsystem
MDU: Multiple Dwelling Unit MTU: Maximum Transmission Unit
EMS: Element Management System BOSS: Business and Operation Support System
2 SJ-20230719162004-003 | 2023-10-30 (R1.0)

1 GPON Access Features
The GPON uses passive optical transmission technologies. It is implemented in the following
networking scenarios: FTTM, FTTO, FTTB, FTTC, and FTTH. The GPON supports the follow-
ing services.
 Voice
 Data
 Video
 Leased line
 Distributed services
Principle
The GPON system resides in the broadband optical access network. It connects to the CN
in the upstream and connects to a customer premises network, implementing the collection,
switching and forwarding of user services.
A GPON system consists of three parts: OLT, ONU and ODN.
 The OLT is an convergence device located at the central office and is the endpoint of a pas-
sive optical network (PON). It acts as not only a switch or a router, but also a platform that
provides multiple services. The OLT provides optical interfaces to passive optical networks,
converges and processes the service traffic from multiple accessing points. As the core
component of a GPON system, the OLT implements the following functions:
à Transmits data to the ONU through multicast.
à Implements service adaptation.
à Initiates and controls the distance measuring process, and records the distance informa-
tion.
à Assigns T-CONT (Transmission Container) upstream bandwidths.
à Implements L2/L3 Ethernet functions.
à Manages ONU through OMCI protocols.
 The ONU/ONT is a user-side unit or terminal, which provides multiple user interfaces. The
OLT and ONU/ONT are connected and intercommunicated through a PON ODN. The ONU/
ONT implements the user accessing functions as follows:
à Selectively receives broadcast data sent by the OLT.
à Implements service adaptation, and multiplexing/demultiplexing.
à Responses to the distance measurement command sent by the OLT and makes some
adjustments.
à Caches user data and transmits the data in the upstream in the T-CONT assigned by the
OLT.
à Implements other Ethernet functions.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 3

 An ODN consists of one or more Passive Optical Splitter (POS), and optical components
such as fibers and other passive optical components. It provides optical transmission media
with high availability for the physical connection between the OLT and the ONU. The ODN
distributes the downstream data and converges the upstream data.
Standard Compliance
 ITU-T G.984.1: general characteristics

It defines the GPON basic features and main protection methods.
 ITU-T G.984.2: Physical Media Dependent (PMD) layer specification
It defines the GPON physical layer parameters, for example, the physical parameters of an
optical module, including transmit optical power, receiving sensitivity, and overloaded optical
power. It also defines optical power budgets in different levels, for example, Class B+, which
is used in most cases.
 ITU-T G.984.3: transmission convergence layer specification
It defines the GPON TC layer specifications including the frame structure of upstream and
downstream and the GPON working principle.
 ITU-T G.984.4: ONT management and control interface specification
It defines the GPON management and maintenance specifications, including OAM, PLOAM
and OMC.
 ITU-T G.984.5: enhancement band
It defines the GPON wavelength planning, which reserves corresponding wave bands for
the next-generation PON.
 ITU-T G.984.6: Reach extension
It describes some Long Reach PON technical solutions to extend the GPON transmission
distance.
 TR-156: Using GPON Access in the context of TR-101
1.2 GPON Optical Layer Features

Description
ITU-T G.984.2 (PMD layer specification) defines GPON physical layer parameters, including
transmit optical power, receiving sensitivity, overloaded optical power and optical power bud-
gets in different levels. In most cases, the Class B+ standard is used. The GPON optical power
in CLASS B+ is 28.5 dB, while the optical power in CLASS C+ is 32 dB under a long transmis-
sion distance.
4 SJ-20230719162004-003 | 2023-10-30 (R1.0)

As a key parameter of PON network and equipment, the optical layer feature is implemented in
various GPON ODN networks and OLT\ONU design, providing important reference for network
optical power design.
Principle
The central wavelength of a GPON downstream channel is 1490 nm, which ranges from 1490
nm to 1500 nm. The central wavelength of a GPON upstream channel is 1310 nm, which
ranges from 1290 nm to 1330 nm.
For the optical power standard and optical mode classes of GPON OLT and ONU, see Table
1-1.
Table 1-1 Optical Power Standard and Optical Mode Class of GPON OLT and ONU
Optical OLT ONU
Mode Transmit Optical Worst Down- Transmit Optical Worst Upstream

Class Power (dBm) Receiv- stream Power (dBm) Receiv- Optical
Minimum Maximum ing Sen- Optical Minimum Maximum ing Sen- Channel
sitivity Channel sitivity Cost (dB)
(dBm) Cost (dB) (dBm)
B+ 1.5 5 –28 0.5 0.5 5 –27 0.5
C+ 3 7 –32 1 0.5 5 –30 0.5
For the optical power budget of combined GPON optical modules, see Table 1-2.
Table 1-2 Optical Power Budget of Combined GPON Optical Modules

Combined Optical Available Optical Power Budget (dB) Maximum Channel Insert Loss (dB)
Module downstream upstream downstream upstream
B+/B+ 28.5 28.5 28 28
C+/C+ 33 32.5 32 32
FEC refers to a coding scheme that encodes the transmission data according to a certain al-
gorithm, and adds extra redundant bits, which can be used by a decoder to detect and correct
transmission errors. Therefore, FEC plays an important role in the physical and optical charac-
teristics of GPON.
 Achieves low data transmission error rate to avoid retransmission.
 Increases link budget to 3 dB –4 dB higher to support higher data rate and longer transmis-
sion distance. Each PON can support more branches.
The ZXA10 C600/C650/C620 GPON system supports the following FEC functions:
SJ-20230719162004-003 | 2023-10-30 (R1.0) 5

 Enables/Disables the FEC function of a single PON port.

 Upstream FEC and downstream FEC.
In the GPON system, RS coding is used to implement FEC. An RS refers to a code based on a
block. It selects a fixed-size data block and adds extra redundancy at the end. FEC decoder us-
es these extra bits to process the data flow, to find errors, to correct errors, and then to obtain
the original data.
The general RS code is RS (255, 239) with the length of 255 bytes including 239 data bytes
and 16 bytes of check fields (Parity).
The original data is reserved when the FEC based on the block is applied. Therefore, even if
the peer end does not support FEC, the original data can be processed by ignoring check bits.
Figure 1-2 shows a downstream frame with FEC codes.
Figure 1-2 Downstream Frame with FEC Codes
Figure 1-3 shows an upstream frame with FEC codes.
Figure 1-3 Upstream Frame with FEC Codes
1.3 GPON ONU Authentication and Registration

Description
GPON OLT uses embedded OAM and PLOAM channels to search ONUs periodically. When it
gets a legal ONU , it allocates a corresponding ONU ID and measures the distance. After it suc-
cessfully measures the distance, it registers the ONU through the PLOAM channel if necessary.
After the successful registration, the OLT configures and manages services through the just es-
tablished OMCI management channel.
The ONU authentication and registration of the ZXA10 ZXA10 C600/C650/C620 GPON system
has the following features:
 Supports the registration mode based on the ONU serial number.
6 SJ-20230719162004-003 | 2023-10-30 (R1.0)

 Supports the registration mode based on the ONU password.

 Supports the registration mode based on the ONU serial number + ONU password.
 Supports the registration mode based on the logic ID.
 Supports to configure the ONU discovery period.
 Supports to configure automatic ONU discovery and registration mode. When the OLT
searches an unconfigured ONU, it uses the ONU serial number to automatically register the
ONU.
 Supports the ONU password authentication in the mode of the ONU serial number registra-
tion.
This feature is used to access and control the ONU.
Principle
Figure 1-4 shows the registration and authentication process of the GPON ONU.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 7

Figure 1-4 GPON ONU Registration and Authentication
The registration and authentication process is as follows:

1. The OLT sends a downstream GTC frame every 125 us.
8 SJ-20230719162004-003 | 2023-10-30 (R1.0)

2. After receiving the downstream GTC frame, the ONU clears the local LOS/LOF, and the
state is changed from O1 to O2.
3. The OLT sends a downstream Upstream_Overhead PLOAM message. This message de-
fines the preamble, delimiter, and equalization delay of the upstream frame.
4. After receiving the Upstream_Overhead PLOAM message, the ONU sets the preamble, de-
limiter, and equalization delay of the upstream frame according to the message content, and
the state is changed from O2 to O3.
5. The OLT sends a downstream Extended_Burst_Length PLOAM message. This message
defines the preamble length of the upstream frame during distance measurement and nor-
mal operation. During distance measurement, the preamble is longer, which helps the OLT
to capture the ONU upstream frames.
6. After receiving the Extended_Burst_Length PLOAM message, the ONU sets the preamble
length of the upstream frame during distance measurement and normal operation according
to the message content.
7. The OLT uses the BWMap field of the downstream GTC frame to open a public quiet win-
dow. All the unregistered ONUs can send their serial numbers to the OLT through this quiet
window.
8. The ONU sends its serial number to the OLT in the Serial_Number_ONU PLOAM message.
9. After receiving the ONU serial number, the OLT assigns an ONU-ID to the ONU through the
Assign_ONU_ID PLOAM message.
10. The ONU receives the Assign_ONU_IDPLOAM message, and the state is changed from O3
to O4.
11. The OLT uses the BWMap field of the downstream GTC frame to open an upstream quiet
window for the ONU-ID. The ONU sends its serial number to the OLT through the quiet win-
dow.
12. The ONU sends its serial number to the OLT through the Serial_Number_ONUPLOAM mes-
sage.
13. After receiving the ONU serial number, the OLT calculates the ONU distance and equaliza-
tion delay, and sends the equalization delay to the ONU through the Ranging_Time PLOAM
message.
14. After receiving the Ranging_Time PLOAM message, the ONU sets its equalization delay,
and the state is changed from O4 to O5.
15. If the ONU authentication is required, the OLT delivers the Request_password PLOAM mes-
sage, requesting the ONU to report the password.
16. The ONU sends its password to the OLT through the Password PLOAM message.
17. The ONU password is verified, The OLT delivers the Confgure Port-IDPLOAM message and
configures the ONU OMCI management channel.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 9

18. The ONU sets the OMCI management channel, through which the OLT can perform config-
uration and management of ONU services.
1.4 GPON DBA Features

Description
The DBA function in GPON refers to a process that the OLT dynamically allocates upstream
transmission time slots for the ONU according to the transmit buffer occupancy ratio. The
ZXA10 C600/C650/C620 GPON system supports the following features:
 Supports SR (Status Report)-DBA and TM-DBA.
 Supports the configuration of the fixed bandwidth, guaranteed bandwidth and maximum
bandwidth for each T-CONT.
 The bandwidth granularity is 64 kbit/s.
 Supports the maximum bandwidth of 1244 Mbit/s of one PON port.
This feature is used to dynamically allocate the GPON upstream bandwidth.
Principle
In GPON , T-CONT is the minimum scheduling unit for upstream bandwidth allocation. Band-
width authority is correlated with only one T-CONT. Regardless the count of buffer on one T-
CONT, the OLT DBA algorithm considers the T-CONT as a container containing only one log-
ical buffer. According to the logical buffer occupation on each T-CONT, DBA allocates specific
upstream bandwidth for the T-CONT. The bandwidth information is sent to the ONU through the
BWmap field of the downstream frame. After receiving the bandwidth information, the ONU allo-
cates the bandwidth to the queues on the T-CONT.
The DBA in the GPON has the following functions:
 Obtains the occupancy condition of the T-CONT logical buffer.
 Calculates the current upstream bandwidth value allocated to the T-CONT according to the
T-CONT buffer occupancy condition and configured bandwidth parameters.
 Builds the BWmap field for the downstream frame according to the calculated upstream
bandwidth value and stores the BWmap field in the BWmap table.
 Transmits the content of the BWmap table in turn in each downstream frame to implement
dynamic management of the upstream traffic.
The OLT sets the queue scheduling policy on the ONU T-CONT through the management
channel, see Figure 1-5.
10 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Figure 1-5 Queue Scheduling Policy Set by the OLT
The OLT obtains the occupancy condition of the T-CONT logical buffer through two the follow-
ing two methods:
 The OLT continuously test the upstream traffic of a T-CONT, and speculate the current oc-
cupancy condition of the T-CONT logical buffer according to the fluctuation condition, to allo-
cate corresponding bandwidth for it. The DBA applying this method is known as TM-DBA.
 The OLT can require the ONU report the current occupancy condition of each T-CONT log-
ical buffer to allocate corresponding bandwidth. The DBA applying this method is known as
SR-DBA.
The GPON DBA supports the five bandwidth types as follows:
 Fixed bandwidth
After the T-CONT is activated, the OLT allocates bandwidth to it regardless the buffer occu-
pation and upstream loading of the T-CONT.
 Assured bandwidth
The bandwidth requirements of the T-CONT should be fulfilled. If the required bandwidth is
less than the assured bandwidth, the extra bandwidth can be used by other T-CONTs.
 Non-Assured bandwidth
The bandwidth requirements of the T-CONT need not be fulfilled. The non-assured band-
width is allocated only after all fixed bandwidth and assured bandwidth are allocated.
 Best-Effort bandwidth
SJ-20230719162004-003 | 2023-10-30 (R1.0) 11

This bandwidth is of the lowest priority. It is allocated after the fixed bandwidth, assured
bandwidth, and non-assured bandwidth are allocated.
 Maximum bandwidth
Regardless the actual upstream traffic on the T-CONT, the allocated bandwidth cannot ex-
ceed the maximum bandwidth.
1.5 GPON Ranging Features

Description
The GPON system uses a point-to-multipoint architecture, where one OLT connects with multi-
ple ONUs. Normally, the physical distances between the OLT and each ONU are different. Al-
though each ONU transmits data with the allocated bandwidth in the upstream direction, multi-
ple ONUs may conflict in upstream transmission.
Ranging measures and equalizes the logical distances between the OLT and the ONUs to
avoid such conflicts.
Ranging is used to measure the logical distance and delay in upstream TDMA resources
scheduling in the PON system.
Principle
The logical distances between different ONUs and the OLT are different. The RTD of the OLT
and ONUs varies with time and environment. Therefore, when the ONUs transmit upstream sig-
nals in TDMA mode, namely, only one of the ONUs under a PON port of the OLT transmits data
at a time, conflicts may occur, see Figure 1-6.
Figure 1-6 Signal Transmission Without Ranging
To avoid such conflicts, the ranging function is enabled when the ONU is registered for the first
time. By measuring the loop delay between each ONU and the OLT and inserting an equaliza-
tion delay (Td value), all logical distances between all ONUs and the OLT are equalized and
then upstream signals do not conflict, see Figure 1-7.
12 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Figure 1-7 Signal Transmission With Ranging
Note
During ranging, the OLT needs a quiet zone and pauses the upstream channels of other ONUs.
1.6 GEM Port Features

Description
The GEM frame is the minimum service bearing unit of the GPON technology. It is the most
fundamental data structure. All the services are encapsulated in the GEM frame, transmitted
over a GPON line and identified through a GEM port. Each GEM Port is identified with a unique
Port ID that is globally allocated by an OLT, namely, each ONU can only use a GEM Port with
the unique port ID. A GEM Port identifies a virtual service channel between the OLT and ONU,
namely, a channel that bears the service traffic and is similar to the VPI/VCI in an ATM virtual
circuit connection.
The Transmission CONTainer (T-CONT) bears the upstream GPON services. All the GEM
ports are mapped to the T-CONT and scheduled through the DBA scheduling by the OLT. The
T-CONT is a most basic control unit in the GPON upstream services. Each T-CONT is unique-
ly identified with an Alloc-ID that is globally allocated by the OLT, namely, each ONU of the OLT
can only use a T-CONT with the unique Alloc-ID.
The T-CONT includes five types, see Figure 1-8.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 13

Figure 1-8 GPON T-CONT Types
During the upstream service scheduling, different T-CONT types are selected according to dif-
ferent service types. Each type of T-CONT has specific QoS features. The QoS features are re-
flected in bandwidth, including fixed bandwidth, guaranteed bandwidth, guaranteed/maximum
bandwidth, maximum bandwidth and hybrid modes.
This feature is applicable to the scenarios of service traffic identification and QoS scheduling in
the GPON system.
Principle
The GEM Port and T-CONT works together to divide the PON into virtual connections, imple-
menting service multiplexing.Figure 1-9 shows the principle of service multiplexing.
Figure 1-9 GPON Service Multiplexing Principle
A GEM Port can bear services in one or more types. The services born on the GEM port are
mapped to the T-CONT unit for upstream service scheduling. Each ONU supports multiple T-
CONTs and can be configured with different service types.
14 SJ-20230719162004-003 | 2023-10-30 (R1.0)

A T-CONT can bear one or more GEM Ports based on the specific configurations of users. Af-
ter the T-CONT is transmitted to the OLT, the GEM Port is demodulated first, and then the ser-
vice payload is demodulated for corresponding service processing.
The service mapping relationship is as follows:
 Downstream: All the services in the GPON service processing unit are encapsulated in the
GEM Port and broadcast to all the ONUs under this GPON interface. The ONU filters data
according to the GEM Port ID and only keeps the GEM Port that belongs to this ONU. The
ONU decapsulated the services of this GEM Port and then sent them to the user equipment
through the ONU service interface, see Figure 1-10.
Figure 1-10 GPON Service Mapping Relationship (Downstream)
 Upstream: All services are mapped to different GEM Ports in the ONU. The GEM Port with
services are mapped to T-CONT in different types and then transmitted to the OLT. The T-
CONT demodulates the GEM Ports in the OLT and sends them into a GPON MAC chip that
demodulates the services in the GEM Port payload. The demodulated services are sent to
the corresponding service processing units for subsequent processes, see Figure 1-11.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 15

Figure 1-11 GPON Service Mapping Relationship (Upstream)
1.7 GPON Data Encryption

Description
The PON is a point-to-multipoint system, in which the downstream data encryption can protect
the data sent to the ONU from being snooped by other ONUs, ensuring user data security. The
ZXA10 C600/C650/C620 system supports an AES128 encryption algorithm that supports to
AES encryption on each single GEM Port.
The GPON data encryption is to encrypt the downstream service data.
Principle
In a PON system, the downstream data is broadcast to all ONU s on the PON. If some mali-
cious user reprograms the ONU, he can listen to the downstream data of all the users. This
is the snooping threat that security system may encounter. To solve this problem, encrypt the
downstream data to ensure the security of users' data. The ONU generates the key and trans-
mits it upward. To avoid deciphering of the key, the system should change the key periodically.
Figure 1-12 shows the AES encryption procedure of the PON.
16 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Figure 1-12 PON AES Encryption
The detailed procedures are as follows:

1. The OLT delivers a Request_Key PLOAM message requesting the ONU to report an new
key.
2. The ONU transmits the new key to the OLT through a Encryption_Key PLOAM message.
3. The OLT saves the new key locally and delivers a Key_Switching_Time PLOAM message to
inform the ONU of the activation time of the new key.
4. The ONU configures the activation time of the new key and transmits a confirmation mes-
sage to the OLT through the Acknowledge message PLOAM .
5. At the activation time of the new key, the OLT encrypts the downstream data with the new
key, then delivers it to the ONU.
6. The ONU uses the new key to decipher the downstream data to obtain effective data.
1.8 GPON Protection

The ZXA10 C600/C650/C620 xPON PON interface protection switchover has the following two
methods:
 Automatic switchover: It is triggered by a fault such as signal loss or signal deterioration.
 Forced switchover: It is triggered by a management event.
All the protection switchover mechanisms of the ZXA10 C600/C650/C620 xPON system sup-
ports the automatic or manual return of the protected services. In the automatic return, if the
SJ-20230719162004-003 | 2023-10-30 (R1.0) 17

fault that triggers the switchover is cleared, after a waiting period (WTR) the protected service is
returned to the original route. The ZXA10 C600/C650/C620 GPON supports the protections in
TYPE B and TYPE C.
In the xPON system, if any of the following conditions occurs on the PON interface that is ap-
plied with the protection Type B/C, the PON interface switchover must be performed.
 Loss of signals.
 Input signal deterioration.
à The power of the input optical signal is too high or too low.
à The BER exceeds its threshold.
 The board is unplugged.
1.8.1 ITU-T Type B Protection Feature

Description
The ZXA10 C600/C650/C620 xPON provides dual fibers and dual PON ports that connect to
downstream user equipment, preventing service interruption caused by a single link, improving
system reliability and ensuring uninterrupted services.
This feature is used for GPON Type B protections.
Principle
GPON Type B protection: The two PON ports of an OLT uses independent PON MAC chips
and optical modules, implementing protections of two PON ports, see Figure 1-13.
Figure 1-13 GPON Type B Protection (An OLT PON Port Is Redundant)
 OLT: The standby PON port of the OLT is in cold standby status. The OLT detects the link
protection and PON port status, and then performs switchover. The OLT must ensure that
the active PON port can synchronize the service information with the standby PON port,
18 SJ-20230719162004-003 | 2023-10-30 (R1.0)

thus the standby PON port can keep the service attributes of the ONU unchanged during the
switchover process.
 Optical splitter: A 2:N optical splitter is used.
 ONU: There is no special requirement on the ONU.
1.8.2 ITU-T Type C Protection Feature

Description
The ZXA10 C600/C650/C620 xPON provides dual fibers and dual PON ports that connect to
downstream user equipment, preventing service interruption caused by a single link, improving
system reliability and ensuring uninterrupted services.
This feature is used for GPON Type C protections.
Principle
GPON Type C protection: Both of the dual PON ports of the OLT, the dual optical modules of
the ONU, backbone optical fibers, optical splitters and auxiliary fibers use dual-redundant pro-
tections, see Figure 1-14.
Figure 1-14 GPON Type C Protection (Whole Protection)
 OLT: The standby PON port of the OLT is in cold standby status. The OLT must ensure that
the active PON port can synchronize the service information with the standby PON port,
thus the standby PON port can keep the service attributes of the ONU unchanged during the
switchover process.
 Optical splitter: Two 1:N optical splitters are used.
 ONU: The ONU uses a PON MAC and different optical modules. The standby optical
module is in cold standby status. Both of the ONU and OLT detect link status and decide
whether to perform switchover according to the link status.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 19

1.8.3 Inter-OLT Protection Feature

Description
In the dual-homing scenarios, the two PON lines between the ONU and the OLT are in active
and standby status, which cannot deliver messages at the same time. When the active line
is interrupted due to an optical fault or device failure, the ONU can be quickly switched to the
standby OLT, achieving an inter-OLT protection.
This feature is applicable to the scenarios of inter-OLT protections.
Principle
Figure 1-15 shows the principle of an inter-GPON OLT Type C protection.
Figure 1-15 GPON Inter-OLT Type C Protection
The PON port in OLT1 is work, and the PON port in OLT2 is protect. The link between the ONU
and the work port of OLT 1 is a work link, and the link between the ONU and the protect port of
OLT 2 is a protect link.
20 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Simply, OLT 1 is called the work OLT, and OLT 2 is called the protect OLT. The PON port con-
nected to the work port of OLT 1 of the ONU is also called the work port, and PON port con-
nected to the protect port of OLT 2 of the ONU is also called the protect port.
The working status of each device during the protection is described as follows:
 OLT: Both of the work OLT and protect OLT are in working status. Configure the work OLT
and protect OLT manually to ensure that the service information of the work OLT is the
same as that of the protect OLT, thus the protect OLT can keep the service attributes of the
ONU unchanged during the switchover process.
 Optical splitter: Two 1:N optical splitters are used.
 ONU: The ONU uses different PON MAC chips, namely, the PON ports connected to the
OLT are located on the different chips. The ONU keeps the service information of the work
port the same as that of the protect port, thus the ONU can keep the local service attributes
unchanged during the switchover over the PON port.
The principle of an inter-GPON OLT Type C protection is described as follows:
1. Both of the work OLT and the protect OLT are in working status (the ONU completes the
PLOAM registration on two OLTs at the same time, and implements the processing of basic
and extended OMCI messages). During the OLT switchover, the protect OLT does not need
ONU initial configurations and service attributes configurations.
2. Both of the ONU and OLT detect link status and decide whether to perform switchover ac-
cording to the link status.
 If the work OLT detects an upstream link fault on the PON port, it informs the ONU
about the upstream fault through an extended OMCI message. The ONU performs the
switchover, informs the work OLT about the switchover through an OMCI AVC message
and then informs the protect OLT about the switchover through a PST message.
 If the protect OLT detects an upstream link fault on the PON port, it negotiates with the
ONU about the switchover through a PST message.
 If the ONU detects a downstream link fault on the work port, the ONU automatically
switches to the protect link and sends a PST message to the protect OLT, to inform the
PON port of the ONU about the executed switchover and the corresponding switchover
reason, requesting a new switchover. After the switchover succeeds, the ONU sends an
OMCI AVC message to the work OLT and informs the work OLT about the switchover.
3. The ONU can be automatically switched back to the work OLT after the switchover. The
OLT sends the switch that controls the automatic switchover and the switching back time to
the ONU. When the ONU detects that both of the work port, work link and the upper-layer
link of the work OLT have no any fault, and the work link is in standby status, if the work sta-
tus keeps the stable status within the recovery time, the ONU automatically switches to the
work link after the recovery time arrives.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 21

If any of the following conditions occurs, the OLT and ONU in the protection group must per-
form the optical link switchover.
 Forced switchover.
 Automatic switchover.
à Loss of signals.
à The ONU is in registration.
à The OLT upstream link is faulty.
à The OLT or ONU hardware is faulty.
22 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Chapter 2
XG-PON Access Features
Table of Contents
XG-PON Physical Characteristic................................................................................................23
XG-PON Optical Layer Feature................................................................................................. 25
XG-PON ONU Authentication and Registration......................................................................... 26
XG-PON DBA Feature............................................................................................................... 27
XG-PON Ranging Feature......................................................................................................... 28
XGEM Port Feature....................................................................................................................29
XG-PON Data Encryption.......................................................................................................... 31
XG-PON Protection.................................................................................................................... 31
2.1 XG-PON Physical Characteristic

Description
XG-PON is the next generation evolution of GPON. The XG-PON downstream rate is 9.95328
Gbit/s, which is four times that of the GPON downstream rate. The XG-PON upstream rate is
2.48832 Gbit/s, which is two times that of the GPON upstream rate. The XG-PON upstream
and downstream lines use NRZ for decoding.
The XG-PON application scenario is similar to that of GPON. XG-PON is mainly used for three
types of users: BTS users, commercial users, and residential users.
 For BTS users, XG-PON is used for FTTCell. The ONU type is CBU that provides BTS
backhaul services. The CBU must support IEEE 1588 and Synchronous Ethernet.
 For commercial users, XG-PON is used for FTTB and FTTO. The ONU type contains the
MTU and SBU, which transmit commercial data, E1 services, commercial video and voice
conferences.
 For residential users, XG-PON is used for FTTH, FTTB and FTTC. The ONU type contains
the SFU, MDU of a LAN interface and MDU of an xDSL interface, which provide high-speed
Ethernet services, voice and video services.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 23

Principle
The XG-PON supports extended range through a Reach Extender (RE). The XG-PON also
supports coexistence with GPON and RF video through WDM1r.Table 2-1 shows the compari-
son of XG-PON and GPON.
Table 2-1 XG-PON and GPON

Item GPON XG-PON
Standard G.984 G.987
Rate Downstream: 2.5 Gbit/s Downstream: 10 Gbit/s
Upstream: 1.25 Gbit/s Upstream: 2.5 Gbit/s
Splitting ratio 0.1305556 0.3972222
Line code NRZ NRZ
Wave length Downstream: 1480 nm - 1500 nm Downstream: 1575 nm - 1580 nm
Upstream: 1290 nm - 1330 nm Upstream: 1260 nm - 1280 nm

(narrowed)
Furthest range/Differential range 20 km/20 km 40 km/40 km
Furthest logical range/Logical dif- 60 km/20 km 60 km/40 km

ferential range
Data encapsulation GEM encapsulation XGEM encapsulation
FEC RS (255, 239) Downstream RS (248, 216)
Upstream RS (248, 232)
Encryption Downstream AES Encryption Upstream and downstream AES

Encryption
Multicast encryption Not Support Supported
OMCI Fixed length Fixed length and variable length
Standard Compliance
XG-PON specifications consist of five modules including G.987 series and G.988 series. They
are called XG-PON series specifications.
 G.987: 10-Gigabit-capable passive optical network (XG-PON) systems: Definitions, Abbrevi-
ations, and Acronyms.
It is a family that defines this access network standard including terms and definitions used
in XG-PON standards.
 G.987.1: General requirements of XG-PON systems
24 SJ-20230719162004-003 | 2023-10-30 (R1.0)

2 XG-PON Access Features
It defines the services, evolution policies and fundamental technical capabilities requested
by the XG-PON.
 G.987.2: Physical media dependent (PMD) layer specification
It defines the detailed technical specifications of the XG-PON physical layer, including rate,
clock, optical interface data and interfaces.
 G.987.3: Transmission convergence (TC) specifications
It defines the technologies and messages of the XG-PON transmission layer, including data
encapsulation, channel management, messages transmission mechanism, security, energy
saving and alarm.
 G.988: ONU management and control interface (OMCI) specification
Based on G.984.4, it defines management and control interface for administering optical
network units. It added adaptive definitions for some new functions, correct and modify
some errors in G.984.4.
2.2 XG-PON Optical Layer Feature

Description
ITU-T G.987.2 (Physical Media Dependent (PMD) layer specification) defines XG-PON physical
layer parameters, including transmit optical power, receiving sensitivity, overloaded optical pow-
er and optical power budgets in different levels.
various XG-PON ODN networks and OLT/ONU design, providing important reference for net-
work optical power design.
Principle
For a description of the XG-PON optical power budget levels, refer to Table 2-2.
Table 2-2 XG-PON Optical Power Budget level

Item "Nominal1" class "Nominal2" class "Extended1" class "Extended2" class
(N1 class) (N2 class) (E1 class) (E2 class)
Minimum loss 14 dB 16 dB 18 dB 20 dB
Maximum loss 29 dB 31 dB 33 dB 35 dB
XG-PON downstream wave length is 1575 nm - 1580 nm, and upstream wave length is 1260
nm - 1280 nm, see Figure 2-1.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 25

Figure 2-1 XG-PON, GPON and RF Video Wave Length Allocation
For a description of the XG-PON ODN physical parameters, refer to Table 2-3.
Table 2-3 XG-PON ODN Physical Parameters

Item Unit Technical Specification
Optical fiber type (refer to Clause – [ITU-T G.652], or compatible

9.2.3.1)
Attenuation range (refer to Clause dB N1 class: 14–29

4.1)
N2 class: 16–31
E1 class: 18–33
E2 class: 20–35
The maximum optical fiber range km DD20: 20

between points S/R and R/S. DD40: 40
The minimum optical fiber range km 0

between points S/R and R/S.
Bidirectional transmission – Single optical fiber WDM
Maintenance wave length nm Refer to ITU-T L.66.
2.3 XG-PON ONU Authentication and Registration

Description
XG-PON OLT uses embedded OAM and PLOAM channels to search ONUs periodically. When
the XG-PON OLT gets a legal ONU, it allocates the corresponding ONU ID and measures the
distance. After the XG-PON OLT successfully measures the distance, it registers the ONU
through the PLOAM channel if necessary. After the successful registration, the XG-PON OLT
configures and manages services through the just established OMCI management channel.
26 SJ-20230719162004-003 | 2023-10-30 (R1.0)

This feature is used to access and control the XG-PON ONU.
Principle
The XG-PON ONU authentication and registration process is similar to GPON, refer to 1.3
GPON ONU Authentication and Registration.
2.4 XG-PON DBA Feature

Description
The DBA function in XG-PON refers to a process that the OLT dynamically allocates upstream
transmission time slots for the ONU according to the transmit buffer occupancy ratio.
This feature is used to dynamically allocate the XG-PON upstream bandwidth.
Principle
XG-PON DBA is an upstream bandwidth allocation process. The OLT dynamically allocates up-
stream bandwidth to the T-CONT of each ONU. The ONU transmits upstream services in the
upstream bandwidth allocated to the T-CONT, see Figure 2-2.
Figure 2-2 XG-PON DBA
SJ-20230719162004-003 | 2023-10-30 (R1.0) 27

The OLT allocates bandwidth according to ONU T-CONT configurations and dynamic indication
(such as DBRu and idle XGEM frame). The DBA calculation result is sent to the ONU through
BWmap.
2.5 XG-PON Ranging Feature

Description
The XG-PON has a point-to-multipoint architecture. An OLT connects to multiple ONUs. Nor-
mally, the physical distances between the OLT and each ONU are different. Although each
ONU transmits data with the allocated bandwidth in the upstream direction, similar to the GPON
ranging feature, multiple ONUs may conflict in upstream transmission.
scheduling in the XG-PON system.
Principle
Figure 2-3 shows the principle of XG-PON ranging.
28 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Figure 2-3 XG-PON Ranging
The furthest ONUR is obtained through ranging. According to the logical distance of ONUR,
other ONUis are allocated to an Equalization Delay. The ONUi waits for an Equalization Delay
when responding to the bandwidth allocation from the OLT.
The logical distance between the OLT and all ONUs is the same as that between the ONUR
and OLT, namely, all ONUs are identically far away from the OLT. Each ONU transmits up-
stream data in the allocated bandwidth, avoiding conflicts with other ONUs.
2.6 XGEM Port Feature

Description
Similar to GPON, each GEM Port of the XG-PON system is identified with an unique Port ID,
which is allocated by the OLT according to the XG-PON port. A GEM Port identifies a virtual
service channel between the OLT and ONU.
The Transmission Container (T-CONT) is a most basic control unit in the XG-PON upstream
services. Each T-CONT is uniquely identified with an Alloc-ID that is globally allocated by the
OLT, namely, each ONU of the OLT can only use a T-CONT with the unique Alloc-ID. Every
GEM port is mapped to the T-CONT and scheduled through the DBA scheduling by the OLT.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 29

the XG-PON system.
Principle
The GEM Port and T-CONT works together to divide the PON into virtual connections, imple-
menting service multiplexing.
A GEM Port can bear services in one or more types. The services born on the GEM port are
A T-CONT can bear one or more GEM Ports based on the specific configurations of users. Af-
ter the T-CONT is transmitted to the OLT, the GEM Port is demodulated first, and then the ser-
vice payload is demodulated for corresponding service processing.
The XGEM frame is the minimum service bearing unit of the XG-PON technology. It is the most
fundamental data structure. All services are encapsulated in the XGEM frame and then trans-
mitted. An XGEM frame consists of an XGEM frame header with fixed length (eight bytes) and
XGEM payload with variable length, including PLI (indicates the payload length) and Key Index
(indicates which secret key is used for encryption). Figure 2-4 shows the XGEM frame struc-
ture.
Figure 2-4 XG-PON XGEM Frame Structure
An XGTC payload consists of one or more XGEM frames, see Figure 2-5.
30 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Figure 2-5 XG-PON XGTC Payload Format
2.7 XG-PON Data Encryption

Description
The XG-PON is a point-to-multipoint system, in which the upstream and downstream data en-
cryption can protect the data sent to the ONU from being snooped on by other ONUs, ensur-
ing user data security. The XG-PON encryption is similar to GPON. The difference is that the
GPON only supports the encryption to the downstream data.
The XG-PON data encryption is to encrypt the upstream and downstream service data.
Principle
Similar to GPON, the XG-PON system supports an AES encryption algorithm that supports
AES encryption on each single XGEM Port. In an XG-PON system, both of the upstream and
downstream unicast XGEM frame payload can be encrypted. The downstream multicast XGEM
frame can also be encrypted, improving user data security. The ONU generates the key and
transmits it upward. To avoid deciphering of the key, the XG-PON system should changes the
key periodically.
2.8 XG-PON Protection

Similar to GPON, the XG-PON supports Type B and Type C switchover, refer to 1.8 GPON Pro-
tection.The XG-PON downstream frame carries a PON-ID field, which is used for implementing
switchover.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 31

Chapter 3
Combo PON Feature
Description
The GPON and XG-PON can operate together in an ODN through an external WDM1r devic.
The GPON and XG-PON operate together based on WDM. The uplink/downlink GPON wave-
length and XG-PON wavelength are completely separated, and the four types of wavelength
coexist in an ODN without interfering with each other. The WDM1r is an optical multiplexer that
combines the downlink wavelength of a GPON port and that of an XG-PON port into one opti-
cal fiber for transmission and separates the GPON and XG-PON uplink wavelengths in an op-
tical fiber onto GPON and XG-PON ports. The WDM1r results in an insertion loss of about 1.5
dB. The optical modules of GPON and XG-PONONTs need to comply with ITU-T G.984.5. Par-
ticularly, a WBF module is required in each optical module. For each GPON optical module, the
WBF module filters out XG-PON and RF wavelengths. For each XG-PON optical module, the
WBF module filters out GPON and RF wavelengths.
Application Scenarios
In the external optical multiplexer solution, OLT shelves, racks, XG-PON cards, external optical
multiplexers, fiber jumpers, and ODFs are required, resulting in high costs and space usage. It
is also difficult and complicated to deploy, operate, and maintain these devices and connect ca-
bles for them. In addition, the optical power loss caused by external optical multiplexers affects
the optical power budget of existing ONUs, bringing a risk of reducing user experience.
To address these issues, ZTE puts forward the combo PON solution creatively. In the combo
PON solution, high-bandwidth services can be upgraded smoothly by only replacing line cards.
Compared with the external optical multiplexer solution, the combo PON solution has the follow-
ing advantages:
 Space Saving and Easy O&M
In the combo PON solution, no additional device is required. The space of the equipment
room can be largely saved for upgrade of a fully-configured GPON. For example, if a rack
is fully configured with two GPON OLTs and upgrade to 10G GPON OLTs is required, the
combo PON solution can save more than 60% of the space in the equipment room. No ad-
32 SJ-20230719162004-003 | 2023-10-30 (R1.0)

3 Combo PON Feature
ditional device is added, so it does not bring more O&M issues, thus saving the CAPEX and
OPEX for the carrier.
 Smooth Network Upgrade Without any Effect on the Existing GPON Services
With large-scale deployment of GPON services, the optical power budgets in some areas or
of some users may be insufficient. If the external optical multiplexer solution is used, an in-
sertion loss of 1.5 dB will be caused, which may result in failure of the existing GPONONU
s, thus affecting existing services. The combo PON solution amplifies optical power to com-
pensate for the optical power loss after multiplexing is implemented inside optical modules,
ensuring that the GPON and 10G GPON optical power budgets are not changed and exist-
ing services are not affected.
 Deployment Cost Reduction
The combo PON solution can reduce the deployment cost. By analyzing the deployment
cost and device space usage cost of a carrier within a five-year life cycle, it is found that the
combo PON solution can save 24% more expenses than the external optical multiplexer so-
lution.
 Reducing the Initial Investment Cost and Improving Profits
Compared with GPONONUs, 10G GPONONUs have higher costs. The combo PON so-
lution can upgrade the existing ONUs in accordance with the bandwidth increase require-
ments and business growth needs, to reduce the high costs caused by full configuration of
10G PON ONUs.
The combo PON solution can flexibly satisfy the high-bandwidth service requirements, thus im-
proving user experience and the carrier's competitiveness, create more value and increase the
profit for the carrier.
Implementation Principle
Figure 3-1 shows the implementation principle of the combo PON solution.
Figure 3-1 GPON and XG-PON Coexistence Through the Combo PON
The combo PON solution multiplexes GPON and XG-PON optical wavelength channels in an
optical module onto a single output optical port. For XG-PON upgrade, the carrier only needs
SJ-20230719162004-003 | 2023-10-30 (R1.0) 33

to replace the GPON line cards in OLTs with combo PON line cards and cut the optical fibers
on the original GPON line cards over to the combo PON line cards, so that the GPON and XG-
PON can operate together.
The key techniques used in the combo PON solution include the following:
 Multimode MAC: The PON MAC chip on the OLT side supports both GPON and XG-PON
MAC processing on a PON port.
 Optical module integration: The GPON and XG-PON optical modules and WDM1r are inte-
grated into a combo PON optical module.
A combo PON port integrates both XG-PON and GPON ports, and uses one optical fiber link,
which corresponds to two physical channels. The processing mechanism is described as fol-
lows:
 The two MAC chips separately process downlink signals and send them to the combo PON
optical module on the OLT side for multiplexing. The multiplexed signals are sent to the
ONUs. The XG-PON ONU receives XG-PON signals and the GPON ONU receives GPON
signals.
 The uplink GPON and XG-PON signals use different wavelengths and are demultiplexed in-
side the optical module on the OLT side. The demultiplexed signals are then sent to different
MAC channels.
Therefore, a combo PON port includes a GPON channel and an XG-PON channel. The GPON
channel has the functions described in 1 GPON Access Features and the XG-PON channel has
the functions described in 2 XG-PON Access Features.
34 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Chapter 4
XGS-PON Access Fea-
tures
Table of Contents
XGS-PON Physical Characteristic............................................................................................. 35
XGS-PON Optical Layer Feature............................................................................................... 38
XGS-PON ONU Authentication and Registration...................................................................... 39
XGS-PON DBA Feature............................................................................................................. 40
XGS-PON Ranging Feature....................................................................................................... 41
XGEM Port Feature....................................................................................................................42
XGS-PON Data Encryption........................................................................................................ 43
XGS-PON Protection..................................................................................................................44
4.1 XGS-PON Physical Characteristic

Description
XGS-PON is the next generation evolution of GPON. The XGS-PON downstream rate is
9.95328 Gbit/s, which is four times that of the GPON downstream rate. The XGS-PON up-
stream rate is 9.95328 Gbit/s, which is eight times that of the GPON upstream rate. The XGS-
PON upstream and downstream lines use NRZ for decoding.
The XGS-PON application scenario is similar to that of GPON. XGS-PON is mainly used for
three types of users: BTS users, commercial users, and residential users.
 For BTS users, XGS-PON is used for FTTCell. The ONU type is CBU that provides BTS
backhaul services. The CBU must support IEEE 1588 and Synchronous Ethernet.
 For commercial users, XGS-PON is used for FTTB and FTTO. The ONU type contains the
MTU and SBU, which transmit commercial data, E1 services, commercial video and voice
conferences.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 35

 For residential users, XGS-PON is used for FTTH, FTTdp, FTTB and FTTC. The ONU type
contains the SFU, MDU of a LAN interface and MDU of an DSL/G.fast interface, which pro-
vide high-speed Ethernet services, voice and video services.
Figure 4-1 shows a XGS-PON network.
Figure 4-1 XGS-PON Network
Principle
The OLT XGS-PON ports support the coexistence of XGS-PON ONUs and XG-PON ONUs by
using the TDMA technology on both upstream and downstream directions. The XGS-PON ports
support burst receive of dual rates, that is, the burst receive of 9.953 Gbit/s and burst receive
of 2.488 Gbits/s, which satisfies the requirements of different application scenarios. An XGS-
PON port supports both access of commercial users requiring symmetric bandwidths and family
users requiring asymmetric bandwidths, which saves the investment on the terminal devices.
The XGS-PON supports coexistence with GPON and RF video through WDM1r.Table 4-1
shows the comparison of XGS-PON, XG-PON and GPON.
Table 4-1 XGS-PON, XG-PON and GPON

Item GPON XG-PON XGS-PON
Standard G.984 G.987 G.9807.1
Rate Downstream: 2.5 Gbit/s Downstream: 10 Gbit/s Downstream: 10 Gbit/s
Upstream: 1.25 Gbit/s Upstream: 2.5 Gbit/s Upstream: 10 Gbit/s
36 SJ-20230719162004-003 | 2023-10-30 (R1.0)

4 XGS-PON Access Features
Item GPON XG-PON XGS-PON
Splitting ratio 1:64/128 1:64/128/256 1:64/128/256
Line code NRZ NRZ NRZ
Wave length Downstream: 1480 nm - Downstream: 1575 nm - Downstream: 1575 nm -

1500 nm 1580 nm 1580 nm
Upstream: 1290 nm - Upstream: 1260 nm - Upstream: 1260 nm -

1330 nm (narrowed) 1280 nm 1280 nm
Furthest range/Differential 20 km/20 km 40 km/40 km 40 km/20 km

range
Furthest logical range/ 60 km/20 km 60 km/40 km 60 km/40 km

Logical differential range
Data encapsulation GEM encapsulation XGEM encapsulation XGEM encapsulation
FEC Downstream RS (255, Downstream RS (248, Downstream RS (248,

239) 216) 216)
Upstream RS (255, 239) Upstream RS (248, 232) Upstream RS (248, 216)
Encryption Downstream AES En- Upstream and down- Upstream and down-
cryption stream AES Encryption stream AES Encryption
Multicast encryption Not Support Supported Supported
OMCI Fixed length and variable Fixed length and variable Fixed length and variable
length length length
Standard Compliance
Different from other ITU-T PON technologies, the components of XGS-PON standard have no
independent documents, and are defined as the Annex in G.9807.1.
 G.9807.1: 10-Gigabit-capable symmetric passive optical network (XGS-PON)
It is a family that defines this access network standard including terms and definitions used
in XGS-PON standards.
 G.9807.1 Annex A: General requirements of XGS-PON
It defines the services, evolution policies and fundamental technical capabilities requested
by the XGS-PON.
 G.9807.1 Annex B: Physical media dependent (PMD) layer specifications of XGS-PON
It defines the detailed technical specifications of the XGS-PON physical layer, including rate,
clock, optical interface data and interfaces.
 G.9807.1 Annex C: Transmission convergence layer specifications of XGS-PON
SJ-20230719162004-003 | 2023-10-30 (R1.0) 37

It defines the technologies and messages of the XGS-PON transmission layer, including da-
ta encapsulation, channel management, messages transmission mechanism, security, ener-
gy saving and alarm.
 G.988: ONU management and control interface (OMCI) specification
Based on G.984.4, it defines management and control interface for administering optical
network units. It added adaptive definitions for some new functions, correct and modify
some errors in G.984.4.
4.2 XGS-PON Optical Layer Feature

Description
G.9807.1 Annex B (Physical media dependent (PMD) layer specifications of XGS-PON) de-
fines XGS-PON physical layer parameters, including transmit optical power, receiving sensitivi-
ty, overloaded optical power and optical power budgets in different levels. In most cases.
various XGS-PON ODN networks and OLT/ONU design, providing important reference for net-
work optical power design.
Principle
For a description of the XGS-PON optical power budget levels, refer to Table 4-2.
Table 4-2 XGS-PON Optical Power Budget level

Item "Nominal1" class "Nominal2" class "Extended1" class "Extended2" class
(N1 class) (N2 class) (E1 class) (E2 class)
Minimum loss 14 dB 16 dB 18 dB 20 dB
Maximum loss 29 dB 31 dB 33 dB 35 dB
XGS-PON downstream wave length is 1575 nm – 1580 nm, and upstream wave length is 1260
nm –1280 nm, see Figure 4-2.
Figure 4-2 XGS-PON Downstream and Upstream Wave Lengths
For a description of the XGS-PON ODN physical parameters, refer to Table 4-3.
38 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Table 4-3 XGS-PON ODN Physical Parameters

Item Unit Technical Specification
Optical fiber type - [ITU-T G.652], or compatible
Attenuation range dB N1 class: 14–29
N2 class: 16–31
E1 class: 18–33
E2 class: 20–35
The maximum optical fiber range km DD20: 20

between points S/R and R/S. DD40: 40
The minimum optical fiber range km 0

between points S/R and R/S.
Bidirectional transmission - Single optical fiber WDM
Maintenance wave length nm Refer to ITU-T L.66.
4.3 XGS-PON ONU Authentication and Registration

Description
XGS-PON OLT uses embedded OAM and PLOAM channels to search ONUs periodically.
When the XGS-PON OLT gets a legal ONU, it allocates the corresponding ONU ID and mea-
sures the distance. After the XGS-PON OLT successfully measures the distance, it registers
the ONU through the PLOAM channel if necessary. After the successful registration, the XGS-
PON OLT configures and manages services through the just established OMCI management
channel.
This feature is used to access and control the XGS-PON ONU.
Principle
The XGS-PON ONU authentication and registration process is similar to GPON, refer to 1.3
GPON ONU Authentication and Registration.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 39

4.4 XGS-PON DBA Feature

Description
The DBA function in XGS-PON refers to a process that the OLT dynamically allocates upstream
transmission time slots for the ONU according to ONU T-CONT configurations and dynamic in-
dication (such as DBRu and idle XGEM frame).
This feature is used to dynamically allocate the XGS-PON upstream bandwidth.
Principle
XGS-PON DBA is an upstream bandwidth allocation process. The OLT dynamically allocates
upstream bandwidth to the T-CONT of each ONU. The ONU transmits upstream services in the
upstream bandwidth allocated to the T-CONT, see Figure 4-3.
Figure 4-3 XGS-PON DBA
The OLT allocates bandwidth according to ONU T-CONT configurations and dynamic indication
(such as DBRu and idle XGEM frame). The DBA calculation result is sent to the ONU through
BWmap.
40 SJ-20230719162004-003 | 2023-10-30 (R1.0)

4.5 XGS-PON Ranging Feature

Description
The XGS-PON has a point-to-multipoint architecture. An OLT connects to multiple ONUs. Nor-
mally, the physical distances between the OLT and each ONU are different. Although each
ONU transmits data with the allocated bandwidth in the upstream direction, similar to the GPON
ranging feature, multiple ONUs may conflict in upstream transmission.
scheduling in the XGS-PON system.
Principle
Figure 4-4 shows the principle of XGS-PON ranging.
Figure 4-4 XGS-PON Ranging
SJ-20230719162004-003 | 2023-10-30 (R1.0) 41

The furthest ONUR is obtained through ranging. According to the logical distance of ONUR,
other ONUis are allocated to an Equalization Delay. The ONUi waits for an Equalization Delay
when responding to the bandwidth allocation from the OLT.
The logical distance between the OLT and all ONUs is the same as that between the ONUR
and OLT, namely, all ONUs are identically far away from the OLT. Each ONU transmits up-
stream data in the allocated bandwidth, avoiding conflicts with other ONUs.
4.6 XGEM Port Feature

Description
Similar to GPON, each XGEM Port of the XGS-PON system is identified with an unique Port ID,
which is allocated by the OLT according to the XGS-PON port. A XGEM Port identifies a virtu-
al service channel between the OLT and ONU, namely, a channel that bears the service traffic
and is similar to the VPI/VCI in an ATM virtual circuit connection.
The Transmission Container (T-CONT) is a most basic control unit in the XGS-PON upstream
services. Each T-CONT is uniquely identified with an Alloc-ID. Every XGEM port is mapped to
the T-CONT and scheduled through the DBA scheduling by the OLT.
the XGS-PON system.
Principle
The XGEM Port and T-CONT works together to divide the PON into virtual connections, imple-
menting service multiplexing.
A XGEM Port can bear services in one or more types. The services born on the XGEM port are
A T-CONT can bear one or more XGEM Ports based on the specific configurations of users.
After the T-CONT is transmitted to the OLT, the XGEM Port is demodulated first, and then the
service payload is demodulated for corresponding service processing.
The XGEM frame is the minimum service bearing unit of the XGS-PON technology. It is the
most fundamental data structure. All services are encapsulated in the XGEM frame and then
transmitted. An XGEM frame consists of an XGEM frame header with fixed length (eight bytes)
and XGEM payload with variable length, including PLI (indicates the payload length) and Key
Index (indicates which secret key is used for encryption). shows the XGEM frame structure.
42 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Figure 4-5 XGS-PON XGEM Frame Structure
An XGTC payload consists of one or more XGEM frames, see Figure 4-6.
Figure 4-6 XGS-PON XGTC Payload Format
4.7 XGS-PON Data Encryption

Description
The XGS-PON is a point-to-multipoint system, in which the upstream and downstream data en-
cryption can protect the data sent to the ONU from being snooped on by other ONUs, ensur-
ing user data security. The XGS-PON encryption is similar to GPON. The difference is that the
GPON only supports the encryption to the downstream data.
The XGS-PON data encryption is to encrypt the upstream and downstream service data.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 43

Principle
Similar to GPON, the XGS-PON system supports an AES encryption algorithm that supports
AES encryption on each single XGEM Port. In an XGS-PON system, both of the upstream and
downstream unicast XGEM frame payload can be encrypted. The downstream multicast XGEM
frame can also be encrypted, improving user data security. The ONU generates the key and
transmits it upward. To avoid deciphering of the key, the XGS-PON system should changes the
key periodically.
4.8 XGS-PON Protection

Similar to GPON, the XGS-PON supports Type B and Type C switchover, refer to 1.8 GPON
Protection.
44 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Chapter 5
P2P Access Feature
Description
The P2P access uses WDM, which means that, the upstream and downstream uses different
wavelengths. A P2P physical interface uses an optical fiber. Compared with the common Eth-
ernet interfaces, P2P access saves a large number of optical fiber resources, reducing network
construction costs. The ZXA10 C600/C650/C620 PFGK board supports P2P interfaces.
 An PFGK board provides 48 channels of GE/FE P2P optical interfaces.
 The P2P interface of the PFGK board uses single fiber transmit/receive optical module.
Each fiber is connected to an ONU or Ethernet device.
Figure 5-1 shows a P2P access application scenario.
Figure 5-1 P2P Access Application Scenario
 Enterprise dedicated line

Because P2P access provides users reliable security isolation in the optical layer, each user
can enjoy a dedicated fiber for communication. Meanwhile, a single fiber is used to save
fiber resources and reduce construction costs. P2P access is primarily used for providing a
dedicated fiber for a large customer.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 45

 BTS network
The P2P access provides networks for BTS through direct connections or a P2P ring.
 Equipment interconnection
The P2P access can be used for interconnections between devices when fiber resources
are limited. The ZXA10 C600/C650/C620 can be cascaded in a ring network. The OLT is
used in the FTTC network through the P2P cascaded DSLAM MDU.
Principle
The PFGK board can use CSFP optical modules to provide P2P interfaces.
When the P2P interface is connected in the downstream, the downstream devices provide fre-
quency synchronization of SyncE and time synchronization of IEEE 1588v2, see Figure 5-2.
Figure 5-2 P2P Frequency/Time Synchronization
When the OLT is connected to the upstream IP/MPLS network, SyncE is used for frequency
synchronization.
The OLT is synchronized with the upstream devices through 1588v2. The OLT can obtain the
time information through the external 1PPS+TOD.
The OLT provides the 1588 BC function.
 The switching and control board and the uplink board provide the 1588v2 slave function.
 The P2P board provides the 1588v2 master function.
46 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Chapter 6
L2 Features
Table of Contents
L2 Port Features........................................................................................................................ 47
MAC Address Management....................................................................................................... 55
6.1 L2 Port Features

6.1.1 L2 Switch
Description
The ZXA10 C600/C650/C620 has numerous L2 service processing functions. The port involved
in the L2 service processing is called an L2 port. The physical Ethernet port can directly involve
L2 services, so it is an L2 port. The PON port cannot directly involve L2 services, therefore a
VPORT on the PON board is defined for L2 services.
 For the GPON port, a VPORT corresponds to a GEM Port.
 For the EPON port, a VPORT corresponds to an LLID.
An L2 port has the following functions:
 Port On/Off
 Access type configuration
 TPID configuration
 PVID configuration
 VLAN filtering
 MAC filtering
 ACL
 Plus and minus of outer Tag
 Outer Tag conversion
 Inner Tag conversion and plus or minus of outer tag
 Plus and minus of SVLAN+CVLAN
 SVLAN+CVLAN conversion
 Flexible QinQ
 Flexible plus and minus of VLAN Tag
SJ-20230719162004-003 | 2023-10-30 (R1.0) 47

 Traffic mirroring
 Traffic loopback
 Traffic statistics
 QoS processing
Principle
Figure 6-1 shows the L2 switch principle.
Figure 6-1 L2 Switch Principle
 At ingress port, system carries out VLAN translation, VMAC translation, ingress ACL,
ingress Mirror, ingress policing.
 At egress port, system carries out egress ACL, egress mirror, egress policing.
 Forwarding includes L2 switch, L3 route, MPLS switch, L2VPN.
 Switch card is cell based to exchange cells between service cards.
6.1.2 TPID Configuration Over the L2 Port

Description
TPID is a field of a VLAN Tag. By default, the TPID of a single Tag is 0x8100. For dual Tags,
the default TPID of the inner layer is 0x8100, and the default TPID of the outer layer is 0x88A8.
In a practical network, the TPID specified by some operators may different from the default val-
ue. To achieve better intercommunication, the ZXA10 C600/C650/C620 provides TPID configu-
ration. You can specify the input and output value of the inner and outer TPID of an L2 port.
 When receiving packets, the system checks whether the input TPID value is matched and
then decides the packet type. If the packets are single Tag packets or dual tag packets but
the TPID is not matched, the packets are discarded.
 Before transmitting packets, the system needs to modify the single/dual tag value to the
configured output TPID value.
According to the number of Tags, packets can be classified into the following types:
48 SJ-20230719162004-003 | 2023-10-30 (R1.0)

6 L2 Features
 Untag: packet.[12-13]≠outer TPID and packet.[16-17]≠inner TPID

 S-tag: packet.[12-13]=outer TPID and packet.[16-17]≠inner TPID
 C-tag: packet.[12-13]≠outer TPID and packet.[12-13]=inner TPID
 Dual Tag: packet.[12-13]=outer TPID and packet.[16-17]=inner TPID
Because the outer TPID field of the Tag packet is the same as the length/Type field of the Un-
tag, the TPID configuration should avoid the following common protocol types:
 ARP: 0x0806
 IP: 0x0800
 MPLS: 0x8847/0x8848
 IPX: 0x8137
 IS-IS: 0x8000
 LACP: 0x8809
 802.1x: 0x888E
The TPID configuration is applicable to all scenarios of Ethernet interconnections.
Principle
This feature is implemented by a chip through command line and EMS configurations.
6.1.3 L2 Port Access Mode

Description
The L2 port of the ZXA10 C600/C650/C620 supports three access modes: Access, Trunk and
Hybrid.
 Access: Connects to users and only receives Untag packets.
 Trunk: Connects to the network and only receives Tag packets.
 Hybrid: Connects to not only users but also the network and receives packets of above two
types.
When the L2 port receives the packets that do not correspond to the access mode, the packets
are discarded. The port access mode can be modified through configuration. By default, it is set
to Hybrid.
Access mode is applicable to the scenarios of broad band access and VPN applications.
Principle
This feature is implemented by a chip through command lines and EMS configurations.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 49

6.1.4 MAC Address Filtering Over the L2 Port

Description
An L2 port can be configured with an MAC address blacklist, to discard the packets whose ad-
dress lists match the source MAC address. Each L2 port supports at least eight MAC address-
es.
The MAC address filtering function is applicable to all scenarios.
Principle
6.1.5 VLAN Filtering Over the L2 Port

Description
When an L2 port is configured to Trunk and Hybrid modes, it can specify multiple VLANs to be
added into. The port discards the Tag packets that are not configured with VLAN. When the L2
port is configured to Access mode, all Tag packets are discarded. When the L2 port is config-
ured to Trunk mode, the Untag packets are discarded.
The VLAN filtering function is applicable to all scenarios.
Principle
6.1.6 VLAN Tag Conversion Over the L2 Port

Description
In an access network, a VLAN Tag is used to identify a user and service. For more convenient
VLAN planning, operators use different VLAN configuration solutions in different network seg-
ments. Therefore, an L2 port is required to have a flexible VLAN Tag conversion function, in-
cluding Tag deletion, modification, and a independently configured conversion rule between the
ingress and egress of the port.
The ZXA10 C600/C650/C620 supports the VLAN tag conversion function of a single Tag and
dual Tags.
 Adds one Tag or two Tags to untagged messages.
50 SJ-20230719162004-003 | 2023-10-30 (R1.0)

6 L2 Features
 Transparent transmits one-tag message.

 Convert one-tag message to one-tag message or two-tag message.
 Adds one Tag to one-tag message.
 Adds one Tag to one-tag message according to VLAN range
 Convert two-tag message to two-tag message.
 Adds one Tag or two Tags to all message
The conversion rule is described as follows: port, in/out, S-Tag+[C-Tag] --> S’-Tag+[C’-Tag].
The VLAN conversion is applicable to the scenario of the unified ONU VLAN configuration and
upstream VLAN reuse.
Figure 6-2 shows the application scenario of the unified ONU VLAN configuration and upstream
VLAN reuse.
Figure 6-2 Unified ONU and VLAN Configuration
All ONUs distinguish services according to different ports, and they use the same VLAN tag.
The same configuration of different ONUs can reduce the complexity of configurations. The
VPORT of the OLT uses the VLAN Tag conversion method that identifies the S-VLAN of users,
thereby different users are distinguished to achieve the target of identification and isolation of
user services.
Figure 6-3 shows an application scenario of upstream VLAN reuse.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 51

Figure 6-3 Upstream VLAN Reuse
An C-Tag is added on the VPORT to identify users. The outer Tag of the upstream port is con-
verted to the same S-tags, which means that, different upstream ports are connected to differ-
ent SPs. The VLAN spaces can be reused, facilitating the VLAN planning in different SP net-
works.
Benefit
This feature helps to implement the VLAN planning of operators and expand the VLAN spaces.
Principle
6.1.7 VLAN Connect

Description
The OLT supports services transparent transmission by using 1:1 VLAN channels. A 1:1 VLAN
channel uses SVLAN or S+C VLAN as the only identifier to set up a private virtual channel be-
tween a service port and an uplink port. The ingress port of a channel filters service traffics ac-
cording to VLAN IDs. The traffics whose VLAN ID match the port VLAN list are transparently
transmitted to the egress port the virtual channel. The traffics whose VLAN ID do not match the
port VLAN list are discarded. The ports in a 1:1 VLAN channel do not learn MAC addresses.
Features
The OLT supports the following 1:1 VLAN features:

 A virtual channel contains only two ports. A port can belong to multiple virtual channels
which can are distinguished by VLANs.
 The two port of a virtual channel can be a user-side port and a network-side port, or two
user-side ports, or two network-side ports.
52 SJ-20230719162004-003 | 2023-10-30 (R1.0)

6 L2 Features
 The service transparent transmission between the two ports of a virtual channel requires the
cooperation of user side layer 2 communication.
 The network-side port of a virtual channel can be either a physical port or an LACP group.
 After VLAN filtering, the ingress port of a virtual channel can perform VLAN translation or
VLAN QinQ. The virtual channel takes the translated VLAN or S+C VLAN as the unique
identifier.
 By default, a virtual channel transparently transmit all traffics, and supports the configuration
of DHCP layer 2 relay and PPPoE IA.
Because a 1:1 VLAN channel does not learn MAC addresses, the channel does not support the
following functions:
 MAC address filtering
 MAC address anti-flapping
 MAC address learning number limit
 IPv4/v6 source guard
6.1.8 PVID Configuration Over the L2 Port

Description
An L2 port can be configured with a PVID, which adds the PVID Tag to the received Untag
packets for transmission in the corresponding VLAN. By default, the PVID is configured to 1.
The PVID configuration is applicable to all scenarios.
Principle
6.1.9 Adding a VLAN Tag to the L2 Port

Description
The PVID can be used to specify a VLAN Tag for the Untag packets of each L2 port. Howev-
er in some enterprise applications, a more flexible method of adding a VLAN Tag for the Untag
packets is needed, that is, adding a VLAN Tag according to the MAC address list, IP subnet, or
the Ethernet type.
This feature is applicable to the scenario where the flexible method of adding a VLAN tag to the
enterprise services is needed.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 53

Principle
6.1.10 Traffic Mirroring Over the L2 Port

Description
The traffic mirroring means that the system copies the traffic complied with the certain condition
of a port, and outputs the traffic through another port. The traffic mirroring is implemented to an-
alyze service traffic, troubleshoot the faults and analyze performance problems. In most cases,
the output port is an Ethernet port.
The ZXA10 C600/C650/C620 supports traffic mirroring in accordance with the port, port + VLAN
and ACL traffic mirroring. It also supports independent or simultaneous traffic mirroring of the
ingress and egress.
For example, the ZXA10 C600/C650/C620 supports simultaneous mirroring of two traffics.
This feature is applicable to the fault and performance analysis.
Impact
If the traffic mirroring function is enabled, the normal services of a port will be affected.
Principle
By the configuration of command lines and EMS configuration, the chip distinguishes and
copies the mirrored traffics, and outputs the copied traffics through the mirroring port.
6.1.11 Traffic Statistics Over the L2 Port

Description
The ZXA10 C600/C650/C620 supports the traffic statistics on the basis of the port and port
+outer VLAN. The traffic statistics includes:
 Number of upstream bytes
 Number of downstream bytes
 Number of upstream packets
 Number of downstream packets
 Total upstream bandwidth
 Total downstream bandwidth
 Upstream bandwidth utilization
 Downstream bandwidth utilization
54 SJ-20230719162004-003 | 2023-10-30 (R1.0)

6 L2 Features
 Upstream byte rate

 Downstream byte rate
 Upstream packet rate
 Downstream packet rate
 Number of upstream unicast packets
 Number of downstream unicast packets
 Number of upstream multicast packets
 Number of downstream multicast packets
 Number of upstream broadcast packets
 Number of downstream broadcast packets
 Number of discarded upstream packets
 Number of discarded downstream packets
The Vport supports statistics of at least eight VLANs. The downstream Ethernet port sup-
ports statistics of at least 64 VLANs. The upstream port supports statistics of at least 256 outer
VLANs.
The refresh rate of traffic statistics can be set to once per second.
This feature is applicable to the fault and performance analysis.
Principle
6.2 MAC Address Management

The ZXA10 C600/C650/C620 is an L2 device. The MAC address management includes the
MAC learning, aging, number control and query. These features provide the management and
maintenance, action control and security configurations for the L2 switching function.
6.2.1 Permanent MAC Address

Description
The permanent MAC address does not need learning. It specifies a static unicast MAC address
directly on the VLAN member port (including Vport, upstream and downstream Ethernet port
and LAG), to forward the packets through this port in a fixed manner.
The permanent MAC address has the following features:
 The permanent MAC address will not be aged.
 The permanent MAC address is prior to the dynamic MAC address when there is a conflict
between them.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 55

 The different VLANs can have the same permanent MAC address.
 The system supports to add, delete or query the permanent MAC address.
 The permanent MAC address is configured manually, namely, it still exists after power-off
restart.
The ZXA10 C600/C650/C620 supports the number of permanent MAC address as follows:
 Each Vport supports 16 permanent MAC addresses.
 Each PON card supports 256 permanent MAC addresses.
 The system supports at least 2048 permanent MAC addresses.
The permanent MAC address is applicable to all scenarios.
Benefit
The device whose MAC address is specified by a user accesses the network from a specified
port, to prevent MAC address aging and flapping.
Principle
6.2.2 MAC Learning

Description
The MAC learning is the basis of L2 switching. Through the learning of the source MAC ad-
dress of Ethernet packets, the system sets the MAC address in the access interface, to output
the corresponding Ethernet packets that uses this MAC address as the destination address,
achieving the correct delivery of packets.
The ZXA10 C600/C650/C620 MAC learning has the following features:
 Supports enabling the dynamic MAC learning according to the VLAN or port. By default, dy-
namic MAC learning is enabled on all VLANs.
 The MAC learning rate can reach to the line rate.
 When the learning MAC address conflicts with the exist permanent MAC address, the learn-
ing fails.
 When the learning MAC address conflicts with the exist dynamic MAC address:
à If the MAC anti-flapping function of this VLAN is enabled and the MAC address is from a
user side port (PON port), the learning fails.
à If the MAC anti-flapping function of this VLAN is enabled and the MAC address is from a
network side port, the MAC + port entry is updated.
à If the VLAN allows MAC address flapping, the MAC + port entry is updated.
56 SJ-20230719162004-003 | 2023-10-30 (R1.0)

6 L2 Features
 If the address list is full, the learning fails and an alarm is reported.
The MAC learning is applicable to all scenarios.
Principle
The system extracts the source MAC address of Ethernet packets input from a VLAN member
port, and then query the forwarding table of this VLAN.
 If the MAC address is new, the system adds a entry and fills in the member port ID which
this MAC address belongs to.
 If the MAC address already exists, and the port does not change, the entries are refreshed
and the aging time is reset. Otherwise, the MAC flapping occurs. The system checks
whether MAC flapping is allowed on the basis of the flapping policy.
à If the MAC flapping is not allowed, an alarm is reported and the learning fails.
à If the MAC flapping is allowed, the member port ID in the entry is modified and the port of
the MAC address is changed, to change the output port of the subsequent packets that
use the MAC address as the destination address.
6.2.3 MAC Address Aging

Description
For better use of MAC address list resources, the MAC address that has no traffic in a long
term needs to be aged to save system resources. Through the dynamic MAC address study,
you can configure the system aging time or configure the aging time on the basis of VLAN.
The ZXA10 C600/C650/C620 supports the following MAC address aging features:
 If a MAC address is not matched in two MAC aging time, the MAC address is deleted.
 By default, the aging time is 300 s, which ranges from 10 s to 1000000 s. However, the
maximum aging time is 4095 s.
The MAC address aging function is applicable to all scenarios.
Principle
The latest refresh time is set in the L2 forwarding entries. The system regularly queries the en-
tries. If the difference between the current time and the latest refresh time exceeds the aging
time, the entry is deleted and the aging is achieved. The chip hardware has the aging function
that does not affect the chip performance.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 57

6.2.4 Limitation of the Number of MAC Addresses

Description
To limit the number of users accessing terminals and to avoid OLT forwarding resource occupa-
tion, the ZXA10 C600/C650/C620 supports to configure the number of dynamic learning MAC
addresses according to ports. If the number of dynamic learning MAC addresses reaches the
maximum value, the learning of the new MAC address from this port or VLAN is stopped.
Note
MAC+VLAN is considered as an address. The different VLANs with the same MAC are considered as two
addresses.
The restriction of the number of MAC addresses is applicable to all scenarios.
Principle
During the MAC learning procedure, the system calculates the number of learned MAC ad-
dresses on a VLAN member port, checks the number of learning MAC addresses, and then de-
cides whether the number of MAC addresses exceeds the preset threshold through the sum of
these two numbers. If yes, the learning fails and the number of MAC addresses from a member
port is limited.
6.2.5 MAC Address Query

Description
For effective management and maintenance, the ZXA10 C600/C650/C620 provides commands
to query static and dynamic MAC addresses.
 Supports to query the MAC address list according to the VLAN and ports.
 The MAC address list information includes the VLAN, port, dynamic and static address.
 The query result includes the MAC addresses statistics.
The MAC address query function is applicable to all scenarios.
Principle
The MAC addresses are queried according to the L2 forwarding table in the chip and displayed
through the command lines or OAM.
58 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Chapter 7
IPv4 L3 Features
Table of Contents
L3 Interfaces...............................................................................................................................59
ARP.............................................................................................................................................61
ARP Proxy.................................................................................................................................. 62
DHCP..........................................................................................................................................63
ICMP........................................................................................................................................... 68
Route.......................................................................................................................................... 69
GRE............................................................................................................................................ 74
ECMP..........................................................................................................................................77
VRF.............................................................................................................................................77
7.1 L3 Interfaces
Description
The L3 interfaces can be configured with IP addresses, receives or transmits IP packets, and
can be used for host or router IP addressing.
In a flat network architecture, the ZXA10 C600/C650/C620 acts as an IP address convergence

device to achieve cross-VLAN IP routing. In this case, ZXA10 C600/C650/C620 must have L3
logic interfaces with IP address IDs.
ZXA10 C600/C650/C620 supports 1k L3 logic interfaces.
Principle
Figure 7-1 shows the principle of the L3 interfaces of the ZXA10 C600/C650/C620.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 59

Figure 7-1 L3 Interface Principle
The ZXA10 C600/C650/C620 provides four types of L3 interfaces.

 Loopback interface
The loopback interface loops back IP traffic to the local CPU and processes control-plane
protocols such as dynamic routing protocols and network management protocols.
 Null interface
The null interface is often used for black-hole routing and does not need any IP address.
It receives packets but does not transmits them. The IP traffic directed to this interface is
abandoned silently by the system.
 VLAN interface
The VLAN interface is an L3 logic interface. The ZXA10 C600/C650/C620 uses single-lay-
er VLAN tags to identify different L3 logic interfaces. The VLAN interface can be configured
with IP address for network addressing.
 SuperVLAN interface
The super VLAN interface is an L3 logic interface that aggregates multiple sub-VLANs with
L2 broadcast isolation. The super VLAN interface can be configured with IP address for net-
work addressing.
The L3 interfaces support complete IP protocol stacks, such as Ethernet-layer ARP address
resolution, ICMP, TCP, and UDP communication. Between different L3 interfaces, the forward-
ing-plane FIB routing table can be directly queried and forwarded according to the destination
addresses of IP packets.
60 SJ-20230719162004-003 | 2023-10-30 (R1.0)

7 IPv4 L3 Features
7.2 ARP
Description
When a network device sends data to another, the network device must know the IP address
and MAC address of the destination network device. ARP maps the IP address to the MAC ad-
dress to ensure communication.
When the ZXA10 C600/C650/C620 performs routing and forwarding according to the destina-
tion IP address, it resolves the ARP address on the L3 interface of the Ethernet to obtain the
MAC address of the host or next-hop router.
Influence and Limitation
After ARP resolves the MAC address, the boards must still use this MAC address for Ethernet
forwarding. Normally, the boards have 16k or 32k MAC learning and forwarding capabilities. If
general mode of L3 mode is enabled, the number of system ARP table entries are more than
the number of MAC entries of a single board. In network planning, the number of IP hosts of a
single board should not exceed the maximum number of MAC table entries that the board sup-
ports.
Principle
ARP provides an interaction mechanism that allows packet requests and responses and
achieves translation between IP addresses and MAC addresses. The ARP process is described
as follows:
1. When host A translates the IP address Ib, it broadcasts a special packet in the physical net-
work to request the host whose IP address is Ib to respond using its MAC address Pb.
2. All hosts in the physical network can receive this request, but only the host B identifies its IP
address and gives a response that contains its MAC address.
3. Host A receives the response and then translates host B’s IP address into a MAC address.
The mapping relationships between IP addresses and MAC addresses are cached into the lo-
cal ARP table to reduce the ARP packets in the network and send data more quickly. When the
ZXA10 C600/C650/C620 needs to send data, it checks the ARP table according to the IP ad-
dress. If it finds the MAC address of the destination device, it does not send an ARP request.
The dynamic table entries in the ARP table are deleted automatically after a certain period of
time, which is called ARP aging time.
To prevent ARP virus attacks or unauthorized user access, users can configure permanent
ARP entries on the ZXA10 C600/C650/C620. Permanent ARP entries take effect immediately
upon configuration and will not lose even the ZXA10 C600/C650/C620 is restarted.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 61

7.3 ARP Proxy

Description
When an L2-isolated host needs ARP communication, the ARP proxy function on the router (
ZXA10 C600/C650/C620) must be enabled to forward ARP packets.
On the L3 Ethernet interface, the ZXA10 C600/C650/C620 uses ARP to resolve the MAC ad-
dresses corresponding to IP addresses. For horizontally-isolated hosts of VLANs, the ARP
proxy function on the L3 VLAN interface must be enabled to forward ARP packets.
 The ARP proxy function can be enabled for specific VLAN users instead of all users.
 The ARP proxy function must be used on the L3 interface and the ONUs on the same L3 in-
terface must be in the same network segment.
 The ZXA10 C600/C650/C620 is configured with L3 interfaces and IP addresses that are in
the same network segment as users’, and enables the ARP proxy function.
 The ZXA10 C600/C650/C620 supports up to 32 L3 interfaces with enabled ARP proxy func-
tion.
Figure 7-2 shows the application scenario of the ARP proxy.
Figure 7-2 ARP Proxy Application Scenario
Principle
PC1 and PC2 are in the same IP subnet of a horizontally-isolated VLAN. PC1 and PC2 are in
the same IP subnet of a horizontally-isolated VLAN. To make PC1 and PC2 communicate on
the same L3 interface of the OLT (ZXA10 C600/C650/C620), an IP address must be configured
for the IP subnet on the L3 interface and the ARP proxy function must be enabled.
The process is described as follows:
1. PC1 knows that it is in the same IP subnet as PC2 according to PC2’s IP address. To make
IP packets reach PC2, PC1 must know PC2’s MAC address. Therefore, PC1 broadcasts an
ARP request in the subnet where it is resides.
2. PC1 and PC2 are horizontally isolated in the VLAN, so PC2 cannot receives PC1’s ARP
request. The OLT receives the broadcast on the L3 interface and, if the OLT’s ARP proxy
62 SJ-20230719162004-003 | 2023-10-30 (R1.0)

7 IPv4 L3 Features
function is enabled, responds PC1 with its own MAC address and PC2’s IP address. In the
ARP response packet, the source IP address is PC2’s IP address, and the source MAC ad-
dress is the MAC address of the OLT’s L3 interface.
3. PC1 receives the ARP proxy response from the OLT and updates its own ARP address ta-
ble.
4. PC1 sends the packets whose destination is PC2 to the MAC address of the OLT’s L3 inter-
face. The OLT does not send the ICMP redirect message through the interface whose ARP
proxy function is enabled because the OLT knows how to reach PC2 and will forward PC1’s
packets to PC2.
The ARP proxy is different from the ARP agent in the following aspects:
 When receiving an ARP request from a user, the ARP proxy responds with the OLT’s MAC
address, while the ARP agent responds with the IP gateway’s MAC address (for MFF func-
tion).
 When acting as an ARP proxy, the OLT transfers the traffic in the IP subnet. When acting as
an ARP agent, the OLT only forwards to the IP gateway, which then transfers the traffic in
the IP network.
 The ARP agent does not need L3 interfaces or their IP addresses, while the ARP proxy
does.
The ARP agent is applicable when the OLT acts as an L2 aggregation device.
7.4 DHCP
Description
DHCP provides addresses and configuration parameters for the hosts on the Internet. DHCP
operates in client/server mode. The DHCP server allocates IP addresses and provides configu-
ration parameters for the hosts.
DHCP has the following advantages:
 Less configuration and deployment time
 Reduced possibility of configuration errors
 Centralized IP address allocation and management
In the WAN environment, DHCP plays the following three roles:
 DHCP client
The DHCP client automatically acquires IP addresses and other configuration parameters
from the DHCP server.
 DHCP server
The DHCP server controls a segment of IP addresses, which are allocated automatically to
the DHCP clients when they log in to the DHCP server.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 63

 DHCP relay
The DHCP relay forwards DHCP packets between the DHCP server and client. When the
DHCP client and server are not in the same subnet, the DHCP relay is required to forward
DHCP requests and responses. The DHCP relay forwards data in a different way from ordi-
nary routing and forwarding, which are transparent transmission without modifying the con-
tent of IP packets. By contrast, after receiving a DHCP message, the DHCP relay generates
and forwards a new DHCP message.
For the DHCP client, the DHCP relay acts as a DHCP server. For the DHCP server, the
DHCP relay acts as a DHCP client.
DHCP is initially used in the LAN, where DHCP clients and the only server are in the same
broadcast domain. When DHCP is used in the WAN, the DHCP relay is introduced. Figure 7-3
shows the application scenario of DHCP.
Figure 7-3 DHCP Application Scenario
 The DHCP L3 relay can forwards DHCP requests from different broadcast domains or sub-
nets to the subnet where the DHCP server resides, so that users do not need to set a DHCP
server in each broadcast domain.
 In the same broadcast domain, such Ethernet aggregation devices as SFU, MDU and OLT
transmit DHCP packets transparently. In an N:1 VLAN, the server cannot identify different
DHCPs after they aggregate and traverse multiple network segments. DHCP L2 relay and
DHCP L3 relay can insert user line information into the DHCP to help the server to distin-
guish different users.
 Normally, the DHCP server uses active/standby and load balancing techniques to process
large numbers of DHCP address requests in the WAN. The DHCP L3 relay can forward ad-
dress requests to a group of DHCP servers.
64 SJ-20230719162004-003 | 2023-10-30 (R1.0)

7 IPv4 L3 Features
 Different IP address plans are available for different services. The DHCP relay forwards
DHCP address requests to different DHCP servers according to the DHCP client’s subnet
and type.
The ZXA10 C600/C650/C620 supports the following DHCP functions:
 L2 DHCP transparent message transmission. During transparent transmission, DHCP
process snooping can be performed to prevent IP address frauds.
 DHCP L2 relays inserted by the subscriber line identifier.
 Inter-network segment DHCP l3 relays
 DHCP L3 relays, which support selection of DHCP servers according to the terminal type
and the network segment where the terminal resides.
The ZXA10 C600/C650/C620 provides the following DHCP functions:
 The DHCP L2 relay supports global enabling and physical Ethernet port or VPort enabling.
 The DHCP L3 relay supports global enabling and L3 logical port enabling (VLAN port, Super
VLAN interface).
 The DHCP L3 relay supports 20 DHCP server groups, each of which has the IP addresses
of up to eight servers.
Principle
 DHCP L3 Relay
The DHCP L3 relay modifies the address of the DHCP packet originated by a subscriber to
a local IP address by changing giaddr in the DHCP packet header. Meanwhile, the OLT (
ZXA10 C600/C650/C620) acts as a relay to send the DHCP packet to the DHCP server as
a unicast packet. The DHCP server uses giaddr as the destination address to send a DHCP
response packet to the OLT, which then forwards the DHCP response packet to the sub-
scriber. Figure 7-4 shows the principle of the DHCP L3 relay.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 65

Figure 7-4 DHCP L3 Relay Principle
 DHCP L2 Relay
When the OLT acts as an Ethernet aggregation device, it performs L2 forwarding. The OLT
has no L3 interface or IP address.
By default, the OLT transmits DHCP packet transparently. In the WAN environment, oper-
ators do not trust DHCP clients and require trusted access devices to insert subscriber line
identifiers to identify different DHCP clients in the same VLAN broadcast domain. In this
case, the OLT can enable the DHCP L2 relay function to insert Option82 (relay agent op-
tion) to carry subscriber line identifiers. Figure 7-5 shows the principle of the DHCP L2 relay.
66 SJ-20230719162004-003 | 2023-10-30 (R1.0)

7 IPv4 L3 Features
Figure 7-5 DHCP L2 Relay Principle
As a DHCPv4 relay device, the OLT checks whether option82 exists in upstream packets.
à If a packet has Option82, the OLT processes the packet and then forwards the packet to
the DHCPv4 server.
For Option82-trusted ports, the OLT keeps the original Option82 and decides whether to
add the OLT’s line identifiers CircuitID and RemoteID in Option82 according to the con-
figured policy. This method is often used for trusted MDUs.
For non-Option82-trusted ports, the OLT abandons the original Option82 and replaces it
with the Option82 that acts as the relay agent of the OLT. This method is often used for
untrusted clients or SFUs.
à If there is no Option82 in the packet, the OLT acts as a relay agent to add Option82 in
the packet and then forwards the packet to the DHCPv4 server.
After receiving the packet forwarded by the DHCP relay, the DHCP server records the infor-
mation carried by the option field in the packet, and sends the packet with DHCP configura-
tion and Option 82 information to the DHCPv4 relay.
Option82 (Relay Agent Option) contains SubOption1 (Circuit ID) and SubOption2 (Re-
moteID).
As a DHCP L2 relay, the OLT does not modify giaddr and the source IP address. Instead,
the OLT uses the broadcast IP address to forward DHCP packets without selecting a DHCP
server in the VLAN broadcast domain.
 Option60
SJ-20230719162004-003 | 2023-10-30 (R1.0) 67

Option60 is the vendor class identifier option in the DHCP protocol. As an attribute of the
DHCP client, Option60 is filled by the DHCP client to identify the client type. When the
ZXA10 C600/C650/C620 OLT operates in DHCP L3 Relay mode, it identifies the Option60
field in subscribers’ DHCP packets and then forwards these packets to different DHCP serv-
er according to different Option60 fields to acquire different IP addresses.
One Option60 is a string that corresponds to a DHCP server group. Figure 8-7 shows the
principle of DHCP Option60. shows the principle of the DHCP L3 relay.
Figure 7-6 DHCP Option60 Principle
7.5 ICMP
Description
As one of the main protocols of the Internet Protocol Suite, ICMP is used to send control mes-
sages in TCP/IP networks to feed back various problems that can occur in the communication
environment. Through such information, network administrators can analyze the problems and
solve them with appropriate methods.
When the ZXA10 C600/C650/C620 enables L3 interfaces, the basic IP protocol stack includes
the ICMP function. The IPv4 interface supports ICMPv4 and the IPv6 interface supports ICM-
Pv6.
Principle
ICMP is one of the protocols of the Internet Protocol Suite and is defined in RFC 792. The pro-
tocol is often used to return the network error information or analyze routes. ICMP error mes-
sages include source data, which is returned to the sender.
One example of ICMP error messages is TTL value expiration. When forwarding packets, each
router decreases the TTL value in the IP packet header by one. If the TTL value is 0, the mes-
68 SJ-20230719162004-003 | 2023-10-30 (R1.0)

7 IPv4 L3 Features
sage “TTL expired in transit” will be reported to the source address. Each ICMP message is di-
rectly encapsulated in an IP packet. Therefore, like UDP, ICMP is unreliable.
Multiple commonly-used tools are based on ICMP messages. Traceroute is achieved by send-
ing packets with special TTLs and receiving “ICMP Time Exceeded” messaged and “Destina-
tion Unreachable” messages (Type code: 3). Ping is achieved by using “Echo request” (Type
code: 8) and “Echo reply” (Type code: 0) of ICMP.
The ICMP Redirect message (Type code: 5) is used by a router to notify the host to update
the routing table after the router receives a packet from the host and finds another route that is
more appropriate to forward the packet. In operator networks, this function is not used in most
cases for the sake of security. When the ARP proxy function of L3 interfaces is enabled, the
routing redirect function is disabled.
7.6 Route
Description
Routers provide a mechanism that interconnects heterogeneous networks and sends a packet
from one network to another. Routing is path information that directs IP packet sending. When
a router receives a packet, it selects an appropriate path according to the destination address in
the packet header (through a network) and sends the packet to the next router. The final router
in the path sends the packet to the destination host.
When a packet is transported in a network, each router selects the best local path to forward
the packet to the next routers until the packet is forwarded to the destination through best
paths. However, packets are not always forwarded through best paths due to some certain rout-
ing policies.
The ZXA10 C600/C650/C620 is used as an L3 router.
Principle
 Routing Table
Routers select routes by using routing tables. In the past, routers completely relied on their
CPUs to forward packets according to the routing table RIB with low processing speed and
throughput. At present, routers provide control-plane slow path and forwarding-plane fast
path. The control plane sends the best routes in the RIB to the FIB of the forwarding plane.
The FIB directs packet forwarding. The control plane processes routing protocol interac-
tions, makes complicated routing computations, and maintain RIB information. The forward-
ing plane only needs to forward packets according to the FIB to help the hardware pipeline
forward packets fast with large throughput. Each router stores at least one RIB and one FIB.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 69

A routing table saves routes discovered through various routing protocols, and it includes
routing information on all network segments known to the router.
In the FIB, each forwarding entry indicates which physical interface of the router should be
used to send the packet whose destination is a subnet or host, so that the packet can reach
the next router in the path, or can be transported to the destination host in the directly-con-
nected network without being forwarded by other routers.
The following shows a common IPv4 routing table.
IPv4 Routing Table:
Dest Mask Gw Interface Owner pri metric
10.26.32.0 255.255.255.0 10.26.245.5 VLAN100 BGP 200 0
10.26.33.253 255.255.255.255 10.26.245.5 VLAN100 OSPF 110 14
10.26.33.254 255.255.255.255 10.26.245.5 VLAN100 Static 1 0
10.26.36.0 255.255.255.248 10.26.36.2 VLAN20 Direct 0 0
10.26.36.2 255.255.255.255 10.26.36.2 VLAN20 Address 0 0
10.26.36.24 255.255.255.248 10.26.36.26 VLAN30 Direct 0 0
10.26.245.4 255.255.255.252 10.26.245.6 VLAN100 Direct 0 0
10.26.245.6 255.255.255.255 10.26.245.6 VLAN100 Address 0 0
For a description of the routing table entries, refer to Table 7-1.
Table 7-1 Routing Table Entry Descriptions

Entry Description
Dest Address of the destination logic network or subnet
Mask Mask of the destination logic network or subnet
Gw Port address of the neighbor router, namely, next-hop IP address of the routing.
Interface Interface that learns the routing entry, also the interface through which packets leave the
router for the destination.
Owner Routing source, indicating how the routing information is learned.
Pri Administrative distance, namely, priority, which determines the priority of the routing in-
formation from different routing sources.
Metric Routing metric, which indicates the cost of each possible route. The route with the low-
est metric is the best route. Metrics are comparable only when a dynamic routing proto-
col finds multiple routes to the same network segment. The metrics of different routing
protocols are not comparable.
For example, the routing entry 10.26.33.253 in the previous routing table, where,
à 10.26.33.253 and 255.255.255.255 are respectively the address and mask of the desti-
nation physical network or subnet.
70 SJ-20230719162004-003 | 2023-10-30 (R1.0)

7 IPv4 L3 Features
à 10.26.245.5 is the next-hop logical address.

à VLAN100 is the L3 interface that learned this route and that will forward the data.
à OSPF is the method that the router uses to learn the route. In this example, this route
entry is learned through the OSPF.
à 110 is the administrative distance of the route and 14 is the metric of the route.
The routing source, administrative distance and metric of the routes in the routing table are
described as follows:
à Routing source (Owner)
For a description of the routing sources, refer to Table 7-2.
Table 7-2 Routing Source Descriptions

Routing Source Description
Local address In the routing table, if the Owner is Address, it means that the routing
source is the local address.
Directly connected route Route generated by the network segment that is directly connected
with the router. The route is found by the link-layer protocol. A directly
connected route can only find the network segment to which the local
interface belongs.
When an interface is configured with a network protocol address, the
physical connection is correct, and the interface detects the keepalive
information of the data link layer protocol, the network segment ad-
dress configured on the interface will be included automatically into the
routing table and associate with the interface. When the router detects
that this interface is down, the route will be removed from the routing
table.
The Owner of the directly connected route is Direct, and the route has
the highest priority 0. The metric of the route is 0, which means the
route has the lowest metric.
Static Route The static route refers to a route that is set manually by the network ad-
ministrator. Static routes are preset according to network configuration
when the system is installed, and will not automatically varies with the
network topology. Whether a static route appears in the routing table
depends on whether the next hop is reachable, that is, whether the net-
work segment of the next hop address on this route is reachable by this
router.
The Owner of the static route is Static, the route priority is 1 and the
Metric value is 0.
Dynamic route Dynamic routes are generated by dynamic routing protocols. Routing
protocols generate routing entries according to the interface configura-
tions (such as IP address configuration) of the router and the status of
the connected link. Dynamic routing protocols generate and maintain
SJ-20230719162004-003 | 2023-10-30 (R1.0) 71

Routing Source Description

routing tables required by the forwarding engine through routing infor-
mation exchanges. When the network topology is changed, dynamic
routing protocols can automatically update the routing table and deter-
mine the best path for data transmission.
Dynamic routes can adjust routing information according to the
changes of network topology to meet the requirements of large-scale
and complicated networks. Common dynamic routing protocols include
RIP, OSPF, IS-IS, and BGP.
à Administrative distance (Pri, distance)

Different routing protocols may discover different paths to the same destination. How-
ever, not all these paths are optimal. At a certain moment, the current route to a certain
destination is decided by only one routing protocol.
To identify the best paths, each of the routing protocols, including static routing proto-
cols, are allocated with an administrative distance. When multiple routing sources exist,
the route found by the routing protocol that has the shortest administrative distance will
be added into the routing table as the best path.
Different vendors’ routers have different administrative distances for routing protocols.
The lower the administrative distance is, the higher the priority will be.
If there are multiple routes that have the same destination network segment, IP packets
will be forwarded through the highest-priority route, namely, the route with the lowest ad-
ministrative distance.
For the default administrative distances of different routing sources, refer to Table 7-3.
Table 7-3 Default Administrative Distances of Different Routing Sources

Routing Source Default Administrative Distance
Connected interface 0
Static route out an interface 0
Static route to a next hop 1
External BGP 20
OSPF 110
IS-IS 115
RIP v1, v2 120
EGP 140
Internal BGP 200
Unknown 255
72 SJ-20230719162004-003 | 2023-10-30 (R1.0)

7 IPv4 L3 Features
à The metric identifies the cost to reach the destination address directed by a route. Nor-
mally, the metric of a route is affected by such factors as hop count, bandwidth, line de-
lay, load, line reliability, and maximum transfer unit
Different dynamic routing protocols select one or more of these factors to calculate the
metric, for example, RIP uses the hop count to calculate the metric. The metric can on-
ly be comparable with other metrics in the same routing protocol. The routing metrics
calculated by different routing protocols are not comparable with one another, and such
metrics have no conversion relationship. The metric of static routes and directly connect-
ed routes is 0.
For a description of the characteristics of commonly-used paths for metric calculation, re-
fer to Table 7-4.
Table 7-4 Path Characteristics Descriptions

Characteristic Description
hop count Number of routers that a packet must pass before reaching the desti-
nation. The less the hop count is, the better the route is. A path is often
described by the hop count.
bandwidth Data transfer capability of links.
delay Time required for a packet to reach the destination address from the
source address.
load Number of network resources (such as routers) and activities on links
reliability Error rate on each link
MTU Maximum data unit that can be transferred by a port.
Each routing protocol selects one or more of these factors to calculate the metric.
 Route Matching Principles
Routers select routes according to the destination address, maximum matching, administra-
tive distance (priority), and metric.
The default route selection process is described as follows:
1. Routes are searched according to the destination address and the maximum matching
principle. Maximum matching refers to selecting the route with the longest subnet mask
directed to the same destination from the routing table during a route search.
2. If two or more routes are available, their administrative distances are compared. Different
routing protocols have different administrative distances. The shorter the administrative
distance is, the higher the priority is.
3. If the administrative distances are the same, the metrics of the routers are compared.
The lower the metric is, the higher the priority is.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 73

 Classification of Routing Protocols

à Addressing algorithm-based classification
By different addressing algorithms, dynamic routing protocols are classified into distance
vector routing protocols (such as RIP) and link-state routing protocols (such as OSPF
and IS-IS).
à AD-based classification
Large ISP’ networks may have thousands of routers, while most small LSPs’ networks
only have tens of routers. The internal network managed by an ISP is called administra-
tive domain. The connections between administrative domains and other ISPs are called
inter-domain connections. Therefore, the Internet can be regarded as a network formed
by interconnected domains.
Because the network is divided into administrative domains (AS), routing protocols, de-
pending on their application scopes, are classified into two types, namely, IGP intra-do-
main routing protocols (such as OSPF, RIP, and IS-IS), and EGP inter-domain routing
protocols (such as BGP).
à Routing type-based classification
The IP packets in the Internet are mostly point-to-point packets, or sometimes point-to-
multipoint packets, such as audio/video meetings (multimedia meetings) and IPTV. Uni-
cast and multicast routing protocols are respectively used for these two types of IP pack-
ets.
Unicast routing protocols, including RIP, OSPF, IS-IS, IGRP, and BGP, refer to the pro-
tocols that generate and maintain unicast routing tables.
Multicast routing protocols, including DVMRP, PIM-SM, PIM-DM, MOSPF, and MBGP,
refer to the protocols that generate and maintain multicast routing tables.
7.7 GRE
GRE Overview
General Routing Encapsulation (GRE) is submitted to IETF by Cisco corporation and Net-
smiths corporation in 1994. At present, network devices of many vendors support GRE tunnel
protocol. A tunnel means that PDUs of a protocol are encapsulated in PDUs of the same layer
protocol or a higher layer protocol.
GRE is a widely used technology that encapsulates PDUs of a network layer protocol in PDUs
of any other network layer protocol. It is usually used to establish a GRE tunnel to pass through
different Layer 3 networks. GRE supports to encapsulate messages of a protocol in messages
of another protocol and transmit the messages on networks. It can encapsulate the packets of
74 SJ-20230719162004-003 | 2023-10-30 (R1.0)

7 IPv4 L3 Features
some network layer protocols (such as IP and IPX), so that the encapsulated packets can be
transmitted through another network layer protocol (such as IP).
In general, system has a data packet which needs to be encapsulated and transmitted to some
destination. This data packet is called payload packet. Payload packet is firstly encapsulated in-
to a GRE data packet. The GRE data packet can be encapsulated into another kind of protocol
and then forwarded. The outer protocol is named as delivery protocol. The format of a GRE da-
ta packet after encapsulation is shown as Figure 7-7.
Figure 7-7 GRE Encapsulation
GRE tunnels can be divided into GRE over IPv4 tunnels and GRE over IPv6 tunnels. The
source and destination addresses of the two types of GRE tunnels are obtained through GRE
tunnel configurations.
GRE tunnels can also be divided into DS-Lite static tunnels and DS-Lite dynamic tunnels, which
are deployed in CGN. For a DS-Lite static tunnel, the source IP address and destination IP ad-
dress need to be manually configured, and for a DS-Lite dynamic tunnel, only the source IP ad-
dress needs to be configured.
GRE tunnel can be established on host-host, host-device, device-host and device-device. The
terminal of tunnel is the final destination of message or the message needs to be forwarded.
GRE over IPv4 Tunnel
When a GRE tunnel is configured, the device searches for the tunnel index at the ingress of the
tunnel. When it finds the outer IP destination and source addresses, it encapsulates an outer IP
header and a GRE header to the IP packet and then forwards the packets through the tunnel.
The device removes the outer IP header and the GRE header at the egress and then forwards
the common packet.
GRE over IPv4 Tunnel mainly includes tunnel encapsulation and de-encapsulation.
 Encapsulation procedure
1. When host or router is sending IPv4 flow, if message outgoing interface is tunnel inter-
face, verify tunnel type first. If it is GRE tunnel, do the encapsulation of IPv4 header, of
SJ-20230719162004-003 | 2023-10-30 (R1.0) 75

which IPv4 header source address and destination address are got by user manual con-
figuration.
2. After encapsulation, the message will be sent by the IPv4 message sending flow.
 De-encapsulation procedure
1. It is the reversed process of encapsulation. Router receives IPv4 data packet. If IPv4
header protocol number is 47, apply process function of each protocol of IPv4 registra-
tion, enter into GRE de-encapsulation flow, search for matched tunnel entry based on
source address and destination address of message. If it is found the IPv4 header and
GRE header encapsulated by tunnel are removed.
2. The remaining message is handled by IPv4 packet receiving flow.
GRE over IPv6 Tunnel
When a GRE tunnel is configured, the device searches for the tunnel index at the ingress of the
tunnel. When it finds the outer IP destination and source addresses, it encapsulates an outer IP
header and a GRE header to the source IP packet and then forwards the packets through the
tunnel.
The device removes the outer IP header and the GRE header at the egress and then forwards
the common packet.
GRE over IPv4 Tunnel mainly includes tunnel encapsulation and de-encapsulation.
 Encapsulation procedure
1. When host or router is sending IPv6 flow, if message outgoing interface is tunnel inter-
face, verify tunnel type first. If it is GRE tunnel, do the encapsulation of IPv4 header, of
which IPv4 header source address and destination address are got by user manual con-
figuration.
2. After encapsulation, the message will be sent by the IPv4 message sending flow.
 De-encapsulation procedure
1. It is the reversed process of encapsulation. Router receives IPv4 data packet. If IPv4
header protocol number is 47, apply process function of each protocol of IPv4 registra-
tion, enter into GRE de-encapsulation flow, search for matched tunnel entry based on
source address and destination address of message. If it is found the IPv4 header and
GRE header encapsulated by tunnel are removed.
2. The remaining IPv6 message is handled by IPv6 packet receiving flow.
GRE DS-Lite Tunnel
DS-Lite tunnels are used for IPv4 users to access an IPv4 Internet through an IPv6 network.
They can also be used for carrier-class IPv4 address multiplexing through IPv4-IPv4 NAT, and
tunnel encapsulation and decapsulation in the forwarding plane.
76 SJ-20230719162004-003 | 2023-10-30 (R1.0)

7 IPv4 L3 Features
7.8 ECMP
Description
In a network that has multiple links to the same destination and uses traditional routing technol-
ogy, packets are forward to the destination only by one link, while all other links are in stand-
by or invalid status. The dynamic switching between links takes certain time. In such a network,
ECMP (Equal-Cost Multi-path Routing) can be applied to use multiple links simultaneously, and
increase bandwidth. EMCP can back up the data transport on invalid link without any delay and
packet loss.
ECMP implements the load balance and link backup for multiple links of equal-cost. The OLT
supports the EMCP functions on static route and OSPF.
ECMP Forwarding
The OLT supports ECMP to balance traffic load. The OLT supports maximum eight equal-cost
paths for the traffics that are sent to the same destination by an interface. By using an algorithm
to calculate the Hash values of source and destination IP addresses, the OLT can implement
load balance between specified gateways.
7.9 VRF
Description
The kernel of VRF (Virtual Route Forwarding) is VR, which implements the function of multi-
ple virtual route devices on a single route device. On a route device, multiple layer 3 interfaces
are allocated to different VRFs to implement the function of virtual multiple route forwarding in-
stances.
The OLT supports to configure VRFs according to VLANs, which is the basis of layer 3 VPN
solution. The processing of all messages and relative protocols on an interface that belongs to
a VRF is only valid in the VRF, and is irrelevant to other VRFs. . VRFs separate services and
users, and save IP addresses.
The OLT implements layer 3 separation and independent message forwarding after multiple
virtual route devices (layer 3 VPNs) are configured on the OLT. In different VRFs, IP address-
es can be reused. The OLT supports DHCP relay multiple instances, route protocol multiple in-
stances, and independent route forwarding table.
An FTTx network supports two VRF application scenarios.
 GPON triple-play service is configured on the OLT. Different services are separated by
VRFs. All service use the same physical link for uplink. A VLAN interfaces only corresponds
SJ-20230719162004-003 | 2023-10-30 (R1.0) 77

to a VR. A uplink interface belongs to multiple layer 3 interfaces. Different VRs forward mes-
sages according to their learnt routes.
 GPON triple-play service is configured on the OLT. Different services are separated by
VRFs. All service use the two or multiple physical links for uplink. The links are in layer 3
mode.
The difference between these two scenarios is that dual links or multiple links are used for up-
link in the second scenario.
Principle
The VRF architecture is compatible with the VPRN (Virtual Private Routed Network) architec-
ture defined in RFC 2764.
Figure 7-8 shows the VRF architecture, an IP network architecture. Multiple L3VPNs should be
set up to separate users according to services or ISPs, or prevent users in different VPNs from
communicating with each other.
Figure 7-8 VRF Architecture
ZTE VRF Features
 Supports to create VRF instances.

Supports to create a VRF instance name by using CLI commands. The VRF name can be
configured, and is the identification of the VRF.
 Supports to add VLAN layer 3 interfaces and Loopback interfaces to a VRF instance.
à The OLT uses VLAN layer 3 interfaces to discriminate VRFs. A VRF may contains one
or several VLAN layer 3 interfaces. The VLAN layer 3 interfaces that belong the VRF
must use the layer 3 route forwarding table of the VRF to receive or transmit messages.
78 SJ-20230719162004-003 | 2023-10-30 (R1.0)

7 IPv4 L3 Features
The messages in the VRF must be forwarded among these VLAN layer 3 interface in the
VRF, and cannot be forwarded to a VLAN layer 3 interface that does not belong to the
VRF.
à When a Loopback interface is bound to a VRF instance, the loopback inteface supports
to process route protocol in the VRF.
à The IP addresses of VLAN layer 3 interfaces in different VRFs can be the same. The IP
addresses of VLAN layer 3 interfaces in a VRF must be different.
 Supports to separate internal ARP in different VRF.
ARP among VRFs are separated. Users in different VRFs may have the same IP address-
es.
 Different VRFs have independent ISIS, OSPF, RIP, or BGP route protocol progress.
 VRFs supports internal layer 3 DHCP Relay or DHCP Proxy.
The OLT supports DHCP configuration on a VLAN to implement DHCP Relay and DHCP
Proxy in a VRF.
 Supports Ping and Trace Route in a VRF.
Ping and Trace Route are basic network maintenance tools.
Ping is used to send Ping packets to a remote host, to check the network connection and
reachablility of the remote host.
Trace Route is use to check the packet route from the source host to the destination, to
check reachablility of the network connection, and locate the network fault.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 79

Chapter 8
IPv4 Routing Features
Table of Contents
OSPF.......................................................................................................................................... 80
IS-IS.......................................................................................................................................... 102
BGP.......................................................................................................................................... 116
8.1 OSPF
8.1.1 OSPF Overview

The Open Shortest Path First (OSPF) protocol, developed by the Internet Engineering Task
Force (IETF), is a link-state interior gateway protocol (IGP) used within an autonomous system
(AS). It makes routing decisions solely within a single AS. In an IP network, the OSPF dynami-
cally discovers and advertises routes by gathering and transferring link states information of an
AS.
8.1.1.1 Features of the OSPF

As a link-state routing protocol, the OSPF has the following features:
 Wide range of application: The OSPF supports networks of various scales.
 Selection of the best path: The OSPF selects a path based on bandwidth (or overhead).
 Fast convergence: When the network topology changes, the OSPF immediately sends an
update message to synchronize the change throughout an AS.
 No self-loop: The OSPF calculates routes by using a shortest path tree algorithm based on
the gathered link state information. Thus, self-loop can be avoided by the algorithm.
 Division of areas: The OSPF protocol allows an AS network to be divided into areas. Rout-
ing information exchanged between areas becomes simpler and thus less bandwidth is re-
quired.
 Equivalent route: The OSPF supports multiple equivalent routes to the same destination.
 Route grading: The OSPF uses four types of routes as follows (in descending order of priori-
ty): intra-area routes, inter-area routes, type 1 external routes, and type 2 external routes.
 Support for verification: The OSPF supports interface-based packet verification to guarantee
the security of route calculation.
80 SJ-20230719162004-003 | 2023-10-30 (R1.0)

8 IPv4 Routing Features
 Multicast transmission: On the link layer that provides multicast transmission capabilities,
the OSPF can send protocol messages with multicast addresses. Thus, the purpose of
broadcast is achieved, while interference to other network equipment can be minimized.
8.1.1.2 Basic Concepts of the OSPF

The basic concepts that help you understand the OSPF are as follows:
 Router-ID
A Router-ID is a 32-digit unsigned integer that uniquely identifies a router. Each router run-
ning the OSPF needs a Router-ID. Generally, a Router-ID should be manually configured to
the IP address of one of the interfaces of the router. The IP address is unique, and thus the
Router-ID is also unique.
If no Router-ID is manually configured, the router automatically selects an IP address from
existing interface IP addresses as its Router-ID. A ZTE router selects a Router-ID in compli-
ance with the following rules:
1. If loopback interface addresses are already configured on the device, the Router-ID
should be the minimum IP address among all the loopback interface addresses.
2. If no loopback interface is configured, the device selects the first activated interface IP
address as the Router-ID.
3. If multiple interfaces are activated, the device selects the minimum IP address among
them as the Router-ID.
A Router-ID is globally unique. Once an address is selected as the Router-ID, it will not
change unless the OSPF process is restarted.
 Interface (protocol interface)
A protocol interface refers to the interface running the OSPF protocol. It periodically sends
hello packets to discover neighbors.
 Designated router (DR) and backup designated router (BDR)
In a broadcast multi-channel access environment, a router must select a DR and a BDR
to represent the network. By selection of a DR and BDR, OSPF traffic in a LAN can be re-
duced.
 Neighbor and Adjacency
à After an OSPF router is started, it sends a hello packet through the OSPF interface to
the outside. When the hello packet is received by another OSPF router, the latter checks
the parameters defined in the packet. If the parameter definitions on both sides are con-
sistent, a neighbor relation is established between the two routers.
à When the link state information database is synchronized based on the neighbor relation,
an adjacency relation is established between the two routers.
 Neighbor database
SJ-20230719162004-003 | 2023-10-30 (R1.0) 81

A neighbor database includes all neighbors of a router.

 Link state database
A link state database includes the link state information of all routers in the network, and
it represents the topology of the whole network. All the routers in the same area share the
same link state database.
 Routing table
A routing table, also called forwarding table, is calculated with the SPF algorithm based on
the link state database.
8.1.1.3 OSPF Protocol Packet

Overview
An OSPF protocol packet is encapsulated by an IP packet, with the protocol number of "89".
Packet Format
For the general format of an OSPF packet, refer to Table 8-1.
Table 8-1 General Format of an OSPF Packet

Domain Length Field
(Number of Bytes)
1 Version
1 Type
2 Packet Length
4 Router ID
4 Area ID
2 Checksum
2 Authentication type
8 Authentication
Variable Data
 Version No.: identifies the version number of the OSPF protocol. For example, for OSPFv2,
the value is 2.
 Type: identifies the type of an OSPF packet, range: 1-5 (respectively corresponding to an
Hello, DD, LSR, LSU, and LSAck packet.
 Packet length: identifies the total length of an OSPF packet, including the packet header,
unit: byte.
 Router ID: identifies the router from which an OSPF packet is initiated.
82 SJ-20230719162004-003 | 2023-10-30 (R1.0)

 Area ID: identifies the area where an OSPF data packet is located. Each OSPF data packet
is associated with one area.
 Checksum: checks the contents of a data packet to detect potential damages during trans-
mission.
 Authentication type (AuType): identifies an authentication type. The value "0" indicates no
authentication. The value "1" indicates authentication in plain text mode. The value "2" in-
dicates authentication with the MD5 algorithm. All the information exchanged by the OSPF
protocol can be authenticated, and the authentication type can be configured by area.
 Authentication: Contents of authentication. This parameter varies with authentication types.
For authentication type 0, this parameter is not defined. For authentication type 1, this para-
meter is the password information. For authentication type 2, this parameter includes a Key
ID, the length of MD5 authentication data, and a serial number (MD5 authentication data is
excluded.)
 Data: Different types of protocol packets may encapsulate different data.
Packet Type
OSPF packets can be divided into five types. They are described as follows:
 Hello Packet
A router periodically sends a hello packet to its neighbors to discover and maintain an OSPF
neighbor relation. A hello packet contains a Router-ID, timer (Hello/dead intervals), known
neighbors (Neighbors), Area-ID, router priority, DR IP address, BDR IP address, authentica-
tion password, and a stub area flag. Among them, the Hello/dead intervals, Area-ID, Authen-
tication password, and stub area flag must be consistent on both sides so that two adjacent
routers can establish a neighbor relation.
 Database Description (DBD) Packet
When two routers synchronize their databases, each of them uses a DBD packet to de-
scribe its Link State Database (LSDB). The packet includes the abstract of each Link State
Advertisement (LSA) in the LSDB (the abstract refers to the head of an LSA, which unique-
ly identifies the LSA.) As the head of an LSA only takes a small part of the whole LSA, infor-
mation exchanged between the routers is greatly reduced. Based on the head, the remote
router can determine whether it already has the LSA.
 Link State Request (LSR) Packet
After exchanging a DBD packet with another router, a router knows which LSAs that the re-
mote router has do not exist in the local LSDB, or which LSAs are updated by the remote
router. Then, the local router sends an LSR packet to the remote router to request desired
LSAs. The LSR packet contains the abstracts of the desired LSAs.
 Link State Update (LSU) Packet
SJ-20230719162004-003 | 2023-10-30 (R1.0) 83

A router sends an LSU packet to the remote router that contains the LSAs required by the
remote router. The LSU packet is a set of LSAs (all contents).
 Link State Acknowledgment (LSAck) Packet
Upon receiving a DBD or LSU packet, a router sends an LSAck packet to acknowledge the
received packet. The LSAck packet contains the head of each LSA to be acknowledged
(One LSAck packet can acknowledge more than one LSA.)
8.1.2 Network Types of the OSPF

The OSPF protocol calculates routes based on the topology of the surrounding network of the
local router. A router works out the topology of its surrounding network, and transfers the topol-
ogy information to all the other routers.
8.1.2.1 Network Types
Four Network Types
The OSPF defines four topological network types as follows:

 Stub Networks: The network segment connected to an interface only contains the local
router.
 Point-to-point (P2P): An interface is connected to a router through a P2P network.
If the link layer protocol is PPP or HDLC, the OSPF assumes that the network type is P2P
by default. In this type of networks, the OSPF sends protocol packets in multicast mode
(224.0.0.5).
 Broadcast or NBMA Networks: An interface is connected to multiple routers through a
broadcast or NBMA network.
à If the link layer protocol is Ethernet or FDDI, the OSPF assumes that the network type is
Broadcast by default. In this type of networks, the OSPF sends protocol packets in multi-
cast mode (224.0.0.5 and 224.0.0.6).
à If the link layer protocol is frame relay, ATM, or X.25, the OSPF assumes that the net-
work type is NBMA by default. In this type of networks, the OSPF sends protocol packets
in unicast mode.
 Point-to-multipoint (P2MP): An interface is connected to multiple routers through a P2MP
network.
No link layer protocol is assumed as of the P2MP type by default. The P2MP type must be
compulsorily changed from other network types. Generally, a P2MP network is changed
from an NBMA network. In this type of networks, the OSPF sends protocol packets in multi-
cast mode (224.0.0.5) by default, or in unicast mode as required by a customer.
84 SJ-20230719162004-003 | 2023-10-30 (R1.0)

About NBMA
The NBMA means a non-broadcast multi-point reachable network, such as the an X.25 or
Frame Relay network. In this type of networks, to minimize the number of routing information
exchanges, a DR is elected, and other routers exchange routing information only with the DR.
There is a prerequisite for this: The NBMA network must be fully meshed. That is, a directly
reachable virtual circuit exists between any of the routers in the network.
For cost or other reasons, however, a fully meshed network is almost impossible in reality. In a
non-fully meshed network, routing information may not be exchanged properly or routing calcu-
lation may be wrong due to the election of a DR. To solve this problem, the OSPF protocol de-
fines a P2MP network type. If no directly reachable link exists between some routers, the corre-
sponding interfaces are configured as the P2MP type (If a router has only one peer in an NBMA
network, the corresponding interface can also be configured as the P2P type.)
Differences Between an NBMA Network and a P2MP Network
The differences between an NBMA network and a P2MP network are as follows:
 In the OSPF protocol, an NBMA is a fully meshed non-broadcast multi-point reachable net-
work, while a P2MP network is not necessarily full meshed.
 A DR or BDR is required in an NBMA network, while it is not required in a P2MP network.
 The NBMA is a default network type, such as the link layer X.25 or Frame Relay type, and
the OSPF assumes the network type of such an interface is NBMA by default (no matter
whether the network is fully meshed or not, which cannot be determined by the link layer).
The P2MP is not a default network type, and no link layer protocol is assumed to be point-
to-multipoint. The P2MP type must be compulsorily changed from other network types. Gen-
erally, a P2MP network is changed from a non-fully meshed NBMA network.
 An NBMA network sends protocol packets in unicast mode, which requires that neighbors
be manually configured. A P2MP network can send protocol packets in both unicast and
multicast mode.
8.1.2.2 DR and BDR
Overview of DR, BDR, and DR Other
In a broadcast or NBMA network, routing information should be exchanged between any two
routers. Suppose there are N routers in the network. Then " N × (N-1)/2 " adjacency relations
must be established. When a route of a router changes, the routing change information should
be exchanged " N × (N-1)/2 " times in the corresponding network segment, which is unneces-
sary and wastes bandwidth resources.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 85

To solve this problem, the OSPF protocol designates a router as the Designated Router (DR
) to exchange information. Each of the other routers only sends routing information to the DR,
and then the DR forwards the routing information to the other routers in the same network seg-
ment. As a result, two routers that are not a DR (they are called "DR Other") will not establish
adjacency relations or exchange routing information between each other. Thus, only N adjacen-
cy relations need to be established for the routers in a network segment, and routing change in-
formation only needs to be exchanged for 2N times.
A BDR is a backup for the DR. The BDR is elected together with the DR. The BDR also estab-
lishes an adjacency relation with each of the other routers in the same network segment and
exchanges routing information with them. When the DR fails, the BDR immediately replaces
the DR to become a new DR. As no re-election is needed and adjacency relations are already
established, the replacement process is very short. In that case, it is also required to re-elect a
new BDR, and the re-election process does not affect route calculation.
In an OSPF network, a router that is not a DR or BDR is called a DR Other. A DR Other only
establishes adjacency relations with a DR and BDR, and no routing information is exchanged
between DR Others. Thus, network traffic is reduced and bandwidth resources are saved.
DR/BDR Election Process
Which router acts as the DR in a network segment is not manually designated, but elected by
all the routers in the segment. The DR election process is as follows:
1. Register voters: all routers running the OSPF in the network segment
2. Register candidates: all OSPF routers with a priority higher than 0 in the network segment.
The priority is a parameter on an interface. It can be manually configured, and the default
value is 1. If the priority of a router interface is 0, it cannot be elected to be the DR or BDR of
the connected network segment.
3. Campaign speech: If an OSPF router with a priority higher than 0 considers itself as the DR,
it sends an OSPF Hello packet to the other routers to claim that it is the DR in this network
segment.
4. Voting: Among all the routers that claim themselves as a DR, the router with the highest
priority is elected to be the DR. If two candidate routers are of the same priority, the router
with a larger Router-ID is elected to be the DR. A vote is an OSPF Hello packet. Each router
writes the desired DR into a Hello packet and sends it to any of the other routers in the net-
work segment.
Features of a DR/BDR
 A DR can only be elected on a broadcast or NBMA interface, and it need not be elected on
a P2P or P2MP interface.
86 SJ-20230719162004-003 | 2023-10-30 (R1.0)

 When a new OSPF router joins in a network segment, it does not immediately participate in
DR election, but tries to identify whether there is an existing DR in the network segment. If
there is an existing DR, the new router will not claim itself to be a DR, even if its priority is
higher than the priority of the DR. Thus, a DR change is avoided.
 The DR in a network segment is not necessarily one with the highest priority. Similarly, the
BDR is not necessarily the router with the second highest priority.
 The BDR is elected together with the DR. The BDR also establishes an adjacency relation
with each of the other routers in the same network segment and exchanges routing informa-
tion with them. When the DR fails, the BDR immediately replaces the DR to become a new
DR without re-election.
 A DR is specific to a network segment and based on an interface of a router. A router may
be a DR on one of its interfaces, and be a BDR or DR Other on another interface.
 Two DR Other routers do not exchange routing information with each other, but they still
send Hello packets to each other. The neighbor state between them is always 2-Way.
8.1.3 OSPF Route Calculation Process

An OSPF router establishes an adjacency relation with another OSPF router. Then both routers
synchronize their link state databases to obtain an LSDB. Finally, the SPF algorithm is used to
calculate an OSPF route.
8.1.3.1 Neighbor State Machine

Figure 8-1 shows the neighbor state changes of an OSPF router. It indicates all the possible
states of the OSPF router during the establishment of an OSPF adjacency relation.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 87

Figure 8-1 OSPF Neighbor State Machine
 Down: initial state of a router. It means that the router has not received any Hello packet
from the peer within the Dead Interval or the router is restarted.
 Attempt: It is applicable only to NBMA interfaces. A router in this state periodically sends a
Hello packet to manually configured neighbors.
 Init: A router in this state has received a Hello packet from a neighbor, but the neighbor list
in the packet does not include the Router-ID of this router (that is, the peer does not receive
a Hello packet from the router.)
 2-Way: A router in this state has received a Hello packet from a peer and they establish an
adjacency relation. In a broadcast or NBMA network, two routers whose interface status is
"DR Other" stay in 2-Way state.
 ExStart: A router in this state exchanges a DBD packet (only including some flag bits, with-
out actual contents) with its neighbor to determine the master/slave relation in transmission.
The establishment of the master/slave relation is to guarantee ordered exchange of subse-
quent DBD packets.
 Exchange: A router in this state describes the local LSDB with a DBD packet, and sends it
to the neighbor.
 Loading: A router in this state sends an LSR packet to request the neighbor for the peer's
DBD packet.
 Full: A router in this state obtains all the LSA information in the LSDB of the neighbor router.
That is, the local router and the neighbor router reach the adjacency state.
88 SJ-20230719162004-003 | 2023-10-30 (R1.0)

8.1.3.2 Establishing a Neighbor Relation

Figure 8-2 shows how to establish an OSPF neighbor relation between two routers.
Figure 8-2 Establishing an OSPF Neighbor Relation
When an OSPF router is started, it starts exchanging hello packets with neighbor routers (con-
figured with the OSPF process). The exchange process after initial startup of the router is as
follows:
1. When router A is started in the network, it does not exchange information with other routers,
so it is in down-state state. Then router A starts to send hello packets through the interface
running the OSPF process, although it does not know any router or which router is a DR.
The hello packets are sent by the multicast address 224.0.0.5.
2. After receiving a hello packet, an OSPF router directly connected to router A adds the ID of
router A to its neighbor list. At that time, the router is in init-state state.
3. The OSPF router directly connected to router A returns a unicast hello packet to router A. In
the hello packet, the neighbor field carries all the known router IDs, including the ID of router
A.
4. Whenever receiving a hello packet, router A adds each router containing its own router ID
into its neighbor list. Then router A is in two-way state. Now, router A establishes a two-way
communication with each router in the neighbor list.
5. If the network type is broadcast, it is required to elect a DR and BDR. The DR will establish
an adjacency relation with each of the other routers.
6. Routers periodically (every 10 seconds by default in a broadcast network) exchange hello
packets in the network to ensure normal communication.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 89

8.1.3.3 Synchronizing Link State Databases

Once a DR and a BDR are selected, routers enter "quasi-start" state, and they are ready to dis-
cover related network link state information and generate their own link state databases. The
first step in this process is that the DR and BDR establish an adjacency relation with each of the
other routers in the network. Once adjacent routers are in Full state, the switching protocol will
not be executed repeatedly, unless the Full state changes.
The following takes Figure 8-3 as an example to describe the protocol switching process.
Figure 8-3 Synchronizing OSPF Link State Databases - 1
1. In "quasi-start" state, the DR and BDR establish an adjacency relation with each of the oth-
er routers in the network. During this process, each of the other routers establishes a mas-
ter/slave relation with the adjacent DR and BDR, and the router with a greater Router-ID be-
comes the master router.
2. The master router and slave router exchange one or more DBD messages. Then the routers
are in Exchange state.
A DBD message includes the head information of each LSA entry in the link state database
of a router. An LSA entry is the information about a link or network. The header of each LSA
entry includes the link type, the address of the router advertising the information, link over-
head, and the serial number of the LSA. The serial number of an LSA is used by a router to
identify the time order of received link state information.
3. After receiving a DBD message from its peer, router A processes it as shown in Figure 8-4.
90 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Figure 8-4 Synchronizing OSPF Link State Databases - 2
a. Router A returns a link state acknowledgement message (LSAck) to acknowledge the re-
ception of the DBD message, corresponding to the serial number of the DBD message.
b. By checking the serial number of the header of the LSA in the DBD message, router A
compares the received information with existing information. If the DBD message has an
updated link state entry, router A sends a data state request message (LSR) to router B.
When the LSR is being sent, the routers are in Loading state.
c. Router B returns a link state update message (LSU), which contains the complete in-
formation about the requested entry. Upon receiving the LSU, router A sends an LSAck
message again.
4. Router A adds the new link state entry into its link state database.
When all the LSRs between router A and router B are properly replied, both routers are syn-
chronized and enter Full state. Before forwarding data, a router must enter Full state.
8.1.3.4 Calculating Routes

The OSPF route calculation process in an area is as follows:
1. Each OSPF router generates an LSA based on its surrounding network topology, and sends
the LSA through an update message to other OSPF routers in the network.
2. Each OSPF router gathers the LSAs advertised by the other routers, and all the LSAs com-
pose an LSDB. An LSA describes the surrounding network topology of a router, while an
LSDB describes the network topology of an autonomous system.
3. An OSPF router converts its LSDB into a weight-based directed graph, which is the actual
reflection of the whole network topology. The directed graph obtained by each router is total-
ly identical.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 91

Note
By default, the COST value of the OSPF network is equal to 10 to the 8th power divided by the link
bandwidth. In the ZXR10, the COST value to a destination is the sum of COST values on all the
egresses along the forwarding path.
4. Based on the directed graph, each router uses the SPF algorithm to calculate the shortest
path tree, assuming itself as the root. The shortest path tree is the set of routes to all the
nodes in the autonomous system.
8.1.4 Division of OSPF Areas

As the network size grows gradually, the number of routers in the network also increases. If all
the routers in a huge network run the OSPF protocol, the following problems may be experi-
enced:
 Each router keeps the LSAs generated by all the other routers in the network, and these
LSAs compose an LSDB. As a result of the increase in the number of routers, the LSDB be-
comes very huge and occupies much storage space.
 The huge LSDB makes it more difficult to run the SPF algorithm, and thus CPU load be-
comes heavier.
 The huge LSDB requires longer time to achieve LSDB synchronization between two routers.
 After the network size increases, the topology is more liable to change. To synchronize the
changes, many OSPF messages are transmitted in the network, and thus the network band-
width utilization decreases. Whenever the topology changes, all the routers in the network
have to re-calculate the routes.
The OSPF solves the above problems by division of areas. The division of areas can reduce
the number of LSAs and narrow the range affected by network changes.
8.1.4.1 Division of Areas
Example
Routers are logically divided into different groups (or areas), and each group is identified by an
area ID. In Figure 8-5, routers A, B, C, and D are in Area 0, routers I, J, K, and L respectively
belong to Area 1, 2, 3, and 4. Area 0 is called the backbone area.
92 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Figure 8-5 Division of OSPF Areas
The boundary of an area is a router, not a link. A router can belong to different areas, but a net-
work segment (or link) can only belong to one area. That is, each router interface running the
OSPF must be specified with only one area.
If an autonomous system is divided into multiple areas, one of them must be the backbone
area, and the other areas must be directly or logically connected to the backbone area. In addi-
tion, the backbone area it must be connected.
Router Types
Based on the positions of routers in an AS, the OSPF divides routers into four types:
 Internal Area Router (IAR)
All the interfaces of an IAR belong to the same OSPF area. In the above figure, routers A, B,
C, D, I, J, K, and L area IARs.
 Area Border Router (ABR)
An ABR belongs to two or more areas, but one of them must be a backbone area. In the
above figure, routers E, F, G, and H area ABRs. An ABR connects a backbone area with a
non-backbone area. It has a physical or logical connection with the backbone area.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 93

 BackBone Router (BBR)

A BBR has at least one interface that belongs to a backbone area. Thus, all ABRs and the
routers within Area 0 are BBRs. In the above figure, routers A, B, C, D, E, F, G, and H are
BBRs.
 AS Boundary Router (ASBR)
An ASBR exchanges routing information with other ASs. An ASBR is not necessarily on the
boundary of an AS. It can be either an IAR or an ABR. As long as an OSPF router redistrib-
utes routing information from the outside, it is an ASBR. In the above figure, routers H and C
are ASBRs.
Purposes of Area Division
Due to area division, an ABR that generates LSAs based on the routes in the local area can ag-
gregate these routes by IP address before generating an LSA. Thus, the number of LSAs in an
AS is minimized.
After area division, a change to the network topology is synchronized first within the local area.
If the change affects the aggregate route, the ABR will advertise the change to other areas.
Most topological changes are inside the area, which reduces the impact on the routers in other
areas.
8.1.4.2 Virtual Link

The topology in some networks is so complex that area division cannot meet the requirement
that each area be directly connected to the backbone area. The OSPF uses a virtual link to
solve this problem.
A virtual link is a logical channel established between two ABRs through a non-backbone area
(also called a transit area), and it must be configured on both ABRs. Figure 8-6 shows that a
virtual link is established between router C and router E, so that area 3 is logically connected to
backbone area 0. In this example, area 1 is a transit area.
94 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Figure 8-6 Example of a Virtual Link
A logical channel means that the other OSPF router between the two ABRs only forwards pack-
ets (The destination address of a protocol packet is not this router. Thus, the packet is transpar-
ent to the router, and the router only forwards it as a common IP packet.)
A virtual link is like a point-to-point link between the two ABRs. Therefore, various parameters
can be configured on a virtual link like those on a physical interface.
8.1.4.3 LSA Classification

The OSPF is a link-state routing protocol, and routing information is encapsulated in LSAs and
sent out. Depending on purposes, LSAs are generally classified into six types as follows:
 Router LSA (Type=1)
A router LSA is a basic LSA. All OSPF routers can generate this type of LSAs. A router LSA
describes the connection and cost of an OSPF interface on a local router. An ABR gener-
ates a router LSA for each of the areas connected to the ABR. This type of LSAs are propa-
gated within the area that a router belongs.
 Network LSA (Type=2)
A network LSA is generated by a DR. In a broadcast or NBMA network, after a DR is elect-
ed, the packet sending mode and the description of link states are both changed. A router
LSA generated by a DR Other or BDR only describes connections to the DR, while the DR
uses a network LSA to describe all the routers that have established an adjacency relation
with the local network segment (The Router-IDs of these routers are listed.) This type of
LSAs are propagated within the area that a router belongs.
 Network Summary LSA (Type=3)
SJ-20230719162004-003 | 2023-10-30 (R1.0) 95

A network summary LSA is generated by an ABR. After an ABR completes route calcula-
tion within one of the areas that it belongs, the ABR queries a routing table, encapsulates
each OSPF route in this area into a network summary LSA, and sends it to another area.
The LSA describes the destination address, mask, and cost of the route. This type of LSAs
are propagated in all the areas connected to the ABR except the area where the LSA is gen-
erated.
 ASBR Summary LSA (Type=4)
An ASBR summary LSA is generated by an ABR. It describes the routes of ASBRs going
to a local area. This type of LSAs have basically the same contents as Type 3 LSAs. The
only difference is that the destination addresses in Type 4 LSAs are ASBRs or hosts, and
thus the mask is 0.0.0.0. This type of LSAs are propagated within the same scope as Type 3
LSAs.
 AS External LSA (Type=5)
An AS external LSA is generated by an ASBR. It describes the information about exter-
nal routes beyond an AS. The LSA describes the destination address, mask, and cost of
a route. Type 5 LSAs are the only type unrelated to specific areas. This type of LSAs are
propagated within the whole AS (except STUB areas).
 AS External LSA (Type=7)
An AS external LSA is generated by an ASBR in an NSSA area. It describes the routes
to other ASs beyond the local AS. This type of LSAs are propagated only within an NSSA
area.
8.1.4.4 Calculating Inter-Area Routes

After the OSPF divides an AS into different areas, route calculation also changes:
1. Only the routers in the same area maintain synchronization of their LSDBs, and a change to
the network topology is updated first in this area.
2. Inter-area route calculation is implemented by an ABR. After an ABR completes route cal-
culation within an area, the ABR queries a routing table, encapsulates each OSPF route in
the area into a Type 3 LSA, which includes the destination address, mask, and cost of this
route. Then the ABR sends all these LSAs to another area.
3. A router in the other area generates a route based on each Type 3 LSA. The routing infor-
mation is all advertised by the ABR, so the next hop of all these routes should be the ABR.
8.1.4.5 Classification of OSPF Areas

Overview
To simply calculation and configuration, the OSPF defines several commonly used area types
as follows: stub area, totally stubby area, and NSSA.
96 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Stub Area
If there is no ASBR in a non-backbone area, routers in the area only have one channel to the
outside of the AS, that is, through an ABR. Thus, the routers send all the LSAs intended for un-
known hosts beyond the AS to this ABR. In that case, type 5 LSAs need not be propagated in
this area, and type 4 LSAs also do not exist in this area. This area is called a stub area.
In a stub area, all the routers must be configured as stub routers. An OSPF hello packet con-
tains a stub area flag, which must be set consistently at both ends that establish a neighbor re-
lation.
The ABR in a stub area can filter all type 5 LSAs, so that they cannot be advertised to the stub
area. In addition, the ABR can generate a Type 3 LSA, and advertise a default route to external
destinations to other non-ABR routers in the area. The default route is pointed to the ABR itself.
Figure 8-7 illustrates features of a stub area: Generally, a stub area only has one egress. There
is no ASBR in the area. The area is not Area 0.
Figure 8-7 Example of a Stub Area
Totally Stubby Area
In a stub area, if the ABR also filters Type 3 LSAs and only advertise a default route to external
destinations (the route is pointed to the ABR), the area is called a totally stubby area, see Fig-
ure 8-8.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 97

Figure 8-8 Example of a Totally Stubby Area
Not-So-Stubby Area (NSSA)
A stubby area does not allow Type 5 LSAs. Therefore, an ASBR is not part of a stubby area.
However, it is expected to create an ASBR-enabled stubby area in reality. Routers in this area
receive external routes from the ASBR, but external routing information from other areas is
blocked.
To achieve this purpose, the OSPF defines a not-so-stubby area (NSSA), see Figure 8-9. In the
NSSA, the ASBR generates Type 7 instead of Type 5 LSAs. The ABR cannot propagate type
7 LSAs to other OSPF areas. The ABR blocks external routes to the NSSA area on the border.
Meanwhile, the ABR converts Type 7 LSAs into Type 5 LSAs and propagates them to other ar-
eas.
98 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Figure 8-9 Example of an NSSA
8.1.5 External Communication of OSPF Beyond an AS

AS Concept
OSPF is an internal routing protocol and calculates the routes in an AS. An AS is a set of con-
nected routers running OSPF. For OSPF, the whole network is only divided into an AS-internal
part and an AS-external part.
It should be noted that the AS-external part is not necessarily located outside an AS physically
or topologically. It, however, refers to those routers that do not run OSPF or those routers that
run OSPF but do not have OSPF interfaces.
ASBR Functions
OSPF is an IGP, but it still needs to learn the routing information outside an AS. The routing in-
formation is obtained by an ASBR, which redistributes the routes discovered by other routing
protocols (including static route and direct routes of interfaces) to OSPF routers.
It should be noted that an ASBR is not necessarily located on the border of an AS. It can be lo-
cated anywhere in an AS.
In the calculation of the routes outside an AS, an ASBR generates a Type 5 LSA for each redis-
tributed route. The LSA contains the destination address, mask, and cost of this route. The rout-
ing information of these external routes is propagated throughout the AS except sub areas.
Due to division of areas, when calculating routes, a router that is not in the same area as the
ASBR cannot know the exact location of the ASBR (The information is filtered by an ABR,
which then generates a Type 3 LSA based on the existing routes in the local area.) To solve
SJ-20230719162004-003 | 2023-10-30 (R1.0) 99

this problem, OSPF defines the following rule: If there is an ASBR in an area, ABRs in this area
must separately generate a Type 4 LSA for the ASBR when generating routing information for
other areas. The LSA contains the Router-ID of the ASBR and the cost to reach the ASBR.
Hierarchical Route Management
OSPF divides routes into four levels as follows (in descending order by priority):
 Intra-area routes
 Inter-area routes
 Type 1 external routes
 Type 2 external routes
Intra-area routes and inter-area routes have the same priority (default: 10). Type 1 and type 2
external routes have the same priority (default: 150).
OSPF divides external routes redistributed from the outside of an AS into two types: type 1 ex-
ternal routes and type 2 external routes.
 Type 1 external routes are redistributed IGP routes (such as RIP and STATIC routes). This
type of routes is more reliable. The cost for a type 1 external route is of the same magni-
tude as that of a route inside an AS. That is, the cost of a type 1 external route is equal to
the cost of the route from a router to the corresponding ASBR plus that from the ASBR to
the external destination.
 Type 2 external routes are redistributed BGP routes. This type of routes is not so reliable.
Thus, OSPF assumes that the cost of the route from an ASBR to an external destination
is much greater than that from a router to the ASBR. In route cost calculation, the former
cost is mainly calculated, that is, the cost of a type 2 external route is equal to the cost of the
route from an ASBR to an external destination. If two type 2 external routes have the same
cost as calculated in that way, the costs of their internal routes to the corresponding ASBRs
are then compared.
8.1.6 Other Common Functions of OSPF

Route Aggregation
OSPF divides an AS into different areas for minimizing the size of routing information and rout-
ing tables. Route aggregation is used to achieve this purpose. After an ABR completes route
calculation within an area, the ABR queries a routing table, encapsulates each OSPF route in
this area into a Type 3 LSA, and sends it to another area.
Figure 8-10 shows that router A in Area 1 has six intra-area routes including 172.16.8.0/22,
172.16.12.0/22, 172.16.16.0/22, 172.20.0/22, 172.16.24.0/22, and 172.16.28.0/22. Normally,
router A should generate six Type 3 LSAs for the six routes. If route aggregation is configured,
100 SJ-20230719162004-003 | 2023-10-30 (R1.0)

the six routes can be aggregated into two routes 172.16.8.0/21 and 172.16.16.0/20, and thus
only two LSAs are generated for the two aggregate routes on router B.
Figure 8-10 Example of Route Aggregation
Note: Route aggregation is valid only if it is configured on an ABR. Route aggregation may
cause route black holes.
Route Load Sharing
It is allowed to configure multiple routes with the same destination and priority in OSPF. Pack-
ets to the same destination are forwarded through different paths to achieve network load shar-
ing.
Figure 8-11 shows that OSPF discovers two routes to the same destination address
10.2.2.1/30:
IPv4 Routing Table:
Dest Mask Gw Interface Owner pri metric
10.2.2.0 255.255.255.252 30.0.1.2 Int1 ospf 110 2
10.2.2.0 255.255.255.252 40.0.0.2 Int2 ospf 110 2
If these OSPF routes have the highest priority among existing routing protocols on the router, IP
traffic load sharing from router A to router B can be achieved on the routing layer. The traffic to
the destination address 10.2.2.1/30 is forwarded through link 1 and link 2 to router B.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 101

Figure 8-11 Example of OSPF Route Load Sharing
OSPF Graceful Restart
In most cases, random interruptions of routers are unpredictable. As a result, data stream for-
warding interruptions and route flapping may occur. If the control functions of a router are sepa-
rated from forwarding functions, the impact of interruption events on router restart and its neigh-
bors can be minimized by the policy called "graceful restart".
The graceful restart process in OSPF is as follows:
1. Within a short period of OSPF restart, other routers in the network still maintain the old link
states.
2. The restarted router maintains the old Forwarding Information Base (FIB) for a short period,
so that data stream forwarding is not affected.
3. After the router is restarted, it quickly synchronizes the LSP/LSA database with its neigh-
bors.
4. After LSP/LSA database synchronization is completed, route calculation based on the SPF
algorithm is performed.
By the configuration of a graceful restart policy, the restarted OSPF router maintains the for-
warding function during the restart process, and neighbor routers also maintain normal process-
ing. Thus, route flapping can be prevented.
Downbit
When an MP-BGP route is redistributed to a VRF instance in OSPF and an LSA is generated
accordingly, the "downbit" in the option field in the header of a Type 3 or Type 5 LSA is set (dis-
played as "Downward"). Thus, route loops can be prevented.
When a PE router detects an LSA with "downbit", the LSA will not participate in OSPF route cal-
culation. When an OSPF route is redistributed to BGP, the LSA with "downbit" will not be redis-
tributed as a BGP route.
8.2 IS-IS
102 SJ-20230719162004-003 | 2023-10-30 (R1.0)

8.2.1 IS-IS Overview

IS-IS Protocol
Intermediate System-to-Intermediate System (IS-IS), proposed by the International Organiza-

tion for Standardization (ISO), is a route protocol used for Connectionless Network Service (
CLNS). IS-IS is a network layer protocol of the Open System Interconnection (OSI) protocol.
By expanding the IS-IS protocol, IP routing is supported, an integrated IS-IS protocol is formed.
The IS-IS protocol is the integrated IS-IS protocol.
As an Interior Gateway Protocol (IGP), the IS-IS is widely used on networks. The operation
mechanism of the IS-IS protocol is similar to that of the OSPF. The IS-IS divides a network into
multiple areas. Routers in one area only manage the routing information about the correspond-
ing area. In this way, router costs are reduced. The IS-IS can satisfy the requirements of a mid-
dle or a large-scale network.
The IS-IS protocol also uses the Dijkstra SPF algorithm to calculate the topology. Based on the
link state database and the topology architecture calculated in accordance with the SPF algo-
rithm, the IS-IS protocol selects the optimized route and then adds this route to the IP routing
table.
NSAP Address
A network device has a link layer address and a network layer address. The link layer address
in an IP network is consistent with that in a CLNS network, but the encoding schemes of the
network layer addresses are different in the two networks. In an IP network, an L3 address is
a common IPv4 (32-bit) or IPv6 (128-bit) address. In an ISO CLNS network, an L3 address is
called a CLNP address, which is also called a Network Service Access Point (NSAP) in the IS-
IS protocol.
An NSAP address is a network address, or a NET address. Composed of 8 to 20 bytes, an
NSAP address describes the area ID and system ID of a device. The format of an NSAP ad-
dress is flexible and extensible. Generally, a system ID is 6-byte long, and it can use the MAC
address of an interface.
An NSAP is composed of an Initial Domain Part (IDP) and a Domain Specific Part (DSP), see
Figure 8-12. An IDP is equivalent to the main network number of an IP address, and a DSP is
equivalent to the subnet number, host address, and port number of an IP address.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 103

Figure 8-12 NSAP Address Structure
An IDP, which is defined by the ISO, is composed of an Authority and Format Identifier (AFI)
and an Initial Domain Identifier (IDI). An AFI indicates the address allocation organization and
address format, and an IDI indicates a domain.
A DSP is composed of a High Order DSP (HODSP), a system ID, and an NSEL:
 A HODSP is used to distinguish areas.
 A system ID is used to distinguish hosts.
 An NSEL indicates the service type.
Generally, the IDP and the HODSP in the DSP are uniformly called an area ID. The length of an
area ID is variable, ranging from 1 to 13 bytes.
A system ID uniquely identifies a host or router in an area, and it is always 6-byte long (48 bits).
The function of an NSAP Selector (NSEL) is similar to a "protocol identifier" in the IP protocol.
The NSEL varies with transmission protocols. For the IP protocol, the NSEL is 00.
IS-IS Area
If a set of routers have the same area ID, they belong to the same area. The division of areas
in the IS-IS is based on links, not based on interfaces as the division of areas in the OSPF, see
Figure 8-13. An IS-SI router totally belongs to an area.
104 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Figure 8-13 Hierarchical Structure of an IS-IS Network
The IS-IS protocol uses a two-layer routing system. A level-1 router only knows the topology in
the local area, including all the routers and hosts, and does not know the routers or destinations
beyond the area. A level-1 router forwards all the traffic going to other areas to the nearest lev-
el-1-2 router in the local area, which knows the level-2 topology.
A level-1-2 router is a border router between different areas and provides connections between
them. A level-2 backbone area is actually a virtual IS-IS area composed of routers that partici-
pate in level-2 route selection.
In an IS-IS network, a level-2 area must be continuous, and all the routers in the area must be
fully interconnected.
The neighbor relation that can be established between routers is described as follows:
 Two level-1 routers can establish a level-1 neighbor relation only if their area IDs are the
same.
 Two level-2 routers can establish a level-2 neighbor relation no matter whether their area
IDs are the same.
 A level-1 router and a level-1-2 router can establish a level-1 neighbor relation only if their
area IDs are the same.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 105

 A level-2 router and a level-1-2 router can establish a level-2 neighbor relation no matter
whether their area IDs are the same.
 Two level-1-2 routers can establish both level-1 and level-2 neighbor relations if their area
IDs are the same.
 Two level-1-2 routers can only establish a level-2 neighbor relation if their area IDs do not
are the same.
IS-IS PDU
The IS-IS protocol is CLNS-based, instead of IP-based. Thus, the IS-IS uses Protocol Data
Units (PDUs) defined by the ISO for the communication between routers. The following PDU
types are used in the IS-IS:
 IS-IS Hello PDU (IIH PDU)
An IIH PDU, which is similar to a Hello packet in the OSPF, constructs a neighbor relation
between routers, discovers new neighbors, and detects whether any neighbor exits.
 Link State PDU (LSP)
An LSP, which is similar to an LSA in the OSPF, describes all the link state information of
the local router.
 Complete Sequence Number PDU (CSNP)
A CSNP includes the summary information of all LSPs in the network. Upon receiving a
CSNP, a router compares it with its link state database. If the router loses an LSP that exists
in the CSNP, the router sends a multicast PSNP to request the other routers in the network
for the required LSP.
 Partial Sequence Number PDU (PSNP)
A PSNP confirms a received LSP in a point-to-point link, and requests an LSP of the latest
version or a lost LSP in a point-to-point or broadcast link.
A CSNP and a PSNP have the same data packet format and carry their own LSP abstract infor-
mation. The difference between them is that the former carries all the known LSP abstract infor-
mation in the link state database of the local router, while the latter only carries a subset of the
LSP abstract information.
8.2.2 Establishing an IS-IS Neighbor

Overview
The IS-IS divides network links into broadcast links and point-to-point links. The process of es-
tablishing an IS-IS neighbor for the two link types are different. They are respectively described
as follows.
106 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Broadcast Link
In a broadcast link, the process of establishing a neighbor is implemented through three hand-
shakes. The level-1 IS sends a level-1 LAN IIH PDU (IS-IS Hello PDU) to the multicast address
AllL1ISs (0180.C200.0014), and starts packet listening based on this address. The level-2 IS
sends a level-2 LAN IIH PDU to the multicast address AllL2ISs (0180.C200.0015), and starts
packet listening based on this address.
To establish a level-1 neighbor, the IS receives a level-1 LAN IIH PDU at the multicast address
AllL1ISs, and compares the area address in the received IIH PDU with the area addresses in
the local configuration. If the area address in the received IIH PDU does not match any area ad-
dress in the local configuration, the IS rejects establishing a neighbor.
Upon receiving an IIH PDU, an IS determines that the neighbor already exists in its neighbor
database based on the following criteria:
 The MAC address of the neighbor in the database is consistent with the MAC source ad-
dress in the IIH PDU.
 The system ID of the neighbor in the database is consistent with the system ID in the IIH
PDU.
 The neighbor type in the database is consistent with that in the IIH PDU.
If all of these conditions are satisfied, it indicates that the neighbor already exists in the data-
base, and the IS updates the hold timer, priority, and neighbor area address information based
on the IIH PDU. If only the system ID and neighbor type in the database are consistent with
those in the IIH PDU, the message will be dropped.
If the system ID and neighbor type in the IIH PDU do not exist in the database, the neighbor
is considered a new one. In that case, the information about the new neighbor is added to the
neighbor database, and the corresponding neighbor state is set to "INIT". Then the IS checks
whether its MAC address exists in the neighbor TLV carried in the IIH PDU. If yes, it sets the
neighbor state to "UP" and sends an IIH PDU. In this PDU, the neighbor TLV carries the MAC
address of the neighbor.
Figure 8-14 shows the process of establishing a neighbor in a broadcast link.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 107

Figure 8-14 Establishing a Neighbor in a Broadcast Link
R1, R2, and R3 are all level-2 routers. Figure 8-14 describes the process of establishing a
neighbor between R1 and R2.
1. R1 sends an IIH PDU to R2.
The system ID and neighbor type in the IIH PDU do not exist in the database of R2. Thus,
R2 considers R1 a new neighbor. R2 adds the information about R1 into its neighbor data-
base, and sets the neighbor state to "INIT". Then R2 checks the neighbor TLV carried in the
IIH PDU and finds that its MAC address does not exist in the neighbor TLV. Thus, R2 main-
tains the "INIT" neighbor state.
2. R2 sends an IIH PDU to R1.
The system ID and neighbor type in the IIH PDU do not exist in the database of R1. Thus,
R1 considers R2 a new neighbor. R1 adds the information about R2 into its neighbor data-
base, and sets the neighbor state to "INIT". Then R1 checks the neighbor TLV carried in the
IIH PDU and finds that its MAC address exists in the neighbor TLV. Thus, R1 sets the neigh-
bor state to "UP".
3. R1 sends another IIH PDU to R2.
R2 finds that neighbor R1 already exists in its neighbor database. Then R2 checks the
neighbor TLV carried in the IIH PDU and finds that its MAC address exists in the neighbor
TLV. Thus, R2 sets the neighbor state to "UP".
108 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Point-to-Point Link
In a point-to-point link, the process of establishing a neighbor is implemented through two hand-
shakes or three handshakes.
 Two-handshake mode
When an IS receives a point-to-point IIH PDU, it compares the area addresses of the two
ISs to determine whether the neighbor to be established is valid. If the two ISs have the
same area address, the neighbor to be established is valid to all types of IS combinations
(except the connection between a level-1 IS and a level-2 IS). If the two ISs have different
area addresses, the neighbor can be established only between two ISs that both have lev-
el-2.
If no error is found in the area address verification, the local IS compares the circuit type
ID in the received IIH PDU with the local IS type. If the two types are the same, a neighbor
can be established. In that case, the local IS adds the neighbor information into its neighbor
database, and sets the neighbor state to "UP". If the two types do not match, for example,
one is level-1 and the other is level-2, the message will be dropped.
The two-handshake mode has a prerequisite: A point-to-point link must be absolutely reli-
able. However, a point-to-point link actually may not be reliable.
 Three-handshake mode
Figure 8-15 shows the process of establishing a neighbor in a point-to-point link in three-
handshake mode.
Figure 8-15 Three-Handshake Mode for a Point-to-Point Link
A three-handshake TLV of the 240 type is carried in the IIH PDU sent by R1. The TLV
stores the three states of the neighbor. Upon receiving the PDU, R2 determines the next
SJ-20230719162004-003 | 2023-10-30 (R1.0) 109

neighbor state based on its own neighbor state as well as the neighbor state in the TLV. For
the changes of the state machine, refer to Table 8-2.
Table 8-2 Neighbor State Changes in Three-handshake Mode

The three-way State of The three-way State in the Received PDU
the Current Neighbor Down INIT UP
Down INIT UP DOWN
INIT INIT UP UP
UP INIT ACCEPT ACCEPT
DIS Election in a Broadcast Link
On a broadcast network, the IS-IS protocol selects the Designate IS (DIS) to reduce the neigh-
bor information carried by the LSP that is sent on the broadcast network and simplify the net-
work architecture. Considering that the network is a middle-system or a dummy node, each
middle-system, including the DIS, advertises each single link to the dummy node. The DIS that
represents a dummy node also advertises a link to all connected middle-systems, see Figure
8-16.
Figure 8-16 DIS Network Structure on Broadcast Network
The conditions to elect a DIS are as follows:
110 SJ-20230719162004-003 | 2023-10-30 (R1.0)

 After a router enables the IS-IS process, the DIS election must be implemented after the du-
ration of twice the interval for sending two Hello packets.
 At least one neighbor is in the UP state.
 It is required to elect the DIS when the neighbor state is changed.
 It is required to elect the DIS after the LAN ID in packet IIH PDU carried by the neighbor is
changed.
Level-1 and level-2 DISs are elected respectively, and the priorities of level-1 and level-2 can
be respectively designated on an IS interface. The IS whose interface has the highest priori-
ty is elected to be the DIS. If multiple ISs have interfaces of the highest priority, the IS with the
largest MAC address is elected to be the DIS. DIS election is implemented in preemption mode.
That is, if the interface priority of an IS that newly joins in a broadcast link is higher than existing
priorities, the IS is elected to be the new DIS.
After an IS is elected to be the new DIS, the following operations should be performed:
1. If another middle-system exists, it is required to set the life time of the LSP of the dummy
node to 0 and delete the LSP.
2. Generate a new LSP for the dummy node and flood it.
3. Generate a new LSP for the non-dummy node and flood it.
After an old DIS is replaced by a new DIS, the following operations should be performed:
1. For the dummy node which is generated by itself before, set the life time of the LSP to 0 and
perform the flooding operation on the entire network.
2. Generate a new LSP for the non-dummy node and flood it.
8.2.3 IS-IS Link State Database Synchronization

Related Terms
 SRM: Send Routing Message. It is used to control the LSP from being sent to a neighbor
router.
 SSN: Send Sequence Numbers Message. It provides the following two functions:
à Confirm the LSP received from a point-to-point link.
à Request for complete LSP information on a broadcast link during data synchronization.
The SRM and the SSN are used for diffusing route selection information and synchronizing the
database.
Point-to-Point Link
On a point-to-point link, the IS-IS protocol uses a reliable flooding mechanism. The peer end
of the link has only one neighbor router and only uses limited bandwidth resource to trace ac-
knowledge messages sent by the peer router.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 111

The CSNP simplifies the database synchronization process. When the neighbor relationship be-
tween two routers is set up for the first time, the active router exchanges the CSNP information
with the standby router. The missing or outdated LSP can be confirmed through comparing the
CSNP information with that of the local database.
After the comparison, use the PSNP to request for the missing LSP. If the router finds that the
neighbor router does not have LSPs, it can diffuse these LSPs actively. During the flooding, the
SSN flag is set to indicate the PSNP to be sent and the SRM flag is set to indicate the LSP to
be sent. For a point-to-point connection, the SRM flag can be cleared after the PSNP acknowl-
edge packet of the peer end is received. Otherwise, the acknowledge packet is re-transmitted
after a timeout.
For the diffusion process on a point-to-point link, see Figure 8-17. It is assumed that the neigh-
bor relationship between R2 and R3 is normal and the neighbor relationship between R1 and
R2 is established for the first time.
Figure 8-17 Database Synchronization of a Point-to-Point Link
1. For the neighbor relationship established between R1 and R2, the database synchronization
process is as follows:
Step R1 R2
1 Sends a CSNP message. Sends a CSNP message.
2 - After receiving the CSNP message from R1,

R2 sends the PSNP request to check the
CSNP received from the R1. If R2 finds that
the CSNP received from R1 does not include
the LSP of the local status database, it sends
R3.00-00 LSP to R1.
3 Receives the PSNP message and sends -

R1.00-00 LSP.
4 Receives R3.00-00 LSP and updates its own -

database.
Sends acknowledge PSNP of R3.00-00 LSP.
5 - Receives R1.00-00 LSP and updates its own

database.
2. After the neighbor relationship between R2 and R1 is set, the information about R1 is dif-
fused to R3. The R2 flooding process is as follows:
112 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Step R2 R3
1 R2 receives R1.00-00,SEQ 100 LSP from R1

through port 2.
When checking the database, R2 finds that this
LSP does not exist.
Sets SSN for R1.00-00 on port 2. Sends a CSNP message.
Sets SRM for R1.00-00 on port 3.
Sends PSNP acknowledgement for R1.00-00 on
port 2.
Clears SSN on port 2.
2 - R3 receives R1.00-00 SEQ 100 from R2

through port 4.
When checking the database, R3 finds that
this LSP does not exist.
Sets SSN for R1.00-00 on port 4.
Add R1.00-00 SEQ 100 to the database.
Sends PSNP acknowledgement for R1.00-00
on port 4.
Clears SSN on port 4.
3 Confirms the PSNP received by R1.00-00 -

through port 3.
Clears the SRM setting for R1.00-00 on port 3.
Broadcast Link
In a broadcast link, an LSP is propagated to layer 1 or layer 2 neighbor routers respec-

tively through specific multicast addresses AllL1ISs (0180.c200.0014) and AllL2ISs
(0180.c200.0015). The propagation of a broadcast link does not need point-to-point reliable
transmission. Instead, routing information propagation in a broadcast link follows the best-effort
rule.
Unreliable diffusion needs a specific mechanism to ensure the synchronization of the database.
The IS-IS router broadcasts the CNSP periodically depending on DIS to synchronize the data-
base on a broadcast link.
The DIS is only responsible for the diffusion on the broadcast link and database synchroniza-
tion. The IS-IS protocol does not require that the IS-IS router on the broadcast link can only set
up a neighbor relationship with the DIS. After the Hello packet performs three-way handshake
between two routers, the neighbor relationship is established. Three-way handshake means
that all routers advertise routers that are found. The CSNP sent by the DIS is diffused peri-
odically to ensure that all routers on the LAN receive a copy. In this way, missing LSP or new
SJ-20230719162004-003 | 2023-10-30 (R1.0) 113

LSP can be confirmed by comparing the CNSP with the content in the link status database and
these LSPs can be requested by sending PSNP messages.
The periodical CSNP broadcast consumes lots of bandwidth. However, this is a simple policy
for reliable transmission on a broadcast link. It is recommended to increase the sending interval
to reduce the sending frequency.
R1 and R2 are routers connected to the link before the R3, see Figure 8-18. At this time, the
link status database of R1 includes R1.00-00, R1.01-00(pseudo lsp) and R2.00-00.
Figure 8-18 Database Synchronization of a Broadcast Link
1. After the neighbor relationship is set between R3 and R1 and between R3 and R2, an LSP,
which means the R3.00-00, is generated. R3 copies this LSP to its own database and diffus-
es it to the link of port 3.
2. R1 that operates as a DIS advertises one CSNP to a link in the broadcast mode.
3. After receiving the CSNP, R3 compares it with that in the local link status database and
finds that three LSPs are missing, including R1.00-00, R1.01-00 and R2.00-00. In this case,
R3 sends packet PSNP to the link to request for these LSPs.
4. R1 sends R1.00-00, R1.01-00, and R2.00-00 in multicast mode. Then R3 receives copies of
these LSPs, so that the database of R3 and that of R1 are synchronized.
Route Leaking
When a level-1-2 router in an area is connected with another area, the router sets an ATT bit
in its level-1 LSP to notify the level-1 routers in the local area that it has an egress. A level-1
router in the local area selects the nearest level-1-2 router with an ATT bit as the default egress
of the area, and generates a default route accordingly.
The level-1-2 router selected by the level-1 router is the nearest, but the nearest path may not
be the optimal path. As a result, a sub-optimal path may be generated.
Route leaking means that the routing information in a backbone area is manually introduced to
a common level-1 area to prevent sub-optimal paths. Thus, a common area can also own the
routing information of the whole IS-IS route domain.
114 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Figure 8-19 illustrates route leaking.
Figure 8-19 Example of Route Leaking
If the source router R1 wants to sends traffic to the destination router R5, R1 sends the traffic
to the nearest level-1-2 router by default, because R1 does not know route information beyond
the level-1 area. In the 49.0001 area, there are two level-1-2 routers: R3 and R4. R3 is closer to
R1, so R1 sends the traffic to R3, and R3 forwards the traffic to R5. The cost of the entire path
is 40. However, the cost of the path from R1 to R5 through R2 and R4 is 30, so the path is a
premium path. R1 does not select the premium path, because it does not know the route infor-
mation in the entire IS-IS domain.
To address this issue, you need to enable route leaking on R3 and R4, so that R1 selects the
path from R1 to R5 through R2 and R4.
LSP Message Size
In an actual network, different devices can be interconnected through different two-layer links.
The interfaces of these interconnected devices may have different MTUs. Because protocol
messages are not allowed to be fragmented in two layers on IS-IS, the maximum and minimum
sizes must be configured for LSP messages on the devices to ensure that all devices on the
network can receive LSP messages during synchronization of the link status database.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 115

You can set the values of the originatingLSPBufferSize and ReceiveLSPBufferSize parame-
ters of an LSP message. The relation between the values and the MTUs of the two-layer links
is:
originatingLSPBufferSize<= ReceiveLSPBufferSize
originatingLSPBufferSize<= MTU
If the ISIS MTU of an interface is lower than originatingLSPBufferSize, the corresponding in-
terface status is set to DOWN, and a corresponding alarm message is generated.
8.3 BGP
8.3.1 BGP Overview

The Border Gateway Protocol (BGP) is a dynamic routing protocol that can run in different Au-
tonomous Systems (ASs) or within one AS. If BGP runs within one AS, the protocol is called In-
ternal BGP (IBGP). If BGP runs in different ASs, it is called External BGP (EBGP).
Three versions released earlier respectively are BGP-1, BGP-2, and BGP-3. The version now in
use is BGP-4. BGP-4, which is virtually an Internet external routing protocol standard, is widely
used among ISPs.
Note
Unless otherwise specified, BGP refers to BGP-4.
Features of BGP are described as follows:

 BGP is an EGP. Different from OSPF, RIP, and other IGPs that focus on discovering and
calculating routes, BGP emphasizes on how to control route propagation and select the best
route.
 BGP is a path vector routing protocol. It measures the distance to a destination address
based on a list of ASs between the source and destination.
 BGP uses the TCP protocol as its transmission layer protocol (port number: 179), which in-
creases the reliability.
 BGP supports Classless Inter-Domain Routing (CIDR).
 In case of route update, BGP only sends the updated route. Thus, much less bandwidth is
needed by BGP for propagating the route. This advantage allows for propagating a great
amount of routing information on the Internet.
 A BGP route carries AS path information. Thus, the problem of route loops is eliminated.
 BGP provides abundant routing policies that can flexibly filter and select routes.
 BGP is highly extensible and adapts to new network developments.
The router sending BGP messages is called a BGP speaker. It receives routing information
or generates new routing information, and advertises the information to other BGP speak-
116 SJ-20230719162004-003 | 2023-10-30 (R1.0)

ers. When a BGP speaker receives a new route from another AS, if the route is better than all
known routes or this route is new to the local AS, the BGP speaker will advertise this route to all
the other BGP speakers in the local AS.
The BGP speakers exchanging information are peers to each other. Several relevant peers can
compose a peer group.
8.3.2 Message Types of BGP

BGP has five message types, including Open, Update, Notification, Keep-alive, and Route-re-
fresh. All the messages have the same header. For the format of the header, see Figure 8-20.
Figure 8-20 Format of a BGP Message Header
The main fields in a BGP message are described as follows:

 Marker: marks the border of the BGP message, 16-byte, all-1.
 Length: total length (including the header) of the BGP message, 2-byte, unit: byte.
 Type: type of the BGP message, 1-byte. The values are from 1 to 5, which respectively rep-
resent an Open, Update, Notification, Keep-alive, and Route-refresh message.
Message Types Description
Open As the first message sent after a TCP connection is established, the Open
message is used to establish a session between BGP peers, contain-
ing the version number (for example, BGP3/BGP4), HoldTime (a negoti-
ation process, the smaller HoldTime is used), Router-ID (manually con-
figurable for the OSPF and BGP), and AS number (in the range of 1 to
65535, among which 64512 to 65535 are reserved for private use.)
Update An Update message is used to exchange routing information between

peers. An Update message can advertise multiple reachable routes with
the same path attribute, or withdraw multiple unreachable routes at the
same time.
The message contains three components, including the Network Layer
Reachability Information (NLRI), path attribute , and withdrawn route.
Notification When detecting an error status, BGP sends a Notification message to its
peer. Then the BGP session will be suspended immediately.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 117

Message Types Description
Keep-alive BGP periodically sends a Keepalive message to its peer to keep the ses-
sion active.
Route-refresh A Route-refresh message is sent to request the peer to re-send the rout-
ing information related to a specified address family.
8.3.3 BGP Neighbor States and State Transition

The states involved in BGP neighbor establishment are as follows:
1. Idle state: initial state. In the "Idle" state, BGP starts initialization, resets the timer, initiates
the first TCP connection, listens for a TCP connection from its peer, and changes its state to
Connect.
2. Connect state: In the "Connect" state, BGP starts the TCP connection and waits for a
TCP connection success message. If the TCP connection succeeds, BGP changes to the
"OpenSent" state; otherwise, BGP transitions to the "Active" state.
3. Active state: In the "Active" state, the BGP always attempts to establish a TCP connection.
If a TCP connection cannot be established before expiration of the timer, BGP transitions
back to the "Connect" state. If a TCP connection is established successfully, BGP transi-
tions to the "OpenSent" state.
4. OpenSent state: In the "OpenSent" state, a TCP connection has been established, and
BGP has sent the first Open message and is waiting for an Open message from its peer.
Upon receiving an Open message from its peer, BGP checks the message. If finding any
error in the message, BGP sends a Notification message and transitions back to the "Idle"
state. If the message is correct, BGP sends a Keepalive message. Then the Keepalive timer
starts, and BGP transitions to the "OpenConfirm" state.
5. OpenConfirm state: In the "OpenConfirm" state, BGP waits for a Keepalive message and
resets the hold timer. Upon receiving a Keepalive message, BGP transitions to the "Estab-
lished" state, and the neighbor relation negotiation is completed. If BGP receives an Update
or Keepalive message, it restarts the hold timer. If BGP receives a Notification message, it
transitions back to the "Idle" state.
6. Established state: In the "Established" state, a neighbor (peer) is established, and the
router can send/receive Update messages to/from its peer and reset the hold timer.
For the state transition during BGP neighbor establishment, see Figure 8-21.
118 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Figure 8-21 State Transition During BGP Neighbor Establishment
8.3.4 BGP Route Advertising Rules

BGP advertises routes in compliance with the following rules:
1. If multiple paths exist, a BGP speaker only selects the optimal path to use (except load bal-
ancing and FRR).
2. A BGP speaker only advertises the route (optimal route) that it uses to neighbor peers.
3. A BGP speaker advertises the routes obtained from an EBGP to all its BGP neighbor peers
(including EBGP and IBGP peers).
4. A BGP speaker does not advertise the routes obtained from an IBGP to its IBGP neighbor
peers (except route reflectors).
5. Whether a BGP speaker advertises the routes obtained from an IBGP to all its EBGP neigh-
bor peers or not depends on the synchronization status of the IGP and BGP.
6. When a BGP speaker receives a refresh message from a peer and the local neighbor sup-
ports the refresh capability, BGP speaker advertises all its BGP routes to the peer.
7. During the GR process, a BGP speaker advertises all its BGP routes to the peer after ac-
tive/standby switching.
8.3.5 BGP Route Attributes

Classification of Route Attributes
BGP route attributes are a group of parameters describing a specific route in detail so that BGP
can filter and select routes.
Actually, all BGP route attributes can be classified into four types:
SJ-20230719162004-003 | 2023-10-30 (R1.0) 119

 Well-known mandatory: All BGP routes must know this type of attributes, which must exist in
all Update messages. If this type of attributes is unavailable, routing information may be in-
correct.
 Well-known discretionary: All BGP routes know this type of attributes, which does not neces-
sarily exist in an Update message. This type of attributes can be selected as required.
 Optional transitive: An attribute of this type can be transferred between ASs. A BGP router
may not support this attribute, but it still receives routes containing this attribute and adver-
tises them to peers.
 Optional non-transitive: If a BGP router does not support this type of attributes, they will be
ignored and not advertised to peers.
For the basic BGP route attributes and the corresponding types, see Table 8-3.
Table 8-3 Route Attributes and Types

Attribute Name Type
ORIGIN Well-known mandatory
AS_PATH Well-known mandatory
NEXT_HOP Well-known mandatory
LOCAL_PREF Well-known discretionary
ATOMIC_AGGREGATE Well-known discretionary
AGGREGATOR Optional transitive
COMMUNITY Optional transitive
MULTI_EXIT_DISC (MED) Optional non-transitive
ORIGINATOR_ID Optional non-transitive
CLUSTER_LIST Optional non-transitive
Main Route Attributes
1. ORIGIN attribute
The ORIGIN attribute defines the origin of routing information, and marks how a route be-
comes a BGP route. There are three options:
 IGP: indicates that a route is generated within the local AS. A route with this attribute has
the highest priority.
 EGP: indicates that a route is learned from EGP. A route with this attribute has a priority
lower than an IGP route.
120 SJ-20230719162004-003 | 2023-10-30 (R1.0)

 Incomplete: indicates that the origin of a route cannot be identified. It does not mean that
the route is unreachable. A route with this attribute has the lowest priority. For example,
a route introduced from other routing protocols.
2. AS_PATH attribute
The AS_PATH attribute is the set of AS numbers that must be traversed to reach the desti-
nation. When advertising a route to other ASs, BGP adds the local AS number to the top of
the AS_PATH list. In accordance with the AS_PATH attribute, an BGP router receiving this
route can know all ASs that must be traversed to reach the destination. The AS number of
the AS nearest to the local AS follows the local AS number. Other AS numbers are ordered
accordingly, see Figure 8-22.
Figure 8-22 AS_PATH Attribute
Generally, BGP will not accept a route with the AS_PATH that contains the local AS num-
ber. Thus, route loops can be avoided.
In addition, the AS_PATH attribute can be used for routing and filtering. Between two routes
of the same conditions, BGP prefers the route with a shorter path. For example, in Figure
6 the BGP router in AS 50 selects the path traversing through AS 40 to the destination ad-
dress 8.0.0.0 as the optimal route.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 121

Some applications allow you to use a route policy to manually increase the length of an AS
to flexibly control BGP routing.
An AS path filtering list can also filter routes by AS numbers in the AS_PATH attribute.
3. NEXT_HOP Attribute
The NEXT_HOP attribute of BGP is different from that of IGP. The former is not necessarily
the IP address of a neighbor route.
The value of the NEXT_HOP attribute can be any of the following (see Figure 8-23):
 When a BGP speaker advertises its own routes to all neighbors, BGP sets the NEX-
T_HOP attribute in the routing information to its interface address used for connecting
the peer end.
 When a BGP speaker advertises a received route to an EBGP peer, BGP sets the NEX-
T_HOP attribute in the routing information to its interface address used for connecting
the peer end.
 When a BGP speaker sends a route obtained from an EBGP neighbor to an IBGP neigh-
bor, it does not change the NEXT_HOP attribute in the routing information. If load shar-
ing is configured, the NEXT_HOP attribute will be changed when the route is sent to an
IBGP neighbor.
Figure 8-23 NEXT_HOP Attribute
4. MED
The MED attribute is exchanged only between two adjacent ASs. After receiving the MED
attribute, an AS will not advertise it to a third AS.
The MED attribute is equivalent to the metrics used by the IGP. This attribute determines
the optimal route for traffic to enter an AS. When a router running BGP obtains multiple
122 SJ-20230719162004-003 | 2023-10-30 (R1.0)

routes that have the same destination address but different next hops from different EBGP
peers, BGP selects the route with the smallest MED value as the optimal route. As shown in
Figure 8-24, traffic from AS 10 to AS 20 selects Router B as the ingress.
Figure 8-24 MED Attribute
Generally, a BGP only compare the MED values of the routes from the same AS.
5. Local preference (LOCAL_PREF) attribute
The LOCAL_PREF attribute is exchanged only between IBGP peers, and is not advertised
to other ASs. This attribute indicates the priority of a BGP router.
The LOCAL_PREF attribute determines the optimal route for traffic to leave an AS. When
a router running BGP obtains multiple routes that have the same destination address but
different next hops from different IBGP peers, BGP selects the route with the largest LO-
CAL_PREF value as the optimal route. As shown in Figure 8-25, traffic from AS 20 to AS 10
selects Router C as the egress.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 123

Figure 8-25 LOCAL_PREF Attribute
6. COMMUNITY Attribute
The COMMUNITY attribute simplifies the usage of route policies and makes maintenance
management easier. This attribute is a set of destination addresses of the same features,
which are not divided by physical boundaries and are independent of ASs. Generally ac-
cepted community attributes include:
 INTERNET: By default, all routes belong to the INTERNET community. The route with
this attribute can be advertised to all BGP peers.
 NO_EXPORT: When a route with the NO_EXPORT attribute is received, the route can-
not be advertised beyond the local AS. If a confederation is used, the route cannot be
advertised beyond the confederation, but can be advertised to other sub ASs in the con-
federation.
 NO_ADVERTISE: When a route with the NO_ADVERTISE attribute is received, the
route cannot be advertised to any other BGP peer.
 NO_EXPORT_SUBCONFED: When a route with the NO_EXPORT_SUBCONFED at-
tribute is received, the route cannot be advertised beyond the local AS or to other sub
AS in a confederation.
8.3.6 BGP Routing Rules

BGP Routing Policies
In the present BGP implementation, routing complies with the following policies:
124 SJ-20230719162004-003 | 2023-10-30 (R1.0)

1. Routes with unreachable next hops (NEXT_HOP) are dropped first.

2. The route with the largest Preferred-value is preferred.
3. The route with the highest local priority (LOCAL_PREF) is preferred.
4. An aggregate route is preferred.
5. The route with the shortest AS path (AS_PATH) is preferred.
6. The routing order by the ORIGIN type is as follows: IGP > EGP > Incomplete.
7. The route with the smallest MED value is preferred.
8. The routing order by origin is as follows: EBGP > confederation > IBGP.
9. The route with the smallest next-hop Cost value is preferred.
10. The route with the shortest CLUSTER_LIST is preferred.
11. The route with the smallest ORIGINATOR_ID value is preferred.
12. The route advertised by the router with the smallest router ID is preferred.
13. The route advertised by the peer with the smallest address is preferred.
Note
 A CLUSTER_ID is the cluster ID of a route reflector. A CLUSTER_LIST is a set of CLUSTER_IDs. A
reflector adds its CLUSTER_ID into a CLUSTER_LIST. If a route received by the reflector contains
the CLUSTER_ID of the reflector in the CLUSTER_LIST, the route is dropped. Thus, loops inside the
cluster can be avoided.
 If load sharing is configured and there are more than one route reaching the same destination ad-
dress, routes are selected for load sharing based on the number of configured route entries.
Routing in Case of BGP Load Sharing
Due to the characteristics of the BGP protocol, the next hop of a BGP route may not be a direct
neighbor of the current router. A common reason is that the next hop is not changed when rout-
ing information is advertised between IBGPs. Thus, to forward a message correctly, the router
must find a directly reachable address first (by querying the entries in the routing table estab-
lished by IGP). The message can then be sent to the next hop specified in the routing table
based on this address. During this process, the route to the directly reachable address is called
a dependent route, on which a BGP route depends to forward messages. The process of find-
ing a dependent route based on the next-hop address is called route recursion.
In the current version, the system supports recursion-based BGP load sharing. That is, if a de-
pendent route is in load sharing mode (suppose there are three next-hop addresses), BGP also
generates the same number of next-hop addresses for message forwarding. It should be noted
that recursion-based BGP load sharing is always enabled in the system.
BGP load sharing and IGP load sharing are implemented in different ways:
 IGP uses the routing algorithm defined by the protocol to calculate different routes to the
same destination address, and implements load sharing among the routes with the same
metric value (such as RIP or OSPF). The routing criteria are very specific (that is, by metric).
SJ-20230719162004-003 | 2023-10-30 (R1.0) 125

 BGP has no such algorithm. Instead, it is only a routing protocol. Therefore, BGP cannot de-
termine whether to implement route load sharing by a specific measure. However, BGP has
many routing rules, and can implement conditional load sharing after routing. That is, load
sharing is added to the scope of BGP routing rules.
Note
 BGP implements load sharing only on the routes with the same AS_PATH, ORIGIN, LOCAL_PREF,
and MED attributes.
 BGP load sharing is applicable to EBGPs, IBGPs, and confederations.
 If there are more than one route reaching the same destination address, routes are selected for load
sharing based on the number of configured route entries.
In Figure 8-26, Router D and Router E are IBGP peers of Router C. When Router A and Router
B both advertises a route to the same destination to Router C, if load sharing is configured
on Router C (for example, balance 2), Router C adds both routes to its forwarding table for
load sharing as long as specific routing rules are satisfied and the two routes have the same
AS_PATH, ORIGIN, LOCAL_PREF, and MED attributes. Router C forwards the route to Router
D and Router E only once. The AS_PATH attribute is not changed, but the NEXT_HOP at-
tribute is modified to the address of Router C, instead of the address of the EBGP peer previ-
ously used. Other transitional attributes of BGP are transferred based on the optimal route.
Figure 8-26 BGP Load Sharing
BGP Route Advertising Policies
In the present BGP implementation, route advertising complies with the following policies:
126 SJ-20230719162004-003 | 2023-10-30 (R1.0)

 If multiple valid routes exist, a BGP speaker only advertises the optimal route to its peers.
 A BGP speaker only advertises the routes used by it to its peers.
 A BGP speaker advertises the routes obtained from an EBGP to all its BGP peers (including
EBGP and IBGP peers).
 A BGP speaker does not advertise the routes obtained from an IBGP to its IBGP peers.
 A BGP speaker advertises the routes obtained from an IBGP to its EBGP peers (If BGP and
IGP synchronization is disabled, an IBGP route is directly advertised. If BGP and IGP syn-
chronization is enabled, an IBGP route is synchronized and advertised to an EBGP peer on-
ly after IGP advertises this route.)
 Once a connection is established, a BGP speaker advertises all its BGP routes to new
peers.
8.3.7 Synchronization Between IBGP and IGP

BGP synchronization refers to the synchronization between an IBGP and an IGP.
The purpose of a BGP synchronization rule is to avoid black holes inside an AS (not all routers
run BGP). That is, a false route that the local AS cannot reach is advertised to the outside.
If there is a non-BGP router providing forwarding services in an AS, an IP packet forward-
ed through the AS may be dropped if the destination address is unreachable. In Figure 8-27,
Router E learns the route 8.0.0.0/8 of Router A from Router D, and forwards a packet with this
destination address to Router D. Then, Router D queries the routing table and finds that the
next hop is Router B. Since Router D learns the route to Router B from the IGP, Router D for-
wards the packet to Router C by route iteration. However, Router C does not know the route to
the address 8.0.0.0/8, and thus it drops the packet.
Figure 8-27 Synchronization Between IBGP and IGP
SJ-20230719162004-003 | 2023-10-30 (R1.0) 127

If synchronization is set, the IGP routing table is checked before an IBGP route is added to the
routing table and advertised to an EBGP peer. The route can be advertised to an EBGP peer
only if the IGP also knows this IBGP route.
In the following cases, synchronization can be disabled:
 The local AS is not a transit AS (in Figure 8-27, AS 20 is a transit AS.)
 All the routers in the local AS are fully connected through the IBGP.
8.3.8 MP-BGP
MP-BGP Overview
Traditional BGP-4 only manages IPv4 unicast routing information, and it has limitations in in-
ter-AS broadcast for the applications that use other network layer protocols (such as IPv6).
To provide support for multiple network layer protocols, the IETF extends BGP-4 and forms MP-
BGP.
Routers supporting BGP extension can interwork with routers that do not support BGP exten-
sion.
MP-BGP Extension Attributes
Three types of information related to the IPv4 address format are carried in an Update message
used by BGP-4, including an NLRI, the route attribute NEXT_HOP, and the route attribute AG-
GREGATOR (this attribute contains the IP address of the BGP speaker forming an aggregate
route.)
To support multiple network layer protocols, BGP-4 should map the information of network layer
protocols to the NLRI and NEXT_HOP attributes. In the MP-BGP, two new path attributes are
introduced:
 MP_REACH_NLRI: Multiprotocol Reachable NLRI. It advertises information about reachable
routes and next hops.
 MP_UNREACH_NLRI: Multiprotocol Unreachable NLRI. It withdraws unreachable routes.
Both of these attributes are optional non-transitive. Thus, a BGP speaker that does not provide
multiprotocol capabilities ignores these two attributes and does not pass them to neighbors.
Address Family
The MP-BGP distinguishes network layer protocols by address family. In the current version,
the system implements multiple MP-BGP extension applications, including VPN and IPv6 ex-
tension.
128 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Chapter 9
VXLAN Feature
Description
VXLAN (Virtual eXtensible LAN) is an overlay network technology defined by RFC 7348.
VXLAN is essentially MAC in IP, or MAC in UDP, which means a layer 2 network can be built
on layer 3 IP network. The layer 2 network here is an overlay network, and the layer 3 network
is an underlay network.
VXLAN can be used for the span WAN connections between OLT user lines to the remote data
centers or enterprise headquarters. The connection can be set up in the following ways:
 Static VXLAN configuration
 Dynamic configuration controlled by a SDN controller
 Automatic discovery and dynamic connection by an EVPN control plane
Figure 9-1 shows the VXLAN application scenario that uses a SDN controller to control connec-
tion.
Figure 9-1 VXLAN Application Scenario
SJ-20230719162004-003 | 2023-10-30 (R1.0) 129

Because VXLAN is an overlay network technology, WAN devices in the middle are not aware
of users' MAC addresses, do not learn users' MAC addresses, and do not concern the number
of users' MAC addresses. The OLT (local VTEP (VXLAN tunnel endpoints)) and remote VTEP
supports ECMP, thus xSTP protocols are not needed. Different tenants are separated by VNI
(VXLAN Network Identifier).
Principle
Figure 9-2 shows the VXLAN message encapsulation.
Figure 9-2 VXLAN Message Encapsulation
The underlay network forwards packets according to the outer IP heads, the destination UDP
port is 4789 by default. When the I-bit in Flagis set to 1, it means that the VXLAN connection is
valid. A VNI identifies a VXLAN connection in certain direction.
Figure 9-3 VXLAN Principle
A local VTEP should be configured on the OLT. A local VTEP can be identified by a layer 3 in-
terface address, which is usually the OLT loopback address. A pair of local VTEP and remote
VTEP (unicast address) can identify a VXLAN tunnel, which may contains multiple VXLAN con-
nections. Different VNIs identify different VXLAN connections. VNIs on the receiving direction
are allocated by the remote VTEP. VNIs on the transmmiting direction are allocated by the local
VTEP.
On the OLT, only the VNI on receiving direction is configured. The SDN controller and EVPN
control signaling advertise the VNI to the remote VTEP. VNIs on the receiving and transmitting
130 SJ-20230719162004-003 | 2023-10-30 (R1.0)

9 VXLAN Feature
directions can be same or different. A traditional VXLAN without control panel learns topolo-
gy by receiving and transmitting same VNI. For a VXLAN with control panel, the receiving and
transmitting VNI are different by default.
The OLT supports to allocate VXLAN connections as logic interfaces to logic OLT slices, or al-
locate to a forwarding instance. When logic OLT slices are not configured, the forwarding in-
stance belongs to physical vOLT0. The forwarding instance can be a VPWS, VPLS, or VRF.
 A VPWS is an Ethernet private connection which contains a user-side AC interface and a
VXLAN logic interface. A VPWS does not learn user's MAC addresses.
 A VPLS may contain a group of user-side AC interfaces and multiple VXLAN logic inter-
faces. A VPLS learns user's MAC addresses to forwarding packets.
 A VRF is an IP private network forwarding instance and forwards packets according to
user's routing table.
For the BUM (Broadcast, unknown-unicast, and multicast) messages in the overlay network,
each forwarding instance controls a VTEP to implement ingress replication in the underlay net-
work to simulate the broadcast and multicast.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 131

Chapter 10
EVPN Feature
Description
EVPN (Ethernet VPN) was introduced to the improve L2VPN at the beginning, and now is used
in data center overlay network in combination with VXLAN. EVPN is in compliance with IETF
(Network Virtualization over Layer 3) architecture.
In a traditional L2VPN (VPLS/VPWS):
 Two sets of signals are used to discover and set up connections. LDP is the signaling to set
up PW. MP-BGP is the signaling for PEs to discover each other.
 The forwarding panel sets up MAC forwarding table (FDB) by self learning, which is lack of
policy and flooding control.
 When a user CE belongs to two PEs, traffic can not be forwarded on the active and backup
links simultaneously.
EVPN unifies the VPN signaling for discovery and connection setup to MP-BGP signaling. The
remote end MAC address is learnt by the control panel MG-BGP, without the forwarding panel
flooding. EVPN supports Ethernet Segment function to implement traffic forwarding on all links.
EVPN uses unified MP-BGP signaling to implement L2VPN service and L3VPN service, where
L2VPN service supports point-to-point E-LINE service andpoint-to-mulitipoint E-LAN service.
On an OLT, three type of forwarding instance, VPWS, VPLS, and IRB ( using Integrated Rout-
ing Bridging interface to backhaul VPLS to VRF), can be configured to implement E-LINE, E-
LAN, and L3VPN services. An IRB interface provides layer 2 forwarding within a subnet and
span-subnet layer 3 forwarding for the same VPN.
132 SJ-20230719162004-003 | 2023-10-30 (R1.0)

10 EVPN Feature
Figure 10-1 EVPN Application Scenario
EVPN Principle
Figure 10-2 describes the main EVPN concepts.
Figure 10-2 EVPN Concepts
The OLT works as an PE (Provider Edge) device (NVE in NVO3 architecture, VTEP in VXLAN).
Table 10-1 EVPN Concept Descriptions

Concept Description
Data Plane encapsulation EVPN supports to use VXLAN, MPLS, PBB, and SRv6 as data forwarding pan-
els. The OLT complies with EVPN-VXLAN mode defined in draft-ietf-bess-evpn-
overlay.
EVI An EVPN instance spanning the Provider Edge (PE) devices participating in that
EVPN.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 133

Concept Description
Ethernet Segment (ES) When a customer site (device or network) is connected to one or more PEs via
a set of Ethernet links, then that set of links is referred to as an 'Ethernet seg-
ment'.
Ethernet Segment Identifier A unique non-zero identifier that identifies an Ethernet segment is called an ’
(ESI) Ethernet Segment Identifier’.
Ethernet Tag An Ethernet tag identifies a particular broadcast domain, e.g., a VLAN. An
EVPN instance consists of one or more broadcast domains. The OLT supports
only one EVPN instance（EVI）which contains one broadcast domain (Ethernet
Tag).
Single-Active Redundancy When only a single PE, among all the PEs attached to an Ethernet segment, is
Mode allowed to forward traffic to/from that Ethernet segment for a given VLAN, then
the Ethernet segment is defined to be operating in Single-Active redundancy
mode.
All-Active Redundancy When all PEs attached to an Ethernet segment are allowed to forward known
Mode unicast traffic to/from that Ethernet segment for a given VLAN, then the Ethernet
segment is defined to be operating in All-Active redundancy mode.
IRB Integrated Routing and Bridging.
MAC-VRF A Virtual Routing and Forwarding table for Media Access Control (MAC) ad-
dresses on a PE for an EVI, which equals to a VPLS forwarding instance on the
OLT.
IP-VRF A Virtual Routing and Forwarding table for IP addresses on a PE that is associ-
ated with one or more EVIs.
IRB Interface A virtual interface that connects a bridge table in a MAC-VRF to an IP-VRF in an
NVE.
The OLT supports EVPN core functions:

 Supports remote end MAC addresses learning by the control panel.
 Supports IP-VRF.
134 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Chapter 11
Multicast Feature
Table of Contents
Multicast Description................................................................................................................ 135
Multicast Application Scenario................................................................................................. 137
Multicast Principle.....................................................................................................................138
11.1 Multicast Description

Multicast Overview
Relative to unicast, multicast is a one-to-many network transmission mode. Multicast is mainly

applied in IPTV, broadcast, stock information, information push and video communication. Mul-
ticast is characterized in wide coverage and large number of users. Multicast is used to effec-
tively utilize the calculation capability of network equipment and avoid explosive requirements
for the bandwidth. In most cases, multicast is pushed to nearest network nodes of users. Thus,
the number of forwarding hops is reduced to ensure good service quality.
Multicast is different from broadcast in the fact that data forwarding is controlled through proto-
cols. A basic multicast network is composed of multicast sources, multicast routers, and multi-
cast clients. Between routers, multicast routing protocols are used, including intra-domain mul-
ticast protocols such as PIM SM/PIMSSM/DVMRP/etc and inter-domain multicast protocols
such as MSDP/BGMP/etc.Between routers and clients, multicast management protocols are
used, including IGMP (IPv4) and MLD (IPv6). On layer-2 network devices between routers and
clients, IGMP/MLD Snooping/Proxy are used.
Multicast services require a large bandwidth and low latency and jitter. With the coming of the
age of big video, multicast services have become an important drive for the development and
evolution of network devices.
Multicast Address Planning
Multicast data is identified with a multicast address. The destination address of an IPv4 multi-
cast package is a type-D IP address (224.0.0.0 through 239.255.255.255). Address segments
can be used as data transmission IDs, except the following reserved multicast address seg-
ments:
SJ-20230719162004-003 | 2023-10-30 (R1.0) 135

 224.0.0.0-224.0.0.255: dedicated address segment, which is used for protocol broadcast

and communication.
 224.0.1.0-224.0.1.255: public address segment, which is used for the Internet.
 239.0.0.0-239.255.255.255: private address segment, which is used in the local area.
When IP multicast packages are transmitted through the Ethernet, the destination IP address
is mapped as the destination MAC address by putting the low 23 bits of the IP address into the
low 23 bits of the MAC address and always filling 01:00:5e into the previous bits. Five bits are
not mapped so that multiple IP multicast addresses are mapped to the same MAC multicast ad-
dress, with a mapping rate of 32:1, see Figure 11-1.
Figure 11-1 Mapping of a Destination IP Address to a Destination MAC Address
In the IPv6 network, the IP layer uses 128-bit IPv6 addresses to identify multicast groups. Eth-
ernet multicast addresses begin with 33:33, and followed by the last four bytes of IPv6 multicast
addresses.
Multicast Data Forwarding
All network devices supporting multicast forwarding have a hardware multicast forwarding table
and forward port lists selected by matching multicast group addresses. The following forwarding
methods are used:
 Forwarding based on the destination MAC
 Forwarding based on the VLAN and the destination MAC
 Forwarding based on the VLAN and the destination IP
 Forwarding based on the VLAN, the destination IP, and the source IP
The first three methods do not identify the multicast source address and therefore are named
ASM mode. The fourth method is named SSM mode, in which, different multicast sources can
send the same multicast group address, and the IGMPv3/MLDv2 supports the SSM.
If the forwarding table information contains the VLAN field, different VLANs may have the same
multicast group address and no conflicts are caused. Thus SP services are separated in the
wholesale scenario.
IP-based forwarding, relative to MAC-based forwarding, avoids MAC address conflicts generat-
ed due to the IP-MAC mapping rate.
136 SJ-20230719162004-003 | 2023-10-30 (R1.0)

11 Multicast Feature
Multicast Management Protocol
Basic principle of the IGMP: The host sends IGMP request messages (including join and leave
messages) to a router, and the router sends IGMP query messages (including general query
messages and specific group query messages) to the host to maintain the group member in-
formation on the router. If the router receives a join message, it established a group member. If
the router receives a leave message, it deletes the group member. General IGMP query mes-
sages are periodically sent. The host must respond to the query messages from the group that
it joins. If the router does not receive any IGMP requests from the host in a long period, the
group member relationship is automatically aged and deleted. Specific group query messages
are triggered by IGMP leave messages to determine whether any member of a specific multi-
cast group exists on the current interface.
The IGMP protocol has three versions: v1/v2/v3. IGMPv2 (rfc2236) is mostly used and IGMPv3
(rfc3376) is added with the multicast source address filtering function.
The IGMP Snooping protocol establishes and maintains the multicast forwarding member list
that is based on layer-2 switching by listening to and forwarding all legal IGMP messages.
The IGMP Proxy protocol also maintains the layer-2 multicast forwarding member list. In addi-
tion, it has a host and router proxy function. The network-side host proxy forwards the IGMP
join message of the first user and the IGMP leave message of the last user of a multicast group,
and responds to the IGMP query messages from a router. The user-side router proxy sends
IGMP query messages. Compared to IGMP Snooping, IGMP Proxy greatly reduces the number
of the IGMP messages that a router processes and the upstream network load.
MLD and IGMP have similar principle except that MLD uses IPv6 addresses. MLD has two ver-
sions. MLDv1 corresponds to IGMPv2, and MLDv2 corresponds to IGMPv3. For easy descrip-
tion, MLD is not mentioned in the following. All IGMP features are suitable for MLD unless oth-
erwise specified.
11.2 Multicast Application Scenario

In an FTTH network, a typical multicast scenario is the IPTV service. IPTV service solution con-
sists of services, contents, a user management system (IPTV middleware system for short), a
CDN content distribution system, and a terminal system, providing video-based services such
as live TV, TSTV and VOD.
Figure 11-2 shows the FTTH multicast application scenario.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 137

Figure 11-2 Multicast and IPTV Service Solution
IPTV middleware and live broadcast codec form the service, content, and user operating plat-
form for the IPTV system. SMS is an IPTV service management and policy control system. It
obtains the product package information and control information through the middleware sys-
tem of the IPTV and sends the service management and policy control information to the OLT
and ONT/HGU that have accessed the network. Thus the IPTV service is controlled and man-
aged on service creation, release, use, and charging.
IPTV programs include live programs and programs on demand. Live programs are transmit-
ted in multicast mode and programs on demand are transmitted in unicast mode. When a user
switches the channel, the set-top box sends an IGMP/MLD multicast request to establish a mul-
ticast forwarding table on an upstream network device. After being copied and forwarded sever-
al times, downlink multicast data reaches the set-top box.
If the multicast copy point moves down to an accessed node, the layer-2 IGMP/MLD protocol
must be enabled on both the OLT and ONU to listen to IGMP/MLD requests, establish the lay-
er-2 multicast forwarding table, and copy the downlink multicast data stream to the PON and
UNI interfaces. IGMP/MLD Proxy operates on the OLT and IGMP/MLD Snooping operates on
the ONU. Downlink multicast data stream on the OLT is sent in SCB mode, all ONUs on the
PON interface will receive the multicast data, and the ONUs finally perform multicast copy and
filtering.
11.3 Multicast Principle

OLT Principle
The OLT multicast protocol has a distributed architecture. A protocol status machine operates
on both the active switching control card and PON interface cards, which exchange protocol
138 SJ-20230719162004-003 | 2023-10-30 (R1.0)

messages through the internal interface. The switching control card copies the messages to the
SA (switch access), and the PON interface cards copy the messages to the PON interfaces.
The OLT supports IPv4 and IPv6 multicast dual protocol stack. The two protocols use the same
service model and operate independently.
Basic Service Models
An OLT manages the basic framework of the multicast service and is composed of a multicast
VLAN, a source port, and a receive port.
A multicast VLAN carries downlink multicast data. Multicast forwarding control is implemented
only on multicast data stream in a multicast VLAN. The multicast data stream in other VLANs
are flooded.
A source port is an uplink OLT interface connected to the multicast source and configured in an
MVLAN. Uplink IGMP/MLD request messages are sent out through the source port. The IGMP/
MLD request messages received from other than the source port are directly discarded.
A receive port is an ONU logical port connected to users and is configured in a MVLAN. Users
are allowed to access the network only when their IGMP/MLD request messages are received
on the receive port. Thus multicast user access is controlled. Downlink IGMP/MLD query mes-
sages are sent out through the receive port.
For GPONONU, an IGMP template must be created, and the template must be bound to the
UNI through the remote interface OMCI. In the IGMP template, the IGMP version, fast leave,
maximum number of the multicast groups, and package list can be configured.
Parameter
The OLT supports configuring IGMP/MLD protocol parameters. The configuration granularity is
MVLAN. For parameter descriptions, refer to Table 11-1.
Table 11-1 IGMP/MLD Protocol Parameter Descriptions

Parameter Description
Snooping Aging Time Group member aging means that if the multicast group members fail to
receive the IGMP request messages within a specific period, the group
members are deleted and the multicast stream delivery is stopped. The
aging time is used to prevent bandwidth usage by multicast stream deliv-
ered when a user device is unexpectedly powered off without sending an
IGMP leave message.
Note: The aging time in Proxy mode is approximately equal to the prod-
uct of the query interval and the robustness variable.
Query Interval Indicates the query interval delivered at specified time. By default, it is
set to 125 s. When a user watches a program for a long time, the com-
mon query packets are delivered at specified time and all user equip-
SJ-20230719162004-003 | 2023-10-30 (R1.0) 139

Parameter Description
ment of the program should respond to them, to avoid the freezing pro-
gram caused by the aging of multicast members.
Last Member Query Interval Indicates the query interval of the last member, which is delivered when
the IGMP leave packets are received during non-fast leave. By default, it
is set to 1 s. If a port has multiple multicast users, and if a user switches
the channel and leaves the multicast group, the last member query pack-
ets must be delivered, to query whether there is any other user watching
the same program.
Last Member Query Count Indicates the number of times that the last member query packets are
delivered when the IGMP leave packets are received during non-fast
leave. Querying for more times can prevent packet loss. By default, it is
set to 2.
Query Response Interval Indicates the maximum response interval in which the user side must re-
spond to the IGMP request packets upon receiving the common request
packets, to avoid request conflicts through random delay.
Robustness Variable When the network is not so robust (packet loss occurs easily), a relative-
ly high robustness variable is set to ensure the reliability of multicast ser-
vices. This parameter adjusts the aging time of group members in Proxy/
Router modes.
Unsolicited Report Interval When a join-in request of new multicast is received, the IGMP request
packets are forwarded immediately and will be delivered again after the
random delay to avoid packet loss. The range of the random delay is
called an unsolicited report interval.
router-ip Source IP address used to send downlink IGMP query messages. This
IP address identifies the message source.
host-ip Source IP address used to send uplink IGMP query messages. This IP
address identifies the message source.
host-version Version (V2, V3, or auto) of the uplink IGMP request message. Auto
means self-adaptive. The version of the received general query message
determines the version of the IGMP request message to be sent.
message-version Version of the downlink query message, which is configured based on

the capability of the set-top box in the network and the practical service.
Generally, it is v2.
Inter-VLAN multicast
In an FTTH network, user-side IPTV services are transmitted in a unicast VLAN, and downlink
multicast data is transmitted in a shared multicast VLAN, separated from the unicast VLAN. In
140 SJ-20230719162004-003 | 2023-10-30 (R1.0)

this scenario, layer-2 multicast copy between different VLANs is referred to as inter-VLAN multi-
cast.
In the uplink direction, the OLT converts the IGMP request messages received from the unicast
VLAN on the user side to multicast VLAN and sends the multicast data to the network side. The
conversion rule is based on the multicast VLAN registered on the receive port.
In the downlink direction, multicast data stream and the VLAN of IGMP query messages must
be converted to unicast VLAN. This conversion is implemented by configuring a VLAN conver-
sion rule on the ONU or on the OLT.
The OLT supports global and ONU-level multicast VLAN translation. At the same time of glob-
al multicast VLAN translation, VLAN conversion is also implemented on multicast data stream
and protocol messages. In networks of some carriers, protocol messages must be independent-
ly converted, using ONU-level multicast VLAN translation.
Multicast Security Control
By setting the maximum number of the multicast groups that an ONU can join concurrently and
the fast leave function, if a user switches channels quickly and the multicast group members
fail to leave before the switch, the downlink multicast stream will not exceed the user port band-
width.
Multicast Service Experience
Hot channels that some users often watch can be configured as prejoined multicast groups.
Data stream is directly sent to the uplink OLT interface. Thus the channel switch latency is re-
duced and user experience is improved. A prejoined multicast group is implemented by re-
sponding to the query messages of routers as static multicast members.
Multicast QoS
Multicast QoS is composed of multicast data stream and protocol messages.

In scheduling the downlink queues on the PON interface, multicast data stream has a sched-
uling priority only lower than that of the voice service, which has the highest priority. Different
multicast streams can be scheduled based on the CoS value.
In addition, CoS mark and Policing speed restriction can be used for downlink multicast
streams.
For protocol messages, a CoS value can be configured for the IGMP messages to be sent to
avoid packet loss due to network congestion.
Multicast Operation and Maintenance Management
The OLT supports the following multicast operation and maintenance management features:
SJ-20230719162004-003 | 2023-10-30 (R1.0) 141

 Collecting IGMP/MLD protocol message statistics based on the global office, a VLAN, or a
user interface.
 Viewing IGMP/MLD multicast group members based on the global office, a VLAN, or a user
interface.
 Sending IGMP/MLD join and leave event logs to the server in a customized format for
charging and big data analysis of user actions.
 Collecting real-time multicast traffic for a multicast group to find abnormal traffic.
 Monitoring and analyzing multicast code streams, and actively finding and handling video
service faults as a part of the big video solution.
142 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Chapter 12
Synchronization Features
Table of Contents
Clock Synchronization.............................................................................................................. 143
Synchronous Ethernet.............................................................................................................. 150
Time Synchronization............................................................................................................... 151
12.1 Clock Synchronization

Description
When a fixed network carries TDM and mobile backhaul services, it needs to provide clock syn-
chronization to meet the requirements of TDM services and wireless services. If the fixed net-
work carries TDM services and the clocks are inconsistent at both ends for a long time, bit slips
can occur. In wireless applications, the frequencies between different base stations must be
synchronized to a certain precision, otherwise, users go offline during base station changeover.
Clock synchronization, namely, frequency synchronization, refers to ensuring the synchroniza-
tion of terminal clock to network frequency to meet the relevant frequency synchronization re-
quirements. As access devices, the OLT and ONU are part of communication network and must
provide synchronization mechanism and relevant techniques to ensure the synchronization of
communication terminals to networks.
 Synchronization network clock architecture
Figure 12-1 shows the synchronization network clock architecture.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 143

Figure 12-1 Synchronization Network Clock Architecture
The synchronization network precisely transports synchronization timing signals from the
reference clock to network all nodes to adjust the clocks in the network, keep signal syn-
chronization, and transports various services. Therefore, the reference clock is important in
the synchronization network.
à Level-1 reference clock includes Primary Reference Clock (PRC) and Local Primary Ref-
erence (LPR).
The PRC consists of free-running cesium atomic clock groups, or cesium atomic clocks
and satellite positioning systems (GPS and/or GLONASS and other positioning sys-
tems).
The LPR consists of satellite timing systems (GPS and/or GLONASS and other position-
ing systems) and rubidium atomic clocks. The LPR can receive synchronization signals
from satellite positioning systems, and can synchronize to the PRC. The LPR is the syn-
chronization reference source of all provinces.
à Level-2 node clock (SSU-T) is the synchronization node for all cities to receive the LPR
synchronization reference source.
144 SJ-20230719162004-003 | 2023-10-30 (R1.0)

12 Synchronization Features
à Level-3 node clock (SSU-L) consists of highly stable crystal clocks

 Access network clock synchronization
The OLT access network synchronizes the clock to the uplink IP network (PTN/IP RAN) or
uplink TDM network by using the following three methods.
à Method 1: The clock source is on the aggregation layer and is provided by the upper-lay-
er network device. The OLT synchronizes the clock to the upper-layer networks. The
synchronization information between the OLT and the upper-layer networks, such as
IP network or TDM network, is transported by the Ethernet interface or TDM interface
through in-band transmission.
à Method 2: The clock source is on the aggregation layer and is provided by the upper-lay-
er network device. When the clock source reaches the edge of the aggregation layer, the
upper-layer network device restores the synchronization information and connects the
OLT through out-band clock interface.
à Method 3: The clock source is on the access layer and the OLT directly acquires syn-
chronization information through the dedicated clock interface. This method is only ap-
plicable to large access networks for high-precision synchronization.
The OLT can extract physical-layer clocks from the following interfaces:
à Ethernet interfaces, including 10 GE, GE, and 40 GE Ethernet interfaces. These inter-
faces are in-band clock interfaces used by IP networks through SyncE.
à TDM interfaces, including 155M SDH (STM-1) optical interface, 622M SDH (STM-4) op-
tical interface, and E1/T1 interface. These interfaces are in-band interfaces that the OLT
uses to synchronize clock to the SDH network in the uplink direction.
à External clock interfaces, including 2M HZ/BITS interfaces. These interfaces are clock in-
terfaces used by the OLT to directly access the clock network for clock synchronization.
The OLT can provide Ethernet interfaces directly through the Ethernet interface board, or
connect the ONU through the xPON interface. The ONU provides the clock interfaces to
connect the terminals which require clock synchronization. Downlink interfaces are classified
into three types:
à Ethernet interface, which is provided on the OLT Ethernet board or by the ONU to
achieve clock synchronization of downstream devices through SyncE.
à E1/T1 interface, which is a service interface provided by the xPON terminal ONU to con-
nect downstream devices for clock synchronization.
à External clock 2M Hz/BITS interfaces, which are clock interfaces provided by the xPON
terminal ONU to connect downstream devices through the dedicated clock interface for
clock synchronization.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 145

For the application scenarios of clock synchronization, refer to Table 12-1.
Table 12-1 Clock Synchronization Application Scenario

Synchronization mode Application Scenario Feature
Clock synchronization by TDM (E1/ The OLT PON carries 2G back- The OLT extracts clock from the
T1/STM-N) hauls and the OLT connects the SDH network as the system clock.
SDH network in the uplink direc- The OLT synchronizes the ONU
tion. through the physical-layer line
clock of the PON optical interface
in down direction.
Clock synchronization by CES The OLT PON carries 2G back- The OLT only transparently trans-
ACR hauls and the OLT connects the mits CES Ethernet packets and
Ethernet packet switching network The ONU achieves clock synchro-
in the uplink direction. nization by ACR.
1588v2 packets transparent trans- The OLT PON/P2P carries 3G and The OLT and ONU only transpar-
mission LTE mobile backhauls and the BS ently transmit the 1588 packets to
only conducts frequency synchro- ensure QoS, but do not handle the
nization. 1588 packets. The downlink device
recovers the frequency from the
1588 packets.
SyncE Clock synchronization The OLT PON/P2P carries 3G and The OLT uses the uplink interface
LTE mobile backhauls and the up- to synchronize the frequency by
link network supports SyncE. SyncE from the uplink network,
and uses the frequency as the
system clock. The OLT synchro-
nizes the frequency from the PON
’s physical lines to the ONU, or to
the BS by SyncE in P2P mode.
Clock synchronization by 1588 The OLT PON/P2P carries 3G The OLT terminates the 1588 clock
ACR and LTE mobile backhauls, and and extracts the frequency to act
achieves frequency synchroniza- as the system clock before sending
tion when the OLT only receives it to the PON and P2P card. In this
the 1588 clock. case, the OLT’s upper-layer net-
works do not support synchroniza-
tion.
External clock synchronization (2M The OLT PON/P2P carries 3G The OLT and extracts the 2M clock
Hz/BITS) and LTE mobile backhauls and from the clock interface card to act
achieves time synchronization as the system clock before sending
through frequency synchronization. it to the PON and P2P terminals. In
this case, the OLT upper-layer net-
146 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Synchronization mode Application Scenario Feature

works do not support synchroniza-
tion.
Benefit
Clock synchronization enables the OLT-based access network to carry TDM services or mobile
backhauls.
Principle
 Working modes of the OLT system clock

The OLT system supports standard stratum 3 clocks, which can work in the following
modes:
à Free running mode, in which the clock unit in the system is not controlled by the phase-
locked loop circuit. In this mode, the stability and precision of the frequency outputted
by the clock synchronization unit is related only to the characteristics of the crystal oscil-
lator. This mode applies when the external reference clock is lost for a long time or de-
grades seriously. Currently, the OLT uses stratum 3 clocks.
à Holdover mode, in which the clock synchronization unit in the system lose all external
reference clocks, or all the external reference clocks are degraded temporarily. In this
mode, the internal control circuit stores the frequency adjustment data obtained in tracing
mode to control the crystal oscillator and keep the crystal oscillator outputting the same
frequency as that in tracing mode. For standard stratum 3 clocks, the holding time must
exceed 24 hours.
à Locked mode, in which the clock unit in the system captures the external reference fre-
quency which is in the synchronization scope. By comparing the phases difference to
trace and lock the external reference frequency, the clock unit makes its own frequency
controlled by the external reference frequency.
 Clock input and output interfaces
On the network side, the OLT supports the following clock-extracting interfaces:
à Ethernet interfaces using synchronous Ethernet techniques
à TDM interfaces, including E1/T1/STM-1/4.
à 2M BITS/Hz.
à The clock recovered from IEEE 1588.
On the subscriber side, the interfaces that synchronize with the following the system clocks:
à Ethernet interfaces using synchronous Ethernet techniques
à GPON/XG-PON interface, which uses the physical-layer line clock of the optical interface
for synchronization
SJ-20230719162004-003 | 2023-10-30 (R1.0) 147

à EPON/10G-EPON interface, which uses the physical-layer line clock of the optical inter-
face for synchronization
 Clock processing principle of the OLT
All clock source inputs to the OLT, including the clock sources provided by boards and in-
terface cards, can be aggregated to the clock-selecting logic of the control switching board.
The priorities of these clock sources are set by the system software. The OLT selects clock
sources. The system clock provided by the locked-phase loop is used by all board slots.
Figure 12-2 shows the clock-processing principle of ZXA10 C600/C650/C620.
Figure 12-2 Clock-Processing Principle
The clocks extracted by all boards are converted into 8 K clocks and send to the controlled
switching board. The clock source and clock alarms from boards are sent to the CPLD on mas-
ter/slave switching boards. After receiving a clock signal, the clock selector on the CPLD calcu-
lates signals according to the SSM_QL (Quality Level) algorithm and alarms. The CPLD on the
switching board selects an clock from all clock sources according to the software configuration,
and sends to the system phase-lock loop for processing. The system phase-lock loop outputs a
19.44M system clock to each board.
The software supports two modes of selecting the clock source:
 The software automatically selects and switches clocks according to the clock level of each
clock line (SSM or ESMC).
148 SJ-20230719162004-003 | 2023-10-30 (R1.0)

 The clock level of each input signal is manually set, and the system automatically selects
and switches clocks.
In addition, the software also provides the following clock functions:
 It supports other output clocks besides 2M BITS and 2M Hz clocks, and supports the config-
uration and insertion of SSM bytes.
 The software enables users to set clock source switching by force, instead of based on the
QL policy.
 The software enables users to add a clock source. Clock source types include: internal, ex-
ternal, E1, STM-1/4, SyncE, and PTP clock.
 Users can set external clock input to the 2M BITS type or the 2M Hz type.
 Users can set external clock output to the 2M BITS type or the 2M Hz type.
 Users can adjust the threshold and offset of phase-lock loop frequency deviation.
 The software displays the status of the current clock source: free-run, pre-lock, out-of-lock,
and holdover.
 Users can detect and view all the existing alarms about clock sources, such as loss of
source, too high frequency deviation, loss of QL information, loss of signal, and loss of the
ESMC byte.
The software provides the clock-source priority-level selection functions:
 The OLT processes clock levels based on the SSM-QL protocol and selects a clock source.
 The clock source is selected based on the manually configured priority level of clock
sources.
 After the primary clock source fails or deteriorates, the OLT dynamically selects other clock
sources. The waiting time from normal operation to clock switch can be configured (Hold Off
Time).
 After the clock source is switched due to failure or deterioration of the primary clock source,
if the original clock source is restored, the software must supports clock source switchback.
To avoid frequent switching between clock sources, the Wait Restore Time can be config-
ured.
 After the external clock source fails, according to the hold-on frequency and time synchro-
nization of the internal clock source, the OLT continues to provide a clock to downstream
devices. The clock level is adjusted accordingly and notified to downstream devices through
SSM-QL messages.
Standard Compliance
 ITU-T G.8261 defines the overall requirements for synchronization and timing of packet net-
works.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 149

 ITU-T G.8262 defines the clock performance (EEC) for equipment in a synchronous Ether-
net.
 ITU-T G.8264 defines the system architecture and synchronization function modules in a
synchronous packet network.
 ITU-T G.827x defines the standards for implementation of time synchronization in a packet
network.
 IEEE 1588v2 defines the PTP protocol.
 NTP defines the IETF time synchronization protocol.
12.2 Synchronous Ethernet

Description
The OLT connects to both of the upstream and downstream devices through the Ethernet. Us-
ing SyncE technology, the OLT can synchronize with the upstream device through the uplink
SyncE interface and the downstream device through downlink SyncE interface.
In the scenario of the mobile backhaul, the OLT performs the frequency synchronization
through the SyncE technology, see Figure 12-3.
Figure 12-3 Synchronous Ethernet Application Scenario
The frequency synchronization procedure through the SyncE technology is described as fol-
lows:
1. The upstream network delivers the clock in the SyncE form to the OLT through an Ethernet
interface.
2. The OLT recovers the clock from the SyncE to the system clock. The OLT delivers the clock
through the physical line of the PON port to the ONU, and then delivers the clock to the BTS
in the SyncE format through the Ethernet interface.
150 SJ-20230719162004-003 | 2023-10-30 (R1.0)

3. The ONU synchronizes the clock from the PON port. The ONU synchronizes the clock in the
SyncE format to the BTS through the Ethernet interface.
Principle
The physical layer synchronization is widely used in the traditional SDH network. The synchro-
nous network node has a local clock with higher frequency accuracy and better reliability. This
clock can not only be a dedicated synchronization device (such as BITS/SSU), but also be a
device clock (such as SEC/EEC). Each node can extract the line clock from the physical links,
or acquire the clock from an external synchronization interface. It selects the clock with best
quality from more than one clock sources, locks the local clock to the best clock source, and
then delivers the locked clock to downstream devices. Through the step-by-step lock, the clocks
in the integrated network are synchronized to the primary reference clock (PRC) .The pack-
et-based network can use the similar technology.
The EEC is not only the transmitter clock of the Ethernet data interface, but also the clock
source of the output interface of the external synchronization. The EEC extracts the line clock
from the bit stream of Ethernet physical links, or acquires the clock reference from an external
synchronization interface. It makes the two clocks as the input of the system clock selection
function, to lock the system clock to the best clock source. The frequency offset value of the
EEC free oscillation is less than 4.6 ppm, while that of the traditional Ethernet clock is 100 ppm.
The EEC performance includes the frequency accuracy, holdover performance, output jitter and
wander, and input jitter and wander tolerance.
The synchronous Ethernet interface is the data interface of synchronous Ethernet equipment. It
can be configured to run in synchronous or non-synchronous modes. The peer in synchronous
mode can exchange data with that in non-synchronous mode, but cannot exchange data with
that in clock synchronization mode. Only if both of two peers operates synchronous mode, the
clock synchronization can be exchanged.
The ESMC is a one-way broadcast channel in the MAC layer. It is used for transmitting SSM in
synchronous mode between devices, including clock quality level (QL), path, port priority. A de-
vice can selects the best clock according to SSM.
The synchronous Ethernet can only implement frequency synchronization.
12.3 Time Synchronization

Description
 Reference architecture of the time synchronization network
SJ-20230719162004-003 | 2023-10-30 (R1.0) 151

The reference architecture of the time synchronization network is similar to that of the syn-
chronization network, which is a hierarchical architecture. Clocks on different levels have dif-
ferent precision requirements, where:
à Stratum0 is the Primary Reference Source (PRS), such as the UTC, GPS, or national
time standard.
à A Stratum1 time server directly synchronizes the time from the PRS, and after obtaining
the UTC time, sends the time to Stratum2 time servers through NTP or in other mode.
à Stratum2 and Stratum3 time servers transmit and allocate time signals. It is recommend-
ed that the service scope do not exceed 500 workstations. In a network with complicated
architecture and too many nodes, a Stratum2 time server is recommended.
According to the precision level and importance, time servers are theoretically divided into
16 levels in range of level 0 to level 15 or more levels, but actually no more than six levels
are used in actual situations. A lower level indicates higher precision and importance. Time
is allocated from lower levels to higher levels, that is, from level 0 to level 15.
Based on the needs of applications in wireless networks, the NTP-based time synchroniza-
tion and transmission mechanism no longer meet the requirements of high-precision time
synchronization (typically in wireless networks such as the TDD-LTE, LTE-A, CDMA2000,
WiMAX, and TD-SCDMA), so time transmission methods with higher precision are required.
 Time synchronization in the access network
The Optical Line Terminal (OLT) supports three time synchronization modes:
à 1PPS transparent transmission mode: Time signals are input from the 1PPS+TOD inter-
face connected to the CLCT board, and the controlled switching board sends time sig-
nals to each board. To ensure good 1PPS transmission performance, an 2M input clock
with the same source as 1PPS must be provided to the OLT to ensure good output an-
ti-jitter performance. —
à 1588 slave mode (the OLT and the ONU act as the Boundary Clock (BC) jointly): If only
an uplink board and a PON interface board are configured on the OLT, the OLT acts as
an independent 1588 slave, which transmits restored 1PPS+TOD messages from 1588
packets to the ONU through the PON layer. After the ONU restores 1PPS+TOD mes-
sages, 1588 master on the ONU regenerates a 1588 protocol packet. If the OLT oper-
ates in 1588 slave mode, its frequency comes from two sources: physical layer clock (2M
or SyncE), or the restored frequency according to the 1588 protocol. The restoration per-
formance of 1PPS is better in physical layer clock +1588 hybrid mode.
à 1588 BC mode: When a P2P board is configured on the OLT, the P2P board acts as
1588 master and the OLT (PTP module) act as 1588 slave, the OLT transmits 1PPS
+TOD messages to the P2P board. The CPU and the FPGA on the P2P board jointly im-
plement the 1588 master function, and the protocol stack of 1588 master resides on the
152 SJ-20230719162004-003 | 2023-10-30 (R1.0)

CPU. The FPGA processes real-time timestamps. The NP on the P2P board sends and
receives 1588 protocol packets.
For time synchronization application scenarios, refer to Table 12-2.
Table 12-2 Time Synchronization Application Scenarios

Synchronization Application Scenario Feature
mode
1PPS+TOD interface Mobile backhaul in the 3G network and The OLT takes the synchronized exter-
synchronization the LTE network are borne in OLT PON/ nal clock as the system clock, and trans-
P2P mode to implement frequency and mits 1PPS+TOD messages.
time synchronization. There are two sce-
narios:
 1PPS+TOD input to implement fre-
quency and time synchronization
based on the 2M clock synchroniza-
tion
 External 2M clock to implement fre-
quency synchronization
PTP (1588v2) interface Mobile backhaul are borne in OLT PON/ It is recommended to use SyncE to im-
time synchronization P2P mode to implement frequency and plement frequency synchronization in
time synchronization. There are two sce- both scenarios. The OLT extracts the
narios: SyncE clock to act as the system clock,
 The OLT+ONU jointly implement the and terminates 1588v2, recovers 1PPS
1588BC function +TOD messages and sends the mes-
 The OLT implements the 1588BC sages to downlink devices. t.
function, and the P2P acts as the
1588v2 master.
Principle
 1PPS+TOD principle
The default baud rate of the TOD message is 9600 bps, and there is no parity check. A TOD
message contains one start bit (represented by a low level), one stop bit (represented by a
high level), and eight data bits (idle frames, represented by high levels). The TOD message
must be transferred 1 ms after a 1 1PPS rising edge occurs and must be completed trans-
ferred within 500 ms. After that, the TOD message indicates the time when the 1 1PPS ris-
ing edge is triggered.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 153

1PPS and TOD information is transmitted in 422 level mode, RJ45 connectors are used as
physical connectors, and electrical features meet requirements of the 422 electrical stan-
dard.
The TOD protocol uses binary node for encoding. Figure 10-4 shows the structure of a TOD
frame. Figure 12-4 shows the structure of a TOD frame.
Figure 12-4 TOD Frame Structure
A TOD message is transmitted in a complete byte for checksum and protection. Messages
are classified on two levels: message type and message ID. The domains exceeding one
byte comply with the Big Endian specification. bit0 represents the Lowest Significant Bit (
LSB) in the byte. When a byte is sent, bit0 is sent first.
 Basic principle of 1588v2
IEEE 1588 synchronize time in master/slave mode. The master clock periodically releases
time information through PTP packets. The slave clock estimates network delay and time
deviation according to the receiving time of the received PTP packet, and adjusts the local
clock accordingly. Only with hardware support, can the 1588 protocol obtain the accurate
timestamp of a PTP packet passing through the equipment outbound interface, thus obtain-
ing higher time synchronization precision.
The 1588-based time synchronization process is divided into two phases: offset measure-
ment phase and delay measurement phase. Figure 12-5 shows a PTP message flow.
154 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Figure 12-5 PTP Message Flow
The deviation measurement phase is used to correct the time difference between the master
clock and the slave clock. During the offset correction process, the primary clock periodical-
ly sends a definite synchronization message (Sync message) at T1, which includes a time-
stamp that describes the estimated packet sending time. The slave clock records the time
T2 when this Sync message is received locally. Because the timestamp included in the Sync
message is the estimated sending time instead of the real sending time, the master clock
sends a Follow_Up message after the Sync message. The Follow_Up message includes the
accurate timestamp T1 when the Sync message is sent. The slave clock obtains the time T1
when the Sync message is actually sent out and the time T2 when the Sync message is re-
ceived.
The delay measurement phase is used to measure the delay caused by network transmis-
sion. To measure the network transmission delay, IEEE 1588 defines a delay request pack-
et Delay_Req. After receiving the Sync message, the slave clock sends a Delay_Req pack-
et at the T3 time. After receiving the Delay_Req packet, the master clock fills in the accurate
time of receiving Delay_Req T4 into the delay response packet Delay_Resp, and sends it to
the salve clock.
Because,
Delay + Offset = T2 - T1
Delay - Offset = T4 - t3
So,
Delay = ((T2 - T1) + (T4 - T3))/2
Offset = ((T2 - T1) - (T4 - T3))/2
SJ-20230719162004-003 | 2023-10-30 (R1.0) 155

Thus, according to the values of T1, T2, T3, and T4, and the above formula, the slave clock
accurately calculates the network delay and the time deviation with the master clock, and
adjusts the local clock accordingly. Thus, through the exchange of the synchronization in-
formation, precise synchronization is implemented between the slave clock and the master
clock.
 Principle of time synchronization on the GPON layer
Time synchronization on the GPON layer is based on the super frames synchronization
mechanism between the OLT and the ONU. On the 1PPS arrival time, the OLT PON
MAC records the current super-frame counter, the offset inside frames, and TOD. G.984.3
Amendments II defines that the TOD message transmitted in an OMCI message has 14
bytes, where the first 4 bytes are super-frame bytes and the last 10 bytes are TOD infor-
mation. The GPON layer calculates the obtained in-frame offset into the corresponding ab-
solute time, and places in the 10-byte TOD message. In the 10-byte TOD message, the first
6 bytes indicate the information above the second level, while the last 4 bytes indicates the
information on the nanosecond level.
The OLT sends the OMCI message in this format to the ONU, and the ONU restores the
corresponding 1PPS according to the synchronization mechanism.
 Time synchronization mechanism between the OLT and the ONU
The OLT receives the 1PPS at an interval of 1 s, that is, the time difference between T1 and
T2 is 1 s. After the OLT receives 1PPS, it records the current time T1 and transmits it to the
ONU through an OMCI message. The ONU restores the 1PPS according to the time T4 that
is calculated based on the T1 time, and generates a 1PPS at T4, so that T4 and T2 are gen-
erated at the same time. The 1PPS relationship between the OLT and the ONU is shown in
Figure 12-6.
Figure 12-6 1PPS Relationship Between the OLT and the ONU
T4=T3+1s-△T. Where, △T is the transmission delay of optical fibers, which can be calculat-
ed through the eqd PLOAM message. The ONU calculates the △T and restores 1PPS ac-
cording to the corresponding OMCI message.
The EPON system also supports time synchronization transmission accordingly. The ba-
sic principle is similar to that of the EPON, that is, by using the MPCP counter synchronized
156 SJ-20230719162004-003 | 2023-10-30 (R1.0)

by the OLT and the ONU. The OLT obtains the technical value of MPCP when the 1PPS
time arrives, and transmits this message to the ONU through the timesync message inside
802.1AS. After receiving this message, the ONU restores the corresponding 1PPS and TOD
based on the local MPCP counter and EqD calculation results.
 Principle that the OLT and the ONU jointly act as the BC
à Basic Principle
The OLT restores 1PPS+TOD messages as the 1588v2 slave clock. The PON interface
transmits 1PPS+TOD messages to the ONU according to the TOD over PON protocol.
According to protocol compensation, the ONU obtains the accurate 1PPS+TOD informa-
tion. The ONU transmits the restored time information to the downstream device to im-
plement the 1588v2 master function.
The PON OLT is synchronized to the upstream device to implement the slave function
through the standard 1588v2 protocol. 1PPS+TOD messages are transmitted between
the PON OLT and the ONU according to the corresponding standard protocol mecha-
nism.
à GPON processing flow
The OLT implements the 1588 slave function. The OLT extracts the clock of the syn-
chronous network from the upstream Ethernet interface, and transmits it to the controlled
switching board as the system clock. The 1588 chip on the controlled switching board
processes the 1588 messages and puts a hardware timestamp to process reverse re-
sponse messages. The 1588 slave chip supports the normal 1588 mode and the syn-
chronous Ethernet mode 1588. The 1588 slave chip transmits the restored 1PPS+TOD
messages to the PON interface board, which then transmits the messages to the ONU
through the OMCI channel according to the mechanism specified in the G.983.3 proto-
col. The ONU restores the corresponding time and frequency information, and transmits
to the BTS or the downstream network node.
The ONU outputs the time information in either of the following two modes: the ONU di-
rectly generates a new PTP message as the 1588 master, and releases the 1588 syn-
chronization message to lower-level devices; according to interface requirements of the
downstream BTS, the ONU converts the obtained time and frequency information into a
1PPS+TOD message and transmits it to the BTS.
à EPON processing flow
The OLT transmits 1PPS+TOD messages to the PON interface board. The PON inter-
face board calculates the MPCP counter of an ONU, takes the value as ToDx at the time
X, and notifies this value to the ONU through an OSSP packet. The ONU compensates x
according to the MPCP counter value S, and obtains the accurate time real_ToD. When
the MPCP counter value reaches S, the ONU sets the local time to real_ToD. The ONU
SJ-20230719162004-003 | 2023-10-30 (R1.0) 157

generates a new PTP protocol packet as the IEEE 1588 master, and sends it to the low-
er-level 1588 slave through the Ethernet port, or directly outputs 1PPS+TOD signals to
downstream network nodes.
à 1588v2 implementation through the P2P board
When a P2P interface board is configured, while acting as the 1588 salve, the OLT
sends 1PPS+TOD messages to the P2P interface board, which implements the 1588
master function. The protocol stack of 1588 master is resided on the P2P interface
board. The P2P interface board processes real-time timestamps, and sends and re-
ceives 1588 protocol packets.
158 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Chapter 13
EOAM Features
Table of Contents
802.3ah..................................................................................................................................... 159
802.1ag/Y.1731 (CFM)............................................................................................................. 160
13.1 802.3ah
Description
The Ethernet in the First Mile (EFM) is defined in IEEE 802.3ah (Clause 57 of Section 5) for de-
tecting, monitoring, and maintaining directly connected links, particularly the links on the access
side.
Application Scenario and Specifications
On the OLT, EFM monitors physical directly-connected point-to-point links and provide opera-
tion statistics, including the frame transmission error ratio, link transmitting/receiving rate, and
loss statistics. EFM guarantees L2 link transmission quality by monitoring links in real time,
helping administrators maintain the links and reducing maintenance costs.
 Supports active and passive modes. The OAM packet transmitting interval can be set as re-
quired (range: 1–10 seconds, default: 10).
 Supports link monitoring and detection, and supports the following general link events: Er-
rored Frame Event, Errored Frame Period Event, and Errored Frame Seconds Summary
Event.
 Supports the transmission of remote failure indication packets, processing of remote failure
indication packets received from the peer, and transmission of the peer failure information to
the upper-layer protocol.
 Supports transmitting and receiving remote loopback messages and event notifications. It
also supports querying and displaying the loopback statistics.
EFM has the following features:
SJ-20230719162004-003 | 2023-10-30 (R1.0) 159

1. EFM uses its own protocol packets to determine whether EFM is enabled on the peer, and
interact with the peer to determine whether negotiation can be completed based on the con-
figurations of the local and peer devices.
2. After the negotiation is completed, EFM implements link monitoring, for example, recording
the error frames or symbols transmitted over the link.
3. When the number of error frames or symbols exceeds the threshold, EFM triggers an event
notification to inform the local and peer devices, so that the network administrator can learn
about the link status.
4. EFM can also use the remote loopback function to detect the packet loss caused by receiv-
ing rate differences of the local and peer ends or by link failure.
5. EFM uses slow protocol packets, which cannot be forwarded and can only be used on phys-
ically directly-connected devices.
13.2 802.1ag/Y.1731 (CFM)

Description
IEEE 802.1ag Connectivity Fault Management (CFM) is used for logical Point-to-Point (P2P)
connection detection and provides the loopback and linktrace functions.
Application Scenario and Specifications
CFM forwards packets by using the same VLAN rules as services use, to detect and separate
service VLANs and report connectivity faults. It is a major protocol used on the data link lay-
er for link monitoring, detection, and location. It can implement Ethernet data link detection for
most P2P or simulating P2P links that support full duplex without dependence on specific sys-
tem interfaces.
A network can be divided into the user domain, service provider domain, and carrier's internal
domain. A level (range: 0–7) is specified for each domain. The domain level determines the in-
clusion relationships of domains. A domain of a higher level can include a domain of a lower
level, but the domain of the lower level cannot include that of the higher level. The domains of
the same level cannot include each other, and the largest domain has the highest level. Two
domains can be internally or externally tangent to each other or one domain can include the
other, but they cannot intersect. This type of domain inclusion relationships defined for CFM
can help locate faults.
 User domain: end-to-end user connectivity, for example, from a UNI interface of the ONU
connected to a user IP host to an IP interface of the BNG connected to the service server.
 Service provider network domain: A network boundary to another can cross multiple carri-
ers, for example, from an ONU on the user side to the BNG on the network side.
160 SJ-20230719162004-003 | 2023-10-30 (R1.0)

13 EOAM Features
 Carrier's internal domain: connection crossing L2 devices, for example, the connection from
the OLT to the BNG with the convergence switch AGS between them.
 Ethernet link: An Ethernet link does not cross L2 devices. Connection faults can be located
through EFM, GPONOAM, or OTDR.
IEEE 802.1ag defines the basic functions of CFM, including the following:
 CCM-based fault detection: A MEP periodically sends and receives CCM messages to de-
tect network connectivity, and connectivity failure and unintended connectivity (error connec-
tion) can be detected.
 LB-based fault determination and isolation: The administrator can determine faults through
LBM/LBR messages and isolate the faults.
 LT-based path discovery: A MEP uses LTM/LTR messages for path discovery, and the path
from a MEP to another MEP or to a MIP can be traced.
ITU-T Y.1731 includes the CFM feature defined in IEEE 802.1ag, which, however, has the fol-
lowing differences:
 Supports AIS alarm reporting from the lower layer (service layer) to the upper layer (cus-
tomer layer), so that the customer layer can suppress alarms and drive switchover quickly.
In general, the AIS transmission direction is contrary to the CCM transmission direction on
the service layer. The AIS function can be enabled as required. If the local layer (service lay-
er) provides AIS protection, the AIS function can be disabled.
 Supports the RDI function, so that after discovering any fault in the receiving direction, the
MEP can send an RDI to the peer. The peer immediately implements switchover before a
CCM detection cycle expires.
 Supports LBM multicasting, where the peer MEP responds with LBRs through unicasting.
 Maintenance Entity Group (MEG)

A MEG is a set of MEs that belong to the same service connection and have the same ad-
ministration level in an administrative domain.
 Maintenance Point (MP)
An MP is configured on a port of the ME and belongs to a MEG. MPs can be divided into
MEPs and MIPs.
à Maintenance Association End Point (MEP)
A MEP is uniquely identified by a MEPID (integer, range: 1–8191) in a MEG. A MEP de-
termines the range and boundary of the maintenance domain. The MEG of the MEP de-
termines the VLAN attribute and level of packets sent by the MEP.
The MEP level determines the level of packets that the MEP can process, and is the
same as the level of packets that the MEP sends.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 161

When a MEP receives packets higher than the MEP level, the MEP forwards the pack-
ets over the original path. When a MEP receives packets equal to or lower than the MEP
level, the MEP does not forward the packets, to ensure that the packets in a low-level
maintenance domain are not transmitted to a high-level maintenance domain.
MEPs can be divided into down MEPs and up MEPs based on the directions.
The MEP direction indicates the position of the MEP on the port. A down MEP sends
packets through its own port, and an up MEP uses another port of the device to send
packets other than its own port.
à Maintenance Association Intermediate Point (MIP)
Located in a maintenance domain, a MIP cannot send CFMs, but can respond to LBMs
and LTMs.
The MEG of the MIP determines the VLAN attribute and level of packets received by the
MEP.
A MIP can operate with a MEP to implement functions similar to ping and tracert. Sim-
ilar to a MEP, when a MIP receives packets higher than its level, it does not process
the packets but forward the packets over the original path. When a MIP processes only
packets equal to or lower than its level.
By default, no MIP is configured on the device.
13.2.1 ETH-CCM
A MEP periodically sends and receives CCMs to detect network connectivity, and connectivity
failure and unintended connectivity (error connection, for example, a connection with different
MEG levels or MEG IDs) can be detected.
A CCM is originated on a MEP and terminated on another MEP. The NE needs to record the lo-
cal MEP and remote MEP (RMEP) information. If the receiver does not receive any CCM from
the RMEP within consecutive three transmission intervals, a local link failure alarm is generat-
ed.
Figure 13-1 ETH-CCM
162 SJ-20230719162004-003 | 2023-10-30 (R1.0)

13 EOAM Features
13.2.2 ETH-RDI
For a full-duplex link that physically separate transmitting and receiving signals, when the MEP
detects a local link failure, it can add an RDI flag in the transmitted CCM, helping the remote
MEP discover the fault quickly.
Figure 13-2 ETH-RDI
13.2.3 ETH-LB
CCMs can be used to discover faults but cannot locate faults. Loopback (LB) is an OAM tool
that the network administrator can use to locate faults. The LB function is similar to the ping
function on the IP layer. An LB message is originated on a MEP and terminated on another
MEP or a MIP. After receiving the LBM, the peer MIP or MEP responds with a LBR. The LB-
originating MEP can send LBMs multiple times, and determine the packet loss rate based on
the number of times that LBRs are received.
Figure 13-3 ETH-LB
ITU-T Y.1731 extends the LB function to LB multicasting, so that a MEP can send multicast
LBMs to other MEPs in the MEG, which respond with unicast LBRs. The MIP transparently
transmits multicast LBMs. In this way, the originating MEP can detect the connectivity to multi-
ple peer MEPs or obtain the remote MEP information when it does not have such information.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 163

13.2.4 ETH-LT
The Link Trace (LT) function is similar to the tracert function on the IP layer. It is used to obtain
the MAC address of the intermediate device that an Ethernet link between two devices pass-
es through, helping locate the link interruption position after a link failure occurs. Each MIP de-
vice between the LT-originating MEP and destination MEP responds with an LTR to the orig-
inating MEP, and continuously forwards the LTM message after decrementing the TTL in the
LTM message by one, until the LTM reaches the destination MEP or the TTL is zero. The orig-
inating MEP obtains the MAC addresses and relative positions of all the devices between the
two MEPs and the failed link section through LTRs.
Figure 13-4 ETH-LT
13.2.5 ETH-AIS
AISs are used for P2P Ethernet connections. When an Ethernet connection fails, an AIS alarm
is reported to the MEP of a higher level (contrary to the link failure direction)
As shown in Figure 13-5, the link between the AGS and the BNG serves the connection be-
tween the OLT and the BNG. The P2P connection between the AGS and the BNG does not
provide redundancy protection, so when the level-3 MEPs of the AGS and BNG detect a CCM
failure between them, the level-3 MEPs immediately send AIS alarms to all MEPs of a higher
level in the opposite direction, for example, the level-5 MEPs of the OLT and BNG. The failed
link serves multiple OLTs connected to the AGS, so these OLTs immediately determine through
AIS alarms that the link fails and do not need to discover the link failure by sending CCMs.
There are multiple OLTs connected to the AGS, so one MEG level involves multiple OLTs (a
MEG includes more than two MEPs). In this case, the AIS function is not applicable. When the
link between an OLT and the AGS fails, it is not recommended that the AGS send AISs to the
BNG, because MEP peer relationships exist between the AGS and other OLTs.
164 SJ-20230719162004-003 | 2023-10-30 (R1.0)

13 EOAM Features
Figure 13-5 ETH-AIS
SJ-20230719162004-003 | 2023-10-30 (R1.0) 165

Chapter 14
System Management Fea-
tures
Table of Contents
SSH...........................................................................................................................................166
SFTP.........................................................................................................................................166
File System...............................................................................................................................167
User Management.................................................................................................................... 168
Command Privilege Level........................................................................................................ 169
SNMP........................................................................................................................................169
14.1 SSH
Secure Shell (SSH) is defined by the IETF network working group. It is a security protocol es-
tablished on the basis of the application layer and transport layer.
Traditional network service programs such as FTP, POP, and Telnet use clear text to transfer
data. Therefore, user names and passwords are vulnerable to man-in-the-middle attacks. Com-
pared with traditional network service programs, SSH is more reliable. It provides security for
remote login sessions and other network services, and has the following advantages:
 The SSH protocol prevents information leakage in remote management processes.
 The SSH protocol encrypts all transferred data, and prevents DNS spoofing and IP spoofing.
 The SSH protocol transfers compressed data, accelerating transmission.
 The SSH protocol is usually used to replace Telnet, and provides a secure "channel" for
FTP, POP, or even PPP.
14.2 SFTP
Overview
SFTP is a network protocol that enables remote users to log in to a server reliably and perform
file management, file transfer, and other operations over SSH connections. This provides high
security guarantee for data transmission. As a high-layer application protocol, SFTP is relatively
independent of the basic SSH architecture.
166 SJ-20230719162004-003 | 2023-10-30 (R1.0)

14 System Management Features
Maximum Session Idle Time Configured on the SFTP Server
The idle time controls the session idle time in a connection. This can prevent session resources
from being occupied and used up.
After the idle time is configured on the server, a timer is started for each login connection (the
timeout time is equal to the idle time), and the login time is recorded. When a timer expires, the
corresponding connection is disabled.
If any command is executed for a login connection before the corresponding timer expires, the
timer is reset when the command is received.
If a timer is re-configured on the server, all connections are queried to calculate the current idle
time of each connection. If the newly configured idle time is exceeded, the corresponding con-
nection is disabled immediately. Otherwise, a new timer is configured based on the difference
between the old idle time and the new idle time.
ACL Rule Names Configured on the SFTP Server
SFTP provides the configuration of IPv4 and IPv6 ACL rule names. ACLs are used to filter the
IP addresses that clients use to log in to the SFTP server. If no ACL is configured on the SFTP
server, users are allowed to log in to the server.
14.3 File System

Overview
The file system consists of hard disks, a Flash and an NVRAM. The MPU board provides a
USB interface that can be used to back up or add configuration files, version files, and log files
quickly and conveniently.
Hard Disk
The hard disks store version files, data files, system breakdown files, and operation logs. It has
two partitions, which are mapped to the /sysdisk0 and /sysdisk0 folders under the root di-
rectory of the Linux system respectively.
 /sysdisk0 partition: system partition that stores version files, important log files, and da-
ta files. Users have the read permission, but do not have the write permission. Users cannot
delete or rename files, but can view files by running the more command. The /sysdisk0
partition does not support the format operation.
à /sysdisk0/verset: stores version set files in .set format. The ZXA10 C600/C650/
C620 obtains version set files when it starts through a network, and saves version set
files in the verset directory.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 167

à /sysdisk0/config: stores database configuration files in .zdb and .ini formats. Con-
figuration files in .zdb format store configuration commands in binary form. In this direc-
tory, DATA0 and DATA1 save the same file synchronously in backup mode. DATA0 is the
active file, and DATA1 is the backup file.
à /sysdisk0/DATA0: stores the startrun.dat text configuration file. The
startrun.dat file is a configuration file in command line form, which is saved when the
write txt command is run.
à System breakdown files and exception log files: system breakdown files include the Ex-
c_Omp.txt and Exc_pp.txt files in the /sysdisk0/run_log directory and the files
in the /sysdisk0/run_log/EXCINFO directory.
 /datadisk0 partition: data partition that stores log files and data files relevant to users'
routine operations and maintenance as well as data files stored by users as needed. Users
have read and write permissions.
Service and alarm log files are stored in the /datadisk0/LOG directory, but the command
log file (that is, the cmdlog file) is stored in the /sysdisk0/usrcmd_log/ directory.
NVRAM
The NVRAM is used to save booting information, including the IP address of the device man-
agement port, IP address of an FTP server, and configuration loading mode.
14.4 User Management

To maintain and manage the ZXA10 C600/C650/C620, users need to log in to it in SSH, Telnet,
or FTP mode. User management implements the configuration, authentication, and authoriza-
tion of users who have logged in to the ZXA10 C600/C650/C620.
The user-name command is used to configure or delete users. By running the user-name
command, you can configure user names and passwords (clear text passwords of 3–32 bits
long or cipher text passwords of 64 bits long).
By configuring functions related to Authentication, Authorization and Accounting (AAA), user
management provides user authentication and authorization in the following modes:
 None-authentication and none-authorization
 Local authentication and authorization
 Remote Authentication Dial In User Service (RADIUS) authentication and authorization
 Terminal Access Controller Access-Control System Plus (TACACS+) authentication and au-
thorization
 RADIUS hybrid authentication and authorization
 TACACS+ hybrid authentication and authorization
168 SJ-20230719162004-003 | 2023-10-30 (R1.0)

14 System Management Features
When a user logs in to the ZXA10 C600/C650/C620 through SSH, Telnet, or FTP, user man-
agement queries the authentication template corresponding to the user to obtain the authentica-
tion mode, and authenticates the user. If the authentication is passed, the user is authorized. If
the authentication fails, user management returns failure information.
After the user passes the authentication, user management authorizes the user. After the user
successfully logs in and is authorized, user management displays a command view based on
the user's privilege level. Therefore, the user cannot view or run commands with privilege levels
higher than the user's privilege level, but can view and run commands with privilege levels low-
er than or equal to the user's privilege level. The local-privilege-level command is used to set
user privilege levels, which range from level 0 (the lowest level) to level 15 (the highest level).
Level 0 is used by default.
14.5 Command Privilege Level

The ZXA10 C600/C650/C620 supports the command privilege level function. Command priv-
ilege level management is used to configure command privileges. Users can run the privi-
lege command to configure the privilege of a command.
Command privilege levels range from level 1 to level 15. Different commands can be config-
ured with different privilege levels. After a user logs in, a command view is displayed based on
the user's privilege level. Therefore, the user cannot run commands whose privilege levels are
higher than the user's level. Users with the highest level (that is, administrators with level 15)
can set privilege levels for commands.
14.6 SNMP
The Simple Network Management Protocol (SNMP) is the most popular Network Management
System (NMS) protocol, and belongs to the application layer of the Transfer Control Protocol/In-
ternet Protocol (TCP/IP) stack. The SNMP module is at the highest layer of the OLT system.
Administrators use SNMP as a main way to operate, control and maintain the OLT. In order to
perform network management, users use NMS software to send and receive SNMP packets
between the managed network elements and the management station.
The basic process of SNMP network management is as follows:
1. A unique ID (OID) is allocated to the object to be managed in the OLT. The allocation of OID
is determined in a unified way by the Request For Comments (RFC).
2. When users need to read or modify the value of an object, the object OID and operation
type (read or write) are sent to the OLT as an SNMP request packet.
3. The SNMP agent in the OLT finds the object data based on the OID, performs the corre-
sponding operations, and then sends the result as an SNMP response packet to the user.
By default, SNMP uses UDP as the transmission protocol.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 169

Chapter 15
System Security Features
Table of Contents
Anti-DoS Attack........................................................................................................................ 170
Anti-IP/ICMP/TCP Attack..........................................................................................................171
ACL........................................................................................................................................... 171
IP Spoofing Prevention............................................................................................................ 172
15.1 Anti-DoS Attack

Description
In a Denial of Service (DoS) attack, a malicious user sends a large number of protocol pack-
ets to the system, resulting in that the system cannot process users' normal service requests.
In general, the packet transmission rate is restricted and the DoS attacker is blocked to prevent
DoS attacks.
The ZXA10 C600/C650/C620 identifies attackers by monitoring the rate of protocol packets
sent by users to the CPU and generates a blacklist. The system processes the packets sent by
blacklisted users to the CPU in accordance with the configured policy. The supported protocol
options include IGMP, DHCP, ARP, PPPoE, and ALL (ALL means all the packets sent to the
CPU). A user identity on the ZXA10 C600/C650/C620 means a VPort or an Ethernet port on
the user side. The protocol packet rate means the number of protocol packets received within
a particular period. A threshold is set for the number of packets received within a cycle. When
the number of protocol packets received on a port exceeds the threshold within multiple con-
secutive cycles, the user is added to the blacklist. The statistical period, threshold, and number
of consecutive cycles can be set as required. The processing policy of packet discarding or rate
restriction can be configured for a specified protocol (involved in attacks) or all protocols. In this
way, CPU overload can be prevented, ensuring normal protocol processing.
The ZXA10 C600/C650/C620 continuously traces the protocol packets of blacklisted users. If
the packet rate of a blacklisted user is lower than the threshold within consecutive cycles, the
170 SJ-20230719162004-003 | 2023-10-30 (R1.0)

15 System Security Features
user can be removed from the blacklist, and the corresponding rate restriction or blocking policy
does not apply. The ZXA10 C600/C650/C620 supports the following manual operations: adding
users to the blacklist, forcibly restricting the packet rate or blocking the packets on a port, and
querying blacklisted users.
15.2 Anti-IP/ICMP/TCP Attack

Description
The destination IP address of packets sent by a normal user is not the management IP address
of the accessed device (except as particularly planned by the carrier). A malicious user fakes IP
packets where the destination IP address is the management IP address, to attack the access
device. A common IP attack is as follows: The attacker sends a large number of requests to the
access device within a short period, seeking to make the system unable to process legitimate
requests due to overload. An IP attack can also be considered as one type of DoS attack.
The Internet Control Message Protocol (ICMP) is a protocol of the TCP/IP family, and is used
between IP hosts and routers to transfer control messages (such as ping and trace route mes-
sages). To locate a fault, an ICMP message can be sent from the peer device to the access de-
vice to determine network connectivity and route availability. In general, the maintenance engi-
neer needs to ping the access device only on the higher-level device or cascaded device other
than on the user terminal, to prevent malicious users from pinging and attacking the device. In
another way of attack, the source IP address and destination IP address of IP packets are set
to the same one to attack the OLT.
With the anti-IP attack feature, the ZXA10 C600/C650/C620 can prevent IP attacks by identifying
and discarding the received IP packets whose destination IP address is the IP address of the
ZXA10 C600/C650/C620. With the anti-ICMP attack feature, the ZXA10 C600/C650/C620 can
prevent ICMP attacks by identifying and discarding the received ICMP packets whose destination
IP address is the IP address of the ZXA10 C600/C650/C620. It also checks the source IP address
and destination IP address of IP packets. If they are the same, the system discards the packets.
15.3 ACL
Description
Common security threats on the Internet include the following:

 Illegal use: Resources are accessed by unauthorized users (illegal users) or by users in an
unauthorized way (illegal permissions). For example, an attacker accesses the computer
system for illegal use of resources by guessing the username and password.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 171

 Denial of service: An attacker intentionally exploits network protocol defects or brutally over-
loads the system to make the target PC or network unavailable to intended users or unable
to provide services. For example, an attacker continuously sends a large number of request
packets or malformed packets to the server within a short period, overloading the server and
prevent legitimate requests from being processed.
 Data tampering: An attacker modifies, deletes, delays the transmission of, resorts, or inserts
a false message into system data or message streams, damaging the data consistency.
 Information theft: An attacker eavesdrops to intercept key data or information other than di-
rectly intruding into the target system.
The above security threats can be removed by configuring an ACL for packet filtering.
An ACL contains multiple match rules executed in order and corresponding actions (includ-
ing passing and discarding). Each rule specifies the contents to be matched for a packet field.
Packet fields include L3 and L2 fields. L3 fields include the source IP address, destination IP
address, IP protocol type, source and destination TCP/UDP port numbers, and DSCP. L2 fields
include the VLAN, source MAC address, destination MAC address, CoS, and Ethernet protocol
type.
Feature
A vOLT supports 1 to 699 ACLs. A maximum number of 512 ACL templates are supported.
15.4 IP Spoofing Prevention

Feature Introduction
IP spoofing means that a malicious user fakes the IP address in packets for network attack. The
attacker can fake the IP address of a normal user to make services unavailable to the user. IP
spoofing prevention means that the system can prevent attacks that use fake IP addresses.
Through static configuration or dynamic tracing of an access procedure, the system binds the
correct IP address with the user port and checks whether the source IP address of IP packets
from the user port is the same as the correct one. If they are different, the system determines
that they are fake packets and discards the packets. This function is also called IP Source-
Guard.
 Static binding
In static binding, the binding information needs to be manually entered. To cancel the bind-
ing relationship, it also needs to be performed manually.
172 SJ-20230719162004-003 | 2023-10-30 (R1.0)

15 System Security Features
 Dynamic binding
The system monitors users going online or offline through DHCP. When a user becomes on-
line, it dynamically obtains the source IP address of the user, and binds the source IP ad-
dress with the user port (VPort or Ethernet port). To strengthen the binding relationship, the
VLAN and source MAC address of the user can also be bound. These items are checked
during communication. If any item does not match the binding relationship, the packets are
discarded. When a user becomes offline, the system unbinds the source IP address of the
user from the port and other attributes.
 Binding relationship restoration
If the device is upgraded or restarted, the dynamic IP binding relationship is lost, and the
user needs to go online again, so that a new binding relationship can be established. If the
user does not go online again, data would be blocked due to binding relationship loss. For
DHCP access, the IP lease does not expire, so the user end does not start the DHCP ac-
cess procedure again even if data is blocked. In this case, the user cannot access the net-
work. Therefore, the ZXA10 C600/C650/C620 needs to store the IP binding information for
DHCP access on the flash storage or remote server. After the ZXA10 C600/C650/C620 is
restarted, it restores the IP binding information from the storage or remote server.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 173

Chapter 16
MAC Address Security
Features
Table of Contents
Preventing MAC Address Frauds............................................................................................ 176
Static MAC Binding.................................................................................................................. 177
Static MAC Filtering................................................................................................................. 178
Check of the Number of the MAC Addresses......................................................................... 178
MAC Address Validity Check................................................................................................... 178
Access devices support multiple forwarding modes. When an access device works in VLAN
+MAC forwarding mode, messages are forwarded in accordance with a VLAN and MAC ad-
dress entries. A VLAN is manually configured and generated and cannot be modified by mali-
cious users. The MAC address entries of a device are generated from learning. Malicious users
often make use of the dynamic MAC address learning mechanism of an access device. They
counterfeit the legal users or source MAC addresses of network devices to attack the MAC ad-
dress entries of the devices and interfere normal network communication. MAC address securi-
ty problems include the following:
 Users' MAC addresses are counterfeited.
Malicious users access the network through counterfeit source MAC addresses of normal
users, use the network resources of these users, and cause the normal user network dis-
connected.
 MAC addresses of network devices are counterfeited.
Malicious users counterfeit the MAC address of an upper-layer device in the access network
and attempt to steal the communication data forwarded to the upper-layer device. The prin-
ciple is described as follow:
1. A malicious user sends a message, with the source MAC address being the MAC ad-
dress of the upper-layer device of the access network.
2. After receiving the counterfeit message from the malicious user, the access device re-
freshes the MAC address table in accordance with the dynamic MAC address learning
mechanism. In the system MAC address table, the MAC address of the upper-layer de-
vice is migrated from an uplink port to the port of the malicious user.
174 SJ-20230719162004-003 | 2023-10-30 (R1.0)

16 MAC Address Security Features
3. The access device forwards the messages sent by other users to the upper-layer device
to the port of the malicious user.
If layer-2 intercommunication is disabled, user ports are separated from each other at lay-
er 2. Therefore, layer-2 forwarding fails. Therefore, the messages sent by other users to the
upper-layer device are discarded. Thus communication is interrupted.
 The MAC address table is used up.
Malicious users counterfeit a large number of messages with different source MAC address-
es to attack an access device and interfere network communication. The principle is de-
scribed as follow:
1. A malicious user counterfeits a large number of messages with different source MAC ad-
dresses.
2. The access device learns a large number of rubbish entries from the messages sent by
the malicious user. Thus lots of MAC address table resources of the system are used.
3. After the MAC address table resources are used up, the access device cannot learn a
new MAC address. Thus normal communication messages of other users can only be
processed as unknown unicast messages.
4. The user messages are broadcast or discarded in accordance with the unknown unicast
forwarding policy.
If unknown unicast suppression is enabled on the device, the messages are discarded, and
some users cannot access the Internet. If unknown unicast suppression is disabled on the
device, the messages are broadcast. Thus too much bandwidth is used for forwarding mes-
sages and the communication quality is affected.
The access device provides multiple methods to resolve the MAC address security problems,
refer to Table 16-1.
Table 16-1 Methods of Resolving MAC Address Security Problems

Method Function Description
Preventing fraud MAC ad- Includes dynamic source MAC address binding and dynamic source MAC ad-
dresses dress filtering. An access device monitors the interaction procedure of DHCP and
DHCPv6 protocol messages, dynamically generates MAC address binding en-
tries and MAC address filtering entries, and filters messages with fraud MAC ad-
dresses from users in accordance with the entries. This method prevents users
from counterfeiting as the source MAC addresses of other users or upper-layer
devices.
Binding static source MAC By binding service flows to a user's static source MAC address, the user's MAC
addresses address cannot be counterfeited by other users and this user cannot counterfeit
the source MAC address of another user or an upper-layer device.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 175

Method Function Description
Filtering static source By manually setting source MAC address filtering for the MAC addresses of up-
MAC addresses per-layer devices in the access network, the MAC addresses of the upper-layer
devices cannot be used as the source MAC addresses of messages to be sent.
Thus attacks from malicious users by counterfeiting the MAC addresses of up-
per-layer devices are prevented.
Preventing MAC address Before the source MAC address of a port becomes aged, a device learns the
flapping source MAC address from another port and refreshes the relationship between
the source MAC address and the physical port in the MAC address table. This is
MAC address flapping. To prevent malicious users from making use of the MAC
address flapping principle to counterfeit the MAC address of another user or an
upper-layer device, the access device disables the MAC address flapping func-
tion.
16.1 Preventing MAC Address Frauds

An access device monitors the interaction procedure of PPPoE and DHCP protocol messages,
automatically saves the MAC address entries of users and servers, and forwards or discards
the messages received on user ports. Figure 16-1 shows the procedure of a DHCP user getting
online and offline.
Figure 16-1 Procedure of a DHCP User Getting Online and Offline
1. When user A gets online, the access device monitors the DHCP message interaction be-
tween user A and the DHCP server, and obtains the information about user A, including the
MAC address and IP lease. The access device adds a dynamic MAC address binding en-
try with an index 50, and records the information (for example, the VLAN, MAC address, and
Vport) of user A.
176 SJ-20230719162004-003 | 2023-10-30 (R1.0)

2. The access device learns the source MAC address (MAC S1) of the DHCP server from the
response message of the DHCP server, and adds the address to the MAC address filtering
entries.
3. After user A gets online, the access device checks the validity of the MAC address of the
data messages sent by user A in accordance with the dynamic MAC address binding en-
tries. Only data messages with MAC address MAC U1 can pass the check and the data
packets with other MAC addresses are discarded.
4. After detecting that user A is offline, the access device deletes the dynamic MAC address
binding entries of user A.
16.2 Static MAC Binding

By binding service flows to a user's static MAC address, the user's MAC address cannot be
counterfeited by other users and this user cannot counterfeit the source MAC address of anoth-
er user or an upper-layer device, see Figure 16-2.
Figure 16-2 Principle of Static MAC Binding
User A is located on port 0/2/1, with Vport 100. The device sets a static MAC address entry
(MAC U1) for user A, and sets the number of the dynamic MAC addresses that user A can
learn to 0.
1. The messages of user A with source MAC address MAC U1 can properly pass the device.
2. The messages of user A with a source MAC address other tha MAC U1 are discarded by
the device. Thus user A is prevented from counterfeiting the source MAC address of another
user or an upper-layer device. The principle involved is that after the number of the dynam-
ic MAC addresses that can be learned for a service flow is set to 0, the service flow cannot
learn any dynamic MAC address. Therefore, it forwards messages in accordance with the
static MAC address configured for the service flow. If a message sent by user A contains a
SJ-20230719162004-003 | 2023-10-30 (R1.0) 177

source MAC address (for example, the MAC address of an upper-layer device) other than
that configured for the service flow, the message is discarded by the device.
3. The messages of user B with source MAC address MAC U1 are discarded because MAC
U1 is the same as the static MAC address of user A. Thus the source MAC address of user
A cannot be counterfeited by other malicious users. The principle involved is that the static
MAC address has a higher priority than a dynamic MAC. If a port is configured with a static
MAC address, this address cannot be learned by other ports in the same VLAN as a dynam-
ic MAC address.
16.3 Static MAC Filtering

By manually adding a MAC address of an upper-layer device to the static MAC address filter-
ing entries of the access device, the MAC address of the upper-layer device cannot be used
by other users as the source MAC address of messages. Thus attacks from malicious users by
counterfeiting the MAC addresses of upper-layer devices are prevented. If a user's IP address
is manually and statically configured instead of being obtained dynamically, filtering of static
source MAC addresses is used to prevent counterfeit MAC addresses of network devices.
Basic principle of filtering MAC addresses: MAC address filtering entries are established on a
device, and all user messages with the MAC addresses in the entries are discarded. Filtering of
static source MAC addresses is to add the source MAC addresses of upper-layer devices to the
source MAC address filtering entries.
16.4 Check of the Number of the MAC Addresses

An access device checks the number of the MAC addresses before generating a new dynam-
ic MAC address binding entry, including the following: If either of the following requirements is
met, the new dial-up messages will be discarded.
 Whether the number of the MAC addresses bound to a service flow in the dynamic MAC ad-
dress binding entries has reached the maximum number allowed for the service flow.
 Whether the number of the bound MAC addresses in the dynamic MAC address binding en-
tries has reached the maximum number of the MAC addresses allowed for the system.
16.5 MAC Address Validity Check

When receiving a data message or a non-dial-up protocol message, a device checks whether
the MAC address of the message is the one that has been bound to the service flow in the dy-
namic MAC address binding entry. A message is valid only when its MAC address is the one
that has been bound to the service flow in the dynamic MAC address binding entry. Otherwise,
the device discards the message as a message with fraud MAC address, and reports the event.
178 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Figure 16-3 shows the principle of checking the validity of a MAC address.
Figure 16-3 Principle of MAC Address Validity Check
1. User A sends a dial-up protocol message with MAC address MAC U1.
2. The access device determines that the dial-up message of user A uses a nonconflicting
MAC address, adds a dynamic MAC address binding entry with index 50, and records the
information (for example, the VLAN, MAC address) of user A. User A normally gets online
after passing the authentication of the upper-layer server in the access network.
3. User A sends a data message with MAC address MAC U1.
4. The access device finds the MAC address that is equal to that of the data message in the
dynamic MAC address binding entries of user A, determines that the data message is valid,
and forwards the message to the upper-layer network.
5. User A sends a data message with a source MAC address other than MAC U1. The access
device does not find the same MAC address as that of the data message in the dynamic
MAC address binding entries of user A, determines that the data message has a fraud MAC
address. The access device discards the fraud message of user A and reports the event.
The device checks MAC address validity of every data message and processes protocol mes-
sages depending on the practical conditions.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 179

Chapter 17
Security Features
Table of Contents
RADIUS.................................................................................................................................... 180
TACACS+................................................................................................................................. 182
DHCP Snooping....................................................................................................................... 184
Port Identification......................................................................................................................187
17.1 RADIUS
RADIUS Overview
Remote Authentication Dial In User Service (RADIUS) is a protocol, which supports authenti-
cation, authorization, accounting and configuration information between network access device
and authentication server. RADIUS protocol has the most widely applications in authentication,
authorization and accounting. It has the following features,
 It uses client/server structure.
The OLT acts as the RADIUS client. The client is responsible for transmitting user informa-
tion to the specified RADIUS server, and processing the response coming from the RADIUS
server.
The RADIUS server is responsible for receiving connection requests coming from users, au-
thenticating the users, and sending the required necessary configuration information to the
client. The RADIUS server can act as agent client for other RADIUS server or other authen-
tication servers.
 It uses shared key to ensure network transmission safety.
The interaction between the client and the RADIUS server is authenticated by using the
shared key. The shared key is not transmitted in network. Additionally, to prevent user pass-
word from interception in unsafe network, the passwords transmitted between the client and
the RADIUS server are encrypted.
 Excellent expansibility
The RADIUS server supports multiple modes to authenticate users. The RADIUS supports
Password Authentication Protocol (PAP), or Challenge Handshake Authentication Protocol (
CHAP), UNIX login or other authentication modes.
180 SJ-20230719162004-003 | 2023-10-30 (R1.0)

17 Security Features
 It provides flexible authentication mechanism.

All interaction packets are formed by many Attribute-Length-Value triples with different
length. The adding of new attribute does not destroy the original function of protocol.
The RADIUS protocol is borne on User Datagram Protocol (UDP). The official port No.1812
is used for authentication and authorization, and No.1813 port is used for accounting.
RADIUS Network Structure
The RADIUS network structure consists of a remote client, OLT (the RADIUS client) and the
RADIUS server, see Figure 17-1.
 Remote client: The remote users who want to access local resource.
 OLT (the RADIUS client): It provides network services for remote users.
 RADIUS server: It has a database to maintain security data (such as user identifier informa-
tion, authorization information and access record).
Figure 17-1 RADIUS Network Structure
The remote user can either be a PC or a router. It accesses OLT (the RADIUS client) through
Telnet or SSH. The RADIUS client runs on OLT. It interacts with security server by using the
RADIUS protocol to implement the following functions:
 Identity authentication
It provides full identity authentication service by means of user name, password, and chal-
lenge response.
 Remote users send authentication and accounting requests to OLT (the RADIUS client)
(RADIUS client). The RADIUS client forms and sends authentication packets to RADIUS
server in accordance with the requirement of users. Moreover, it receives the responding
packets from RADIUS server, authenticates, and accounts remote users.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 181

17.2 TACACS+
TACACS+ Overview
Terminal Access Controller Access-Control System Plus (TACACS+) provides access control-
ling service for router, network access server and other network processing devices by one or
more central servers. The TACACS+ supports independent authentication, authorization and
accounting function.
The TACACS+ makes authentication, authorization and accounting as an independent part re-
spectively, and encrypts the data transmission between OLT (TACACS+ client) and the security
server. The TACACS+ permits the packets without fixed length, and it also permits the authen-
tication mechanism with any form to be applied to the TACACS+ client. The TACACS+ is able
to extend site customization and function adding. The packets transmission is ensured by using
TCP protocol in transmission layer. This protocol permits the TACACS+ client to request the ac-
curate access control, and it also permits the TACACS+ server to respond every request part.
The features of TACACS+ are as follows:
 The design basis of TACACS+ is the function separation of authentication, authorization and
accounting. The advantage of function separation between the authentication and authoriza-
tion is that authorization is a dynamic processing procedure, and users do not need to per-
form authorization after authenticating.
 The TACACS+ protocol is more flexible when it is used together with the Point-to-Point Pro-
tocol (PPP), and ARAP protocol.
 The TACACS+ accounting function can provide security auditing and service accounting
functions.
TACACS+ Networking Structure
The TACASC+ network includes a remote client, OLT (TACACS+ client), and TACACS+ server.
For the network structure, see Figure 17-2.
 Remote client: The remote users who want to access local resource.
 OLT (TACACS+ client): It provides network services for remote clients.
 The TACACS+ server: It has a database to maintain security data (such as user identifier in-
formation, authorization information and access record).
182 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Figure 17-2 TACACS+ Networking Structure
The remote user can either be a PC or a router. It accesses OLT (TACACS+ client) through
MODEM or ISDN by using PPP, SLIP or ARAP. The TACACS+ client runs on OLT. It interacts
with security server by using the TACACS+ protocol to finish the following functions:
 Identity authentication
It provides full identity authentication service by means of user name, password, challenge
response.
 Authorization
It provides authorization service during user session. For example, it permits user to use
some level of command only.
TACACS+ Packets Interaction
TACACS+ provides independent 3A support. Authentication, authorization, accounting are im-

plemented by independent servers. The data transmitted by TACACS+ between OLT (TACACS
+ client) and security server is encrypted.
Figure 17-3 shows the authentication, authorization and accounting process between the
TACACS+ client and the server.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 183

Figure 17-3 TACACS+ Packets Interaction
17.3 DHCP Snooping

DHCP Snooping
Dynamic Host Configuration Protocol (DHCP) is a Transfer Control Protocol/Internet Protocol (

TCP/IP) standard that simplifies the management of host IP address configuration. It provides
an effective method for DHCP server use, that is, it manages the dynamic assignment of IP ad-
dresses to clients on the network and other related configuration information of DHCP clients on
the network. After a DHCP server is installed and configured on the network, DHCP clients can
be used. DHCP clients can obtain the IP addresses related parameter values that are needed
to get online when the DHCP clients join the network. This reduces the configuration manage-
ment, and provides secure and reliable configuration.
However, with the wide applications of the DHCP service, some problems appear.
 Several DHCP servers are allowed on a subnet, which means that administrators cannot en-
sure that the IP addresses of clients are obtained from legal DHCP servers instead of illegal
servers created by some users privately.
184 SJ-20230719162004-003 | 2023-10-30 (R1.0)

 On a subnet where the DHCP service is enabled, a host specified with legal IP address,
mask and gateway can access the network properly. However, the DHCP server may still
assign the address to other hosts. This causes addresses conflict and affects IP address as-
signment.
The DHCP snooping inspection can solve the above problems.
The DHCP snooping is a technology used to snoop into the validity of DHCP packets.
DHCP Snooping Work Flow
R1 and R2 are two interconnected routers. The clients obtain IP addresses through the DHCP
server to get online. Based on the requirement, the ports on the routers connecting to the
clients are set to untrusted ports, and the port on the router connecting to the DHCP server is
set to trusted port, see Figure 17-4.
Figure 17-4 DHCP Snooping Typical Application
When a DHCP server and a client are not on the same subnet and the client wants to obtain an
IP address from the DHCP server, a DHCP relay agent must be used to forward DHCP request
packets. Before the DHCP relay agent forwards DHCP request from the client to the DHCP
server, it inserts some option information so that the DHCP server can know the client informa-
tion more correctly. In this way, the IP address and other parameter values can be assigned
more flexibly based on the related policy.
The option is named DHCP relay agent information option, and the option number is 82. There-
fore, it is also called Option82.
Note
Option82 is an extended application of DHCP options. It is only a type of application extensions. Whether
Option82 is contained does not affect the application of the DHCP. In addition, whether DHCP servers
support Option82 must be checked. If a DHCP server that does not support Option82 receives packets
containing Option82 information, or a DHCP server that supports Option82 receives packets not contain-
ing Option82 information, the basic DHCP service is not affected.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 185

To support the extended application of Option82, the DHCP server must support Option82 and
Option82 information must be inserted into the DHCP packets received. When a DHCP request
packet is received from an untrusted port, no matter whether the DHCP server and the client
are in the same subnet, the router on which DHCP snooping is enabled can select whether to
insert Option82 information. By default, the router inserts Option82 information to the DHCP re-
quest packet received on the untrusted port.
For the packet interaction procedure, see Figure 17-5.
Figure 17-5 DHCP Message Interaction
1. When a DHCP client begins DHCP initialization, it broadcasts a configuration request packet
on the local network.
2. If there is a DHCP server on the local network, DHCP configuration can be performed with-
out a DHCP relay.
3. If there is no DHCP server on the local network, when a network device with the DHCP re-
lay function connecting to the local network receives the broadcast packet, it processes the
packet and then forwards the packet to a DHCP server on other networks.
4. The DHCP server performs related configurations based on the information provided by the
DHCP client, and then sends the configuration information to the client through the DHCP
relay. Dynamic configuration of the DHCP client is completed.
In fact, from the beginning to the end, there are several interaction procedures similar to the
above procedure.
The DHCP relay modifies related fields in the DHCP packet to modify the DHCP broadcast
packet to a unicast packet. It is responsible for the conversion between the server and the
client.
186 SJ-20230719162004-003 | 2023-10-30 (R1.0)

17.4 Port Identification

Description
The number of VLANs is 4096 due the limitation of IEEE 802.1q. In an IP network, especially in
an access network, which requires the distinguishing of users and services, when VLANs are
used to identify user's physical locations, the limitation is obvious. PPPoE+(PPPoE intermediate
agent), DHCP option82, and DHCP option18 and option37, are introduced to solve the problem
of identifying user's physical locations and protect the interests of users and operators.
The port identification module adds and deletes port identification fields to the DHCP or PPPoE
messages. The uplink devices implement security control by identifying the information about
user's physical locations. An access layer device only adds or deletes the information about
physical location, does not maintain the corresponding relationship between port information
and user accounts.
PPPoE+
PPPoE+(PPPoE intermediate agent) is an evolution of PPPoE. PPPoE was first introduced by

the DSL Forum. Figure 17-6 shows the PPPoE+ interaction procedures.
Figure 17-6 PPPoE+ Interaction Procedures
 In the PPPoE Discovery stage, PADI and PADR messages send user's circuit ID ( Agent
Circuit ID and Agent Remote ID) to the BAS device through extended Tag 0x0105.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 187

 The BAS device maintains the corresponding relationship between the user's physical lo-
cation and user's Session ID. In the LCP authentication stage, the user's physical location,
as the NAS-Port (5) and NAS-Port-Id (87) authentication attributes, are sent to the RADIUS
Server with the username and password for authentication.
 The user circuit ID, including Agent Circuit ID and Agent Remote ID should be completely
forwarded during the interaction.）
Figure 17-7 shows the PPPoE+ option format.
Figure 17-7 PPPoE+ Option Format
DHCP Option82
DHCP Relay Agent Information Option in RFC 3046 mentions the application of Option 82.
DHCP Relay Agent insert the Option 82 to the user's DHCP messages, The DHCP server car-
ries out the IP address allocation policy or other policies according to Option 82. The response
messages from the DHCP server carries Option 82 as well. The DHCP relay agent removes
Option 82 before sending them to the users.
Figure 17-8 shows the brief interaction procedures of DHCP Option 82.
188 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Figure 17-8 DHCP Option 82 Interaction Procedures
Figure 17-9 shows the DHCP option 82 format.
Figure 17-9 DHCP Option 82 Format
Agent Information Field contains multiple sub-options. The format of each sub-option is SubOpt/
Length/Value, as shown in Figure 17-10.
Figure 17-10 DHCP Option 82 Sub-Options Format
At present, two sub-options are used for port identification:

 Agent Circuit ID Sub-option
 Agent Remote ID Sub-option
DHCP Option18, Option37
DHCPv6 Relay Agent inserts the Option18 (circuit ID) and Option37 (Remote ID) to user's
DHCP messages such as DHCP SOLICIT, DHCP REQUEST. The DHCPv6server carries out
the IP address allocation policy or other policies according to Options. The response messages
SJ-20230719162004-003 | 2023-10-30 (R1.0) 189

from the DHCPv6 server carries Options as well. The DHCPv6 relay agent removes Option18
and Option37 before sending them to the users.
190 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Chapter 18
Networking Protection
Features
Table of Contents
LACP.........................................................................................................................................191
BFD...........................................................................................................................................192
FRR Configuration....................................................................................................................195
OAM Binding............................................................................................................................ 199
18.1 LACP
Overview
Link aggregation is to aggregate multiple ports to an aggregation group, to implement load bal-
ance of traffics among group members. An aggregation group works as a port. The upper layer
entity takes the multiple physical links in an aggregation as a logic link. Link aggregation is im-
plemented on data link layer.
The advantages of link aggregation are as follows:
 Increase bandwidth: the bandwidth of the aggregated logic port is the sum of bandwidth of
all physical port in the group.
 Enhance the reliability of network connection.
Link Aggregation Types
There are two types of link aggregation.

 Static trunk
In static trunk, multiple physical ports are added to a trunk group to form a logic port. In a
static trunks, port status cannot be easily observed.
 Dynamic LACP
LACP complies with the IEEE 802.3ad standard. The LACP protocol dynamically aggre-
gates multiple physical ports to a trunk group to form a logic port and acquire maximum
bandwidth.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 191

LACP
The IEEE 802.3ad based LACP is a protocol implementing dynamic link aggregation. LACP
uses LACPDU (Link Aggregation Control Protocol Data Unit) to exchange information with the
peer.
When LACP is enable on a port, the port sends LACPDU to the peer to advertise the system
priority, system MAC address, port priority, port number and operation key. When the peer port
receives these information, the port compares these information with the information saved
on the other ports to select ports for aggregation, so that ends can agree that whether a port
should join or exit the aggregation group.
Product Featuers
The OLT supports maximum 80 aggregation groups.

 Supports aggregation groups in static mode or 802.3ad mode. The default mode is static
mode.
 Supports load balance for link aggregations. The load balance modes includes: dst-ip, dst-
mac, src-ip, src-mac, src-dst-ip, and src-dst-mac.
18.2 BFD
18.2.1 BFD Overview

Overview
For network devices, an important feature is to detect the communication failures between adja-
cent systems rapidly. This way, when failures occur, the devices can establish alternative paths
or hand over services to other links more quickly.
The BFD provides a solution to the above problem. The BFD protocol can detect failures on any
types of paths between adjacent systems, including direct-connected physical link, virtual cir-
cuit, tunnel, MPLS LSP, multi-hop routing channel, and indirect-connected tunnel. Because of
its simplicity and unitary, BFD can focus on fast detection of forwarding failures. It helps net-
works to implement transmission of voice, video, and other services with good Quality of Ser-
vice (QoS), thus helps service providers to provide real-time services (such as Voice over Inter-
net Protocol (VoIP) on the basis of IP network.
BFD Features
The BFD is a simple Hello protocol. It is similar to the Hello mechanisms of routing protocols.
The BFD is simpler and universal. The two systems that establish a BFD session send packets
to each other periodically. If one system does not receive any packet from the peer in a specif-
192 SJ-20230719162004-003 | 2023-10-30 (R1.0)

18 Networking Protection Features
ic period, it considers that there is a failure on the communication path. The BFD session will
be down, and the BFD will inform the upper-layer protocol to select another path. To reduce the
loads of devices, some special application modes are designed in the BFD. In these modes, de-
vices can reduce the number of BFD packets sent to the peers; or it is unnecessary for the de-
vices to send BFD packets periodically. The devices can send the packets only when it is nec-
essary.
The BFD protocol aims at fast failure detection (including failures on interfaces, data links, and
even forwarding engines) on a bidirectional tunnel between forwarding engines. Another aim
is to provide a single detection mechanism that can be applied to any type of medium and any
protocol layer. BFD detects failures in the forwarding engines between a device and the next
hop. It is likely to work in some parts of a system forwarding engine. The forwarding engine and
the control engine are isolated. This not only binds the protocol to the forwarding plane, but also
isolates the protocol from the routing protocol engine (control plane). Therefore, BFD can take
effect in non-interrupt forwarding and run in the control engine.
The BFD provides failure detection between systems, including directly connected physical
links, virtual links, tunnels, MPLS LSPs, and multi-hop routing paths.
BFD Creation Modes
On the ZXA10 C600/C650/C620, BFD can be created in one of the following modes:
 Static BFD establishment: Establish a BFD session through configuring related protocol pa-
rameters by using instantiation commands.
 Dynamic BFD establishment: Establish a BFD session (triggered by the protocol) in conjunc-
tion with the BFD enabling command in the route protocol/MPLS protocol mode.
18.2.2 BFD Application
18.2.2.1 Static BFD Expansion

The common static BFD function is used to detect LDP-based LSPs and static tunnels, and
LSP ping must be used as the triggering mechanism of BFD sessions. It is only necessary to
create BFD sessions at the ingress of tunnels or LSPs.
Static BFD has the following disadvantages:
 Bidirectional LSP detection is not supported.
 The reversal path is not supported.
 The static tunnel or LSP scenario where IP routes are not available is not supported.
However, the LSP ping function can be expanded and static sessions can be configured on
both ends to solve the above problems. The function of the head node pointing to the reversal
path can be achieved by expanding the LSP ping function and adding private TLVs. Static ses-
SJ-20230719162004-003 | 2023-10-30 (R1.0) 193

sions are configured on both ends to support specifying path modes and LD/RD attributes in
sessions.
During the pure expanding of private TLVs in the LSP ping function, the incompatibility between
different vendors and devices related to the function may be encountered. Therefore, the device
must support the configurations of static LSP BFD on both ends. In the reversal direction of a
BFD session, a parameter (IP address, LSP path, or tunnel) can be specified. At the same time,
the LD/RD attributes of the static BFD session can be manually specified.
During the implementation, the command for adding static BFD sessions must be added. The
path type (IP, LSP, or tunnel) can be specified for both ends, and the LD/RD/Tx/Rx/Multiper at-
tributes of sessions can also be specified.
18.2.2.2 BFD Triggering the Fast ECMP Switchover

ECMP is a technology that allows multiple links to share traffic to the same destination address.
If a link is faulty, a proper path can be obtained only after a protocol convergence period. Dur-
ing the period, traffic is still forwarded over the original link, thus causing packet loss. In the
case of a network fault, the service convergence speed is very important for carriers. The ser-
vice switchover time between adjacent nodes (smaller than 50 ms) and end-to-end service con-
vergence time (smaller than 1 second) in the case of a node fault have gradually become the
threshold-level indicators of the bearer network. Performance requirements are difficult to be
met if only protocol convergence is applied. Therefore, the BFD function should concern the
ECMP link status and support fast switchover.
In the ECMP configuration, it is necessary to add peer addresses as BFD detection objects. If
a link is faulty, the BFD-enabled device performs a fast switchover in accordance with the peer
address to reduce the number of lost packets.
In the scenario shown in Figure 18-1, CE1 belongs to PE1 and PE2, and two ECMPs are
formed from PE3 to CE1: PE3-PE1-CE1 and PE3-PE2-CE. The ECMP configuration stores the
peer addresses of PE1 and PE2 (100.1.1.1 and 200.1.1.1). If PE2 is faulty, the BFD-enabled
device discovers the fault, switches over traffic to the PE3-PE1-CE1 link, and informs the proto-
col to re-calculate a route. After the protocol is re-converged, there is only one link (PE3-PE1-
CE1) from PE3 to CE1, and ECMP routes change to a single route. In this way, network con-
vergence performance is improved.
194 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Figure 18-1 Scenario Where BFD Triggers a Fast ECMP Switchover
18.3 FRR Configuration
18.3.1 IP FRR
18.3.1.1 IP FRR Overview
Overview
When a link or a node in the network becomes invalid, the packet passing through the invalid
nodes to the destination may be dropped or cause loops. Therefore, transient flow interruption
or traffic loopback is inevitable in network until the network calculates out the new topology and
routes. The interruption duration is about a few seconds. At present, some new technologies in
the router field can shorten the convergence time within one second.
With the development of Internet technologies and applications of different complicated ser-
vices, some applications (such as voice and video) are extremely sensitive to traffic interruption.
Once the network is not steady, there will be serious effect to those services. When a node be-
comes invalid, the rapid recovery of traffic is very important. At present, the communication in-
dustry considers that the network convergence period has three levels, including:
 Sub-Second: It is the requirement of most IP networks.
 Sub-500 ms: It is an objective that can be reached.
 Sub-50 ms: This is a business requirement for some specified parts in the IP network.
Convergence Time and Traffic Loss
The following aspects normally take the convergence time:

1. The time that is used to discover invalid nodes and links. The detection time is tens of mil-
liseconds for an invalid physical link. The detection time is dozens of seconds for invalida-
tions in protocol plane.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 195

2. The time that is used to notice the invalid event to the control plane of a router. It costs sev-
eral milliseconds to tens of milliseconds.
3. The time that is used to take the corresponding responses to the invalid node and link. The
response includes triggering and flooding the new link state, and updating packets. Normally
it is several milliseconds to tens of milliseconds.
4. The time that is used to notice other nodes in network that the local router link is invalid.
Normally it is tens of milliseconds to a hundred seconds normally on each node.
5. The time that is used to recalculate the triggering route. For Interior Gateway Protocol (IGP)
protocols that use the Dijkstra algorithm, the time is tens of milliseconds.
6. The time that is used to interact with line interface cards to calculate the new routing infor-
mation and form the new forwarding table. The time varies in accordance with the number of
routing entries. Normally it is several hundred milliseconds.
7. The time that is used to load the new forwarding route entries into hardware. Normally it is
tens of milliseconds.
The traffic loss may occur in the above mentioned steps. The traffic loss can be divided into two
stages, including:
1. Stage 1: The router fails to discover the invalid link immediately, and it still forwards the traf-
fic to the invalid link.
2. Stage 2: The route discovers the invalid link, but the network is in convergence process. The
local forwarding table is different with that of other routers, which causes "micro-loop" in for-
warding plane.
To shorten the traffic interruption duration, a mechanism must be provided to implement the fol-
lowing functions:
1. Discover the invalid link quickly.
2. When the link is invalid, provide a recovery path quickly.
3. Prevent forwarding "micro-loop" during the further recovery process.
This mechanism is the IP Fast-Reroute (This mechanism is the IP Fast-Reroute (
18.3.1.2 Nested FRR

At present, FRR is classified into IP FRR, LDP FRR, TE FRR, VPN FRR, and PWE3 FRR. In
a reliable networking environment, one or more FRR technologies are deployed as required to
improve the reliability of the network.
As shown in Figure 18-2, IP FRR is formed among PE1, PE2, and PE3, and TE FRR is formed
between PE1 and PE2.
196 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Figure 18-2 VPWS/PWE3 FRR + TE/LDP FRR Application Scenario
18.3.1.3 IP FRR Supporting WTR

As shown in Figure 18-3, FRR routes are configured on R1: The primary path is R1→R2→R4,
and the secondary path is R1→R3→R4.
The WTR function is applied to the following scenario: After the R1→R2 and R2→R4 paths are
invalid, if the R1→R2 path in network 1 is restored and the R2→R4 path in network 2 is not re-
stored, the WTR function is configured on R1 to prevent FRR from rapidly switching over traffic
to the primary path, so that packet loss can be avoided.
Figure 18-3 Scenario Where IP FRR Supports WTR
18.3.1.4 Direct Routes Supporting IP FRR Protection

As shown in Figure 18-4, in the application scenario where a CE belongs to dual PEs, BGP re-
lationships are established between PE1 and PE3 and between PE2 and PE3. If the active PE
is faulty, traffic is switched over to the standby PE.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 197

Figure 18-4 Scenario Where a CE Belongs to Dual PEs
In the scenario shown in Figure 18-4, the traffic path is PE3→PE1→CE. If PE1 or the link be-
tween PE1 and PE3 is faulty, the FRR protection function between PEs can be used to switch
over traffic to the PE3→PE2→CE1 path. However, when the CE1→PE1 link is faulty, PE1 can-
not forward the instantaneous traffic that is received from PE3 due to no FRR protection mech-
anism, and therefore the traffic is discarded. In this case, after PE1 advertises the fault informa-
tion about the link between PE1 and CE to PE3, traffic can be switched over to the PE3→PE2
→CE path. However, in this mode, the switchover time is too long, and is not helpful for network
recovery. Therefore, PE1 must be configured with the IP FRR protection function that supports
direct routes to enhance the convergence speed.
18.3.2 Static Route FRR

Overview
After one or more links or nodes are faulty, the packets passing the nodes may be discarded or
a loopback phenomenon may occur. This may inevitably cause transient traffic interruption or a
loopback phenomenon and can be eliminated only until the network is re-converged to calculate
a new topology or route.
With the expansion of the network scale and endless emergence of new applications, some ap-
plications (such as voice and video) are very sensitive to traffic interruption. If some nodes are
invalid, rapid traffic recovery is of great importance.
Therefore, a mechanism must be provided to implement the following functions:
 Rapid discovery of faulty links.
 An alternative path is rapidly provided when a link is faulty.
 During the subsequent network recovery process, the possibility of micro-loop in traffic for-
warding is eliminated.
The IP FRR technology can be used to solve the above problems.
Static route FRR means that the IP FRR technology is used in the static route. The user can
configure the relationship between the active route and the standby route in the static route.
198 SJ-20230719162004-003 | 2023-10-30 (R1.0)

When the link or node in the network becomes invalid, the traffic will be handed over to the
standby route quickly. After the network is restored, the traffic will be handed over to the active
route again.
Work Follow
The operation process of static route FRR is as follows:

1. Detect the fault quickly. The common technology includes BFD and physical signal detec-
tion.
2. Modify the forwarding plane and hand over the traffic to the prepared backup path.
3. Converge the route again.
4. After the route convergence, the traffic will be handed over to the optimization path.
The backup path is to fill the route convergence gap. It ensures the continuity of the service by
switching the traffic to the backup path quickly.
The static route cannot calculate the route and converge the route again, so the user needs to
specify routes to form the relationship between the active route and the backup route. That is to
say, configure two static routes with the same destination address, different egress interfaces
and different priorities.
18.4 OAM Binding

For some network applications, users cannot deploy end-to-end PWs or tunnels. As a result,
the service protection is complicated, especially in a multi-point fault scenario, and services
may be interrupted. In a typical bridging network solution, the access layer, convergence layer,
and core layer respectively use their network protection measures. However, there is no map-
ping mechanism among these layers, which may result in service interruption in case of a mul-
ti-point fault.
Figure 18-5 shows a bridging network. The access layer uses the "PW-FRR + VRRP" protec-
tion, the convergence layer uses the "Hot-Standby + VPN-FRR" or "static end-to-end tunnel +
VPN-FRR" protection, and the core layer uses the "dynamic VRRP + active/standby" protection.
If a multi-point fault occurs, for example, 1 and 2, 2 and 3, 3 and 4, or 4 and 5, the end-to-end
service is interrupted.
A multi-point fault may result in end-to-end service interruption, because the access layer, con-
vergence layer, and core layer only provide protection on the local layers, and cannot detect
faults of other layers. As a result, a normal layer sends data through original routes, and a faulty
layer cannot transfer service traffic because of the multi-point fault.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 199

Figure 18-5 Multi-Point Fault Network Solution
The OAM mapping and linkage between different layers can solve the above problem. For the
principle, see Figure 18-6.
200 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Figure 18-6 OAM Mapping and Linkage Principle
When R1 detects that faults 1 and 2 occur simultaneously, R1 notifies R2 about the faults
through the application fault OAM binding function, and then R2 performs the protection switch-
ing.
The association can be implemented through detection groups. The association can be used to
shut down a port or prevent the port from transferring messages (excluding OAM messages).
 Method 1: Associated physical and logical ports are shut down.
 Method 2: If the SF flag is configured at a logical interface, only OAM messages can be
transferred.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 201

Chapter 19
NETCONF Feature
Description
NETCONF (Network Configuration Protocol) is a user-oriented network management protocol

based on XML technology. NETCONF provides mechanism to install, operate, and delete net-
work device configurations. NETCONF uses XML to identify configuration data and protocol
messages, and uses simple mechanism based on RPC (Remote Procedure Call) to implement
the communication between servers and clients. NETCONF adopts hierarchical structure, each
layer capsulate an aspect of protocols, and provides service to the upper layer. The hierarchi-
cal structure allows each layer to concern only one aspect of protocols, which is easy to imple-
ment. The dependence between each layer is decoupled, and the effect on other layer due to
the modification of each layer's internal implementation can be minimized.
Figure 19-1 shows the NETCONF protocol layers.
Figure 19-1 NETCONF Protocol Layers
 Secure Transport layer provides a secure and reliable transport of messages between a
client and a server. The supporting of SSH is required.
 Messages layer provides a mechanism for encoding RPCs and notifications.
 Operations layer defines a set of base protocol operations to retrieve and edit the configura-
tion data.
202 SJ-20230719162004-003 | 2023-10-30 (R1.0)

19 NETCONF Feature
 Operations layer defines a set of base protocol operations to retrieve and edit the configura-
tion data.
 Content layer consists of configuration data and notification data.
Principle
NETCONF provides a standard frame and an assembly of standard RPC methods. Operaters
and application developer can operate network device configurations according to the frame
and assembly. Network device configurations and NETCONF protocol use XML format. All
NETCONF messages use XML format in XML Namespaces.
Figure 19-2 NETCONF Principle
NETCONF adopts Manager/Agent structure. The Manager initiate session link to the Agent
through a transport layer. When the link setup/authentication on transport layer is finished, the
Manager and Agent send Hello messages to each other to advertise its capability. When receiv-
ing Hello messages, both parties exchange their capability, and then establish NETCONF ses-
sion. When the session is established, the Manager uses protocol operation to send configura-
tion to the Agent or get information from the Agent.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 203

Chapter 20
ISSU Feature
Description
The in-service software upgrade (ISSU) feature enables you to upgrade OLT with almost ze-
ro interrupting the underlying device's operations, just like packet forwarding, which increases
OLT's network availability and reduces interruption time caused by software upgrades. ISSU
takes advantage of the redundancy provided by dual switch and control card within OLT's core
architecture and works in conjunction with the non-stop routing feature.
Figure 20-1 shows the he forwarding and control plane architecture of OLT.
Figure 20-1 OLT Forwarding and Control Plane Architecture
Each card (PON card/uplink card/switch and control card) has dedicated CPU system. run the
whole control plane software system.
The xPON MAC and NP (network processor) in PON card is forwarding plane components,
Switch Fabric is forwarding components in the switch and control card, The ETH MAC and NP
are the forwarding plane components.
When the software is upgraded, the CPU will reset to load the new software and the forwarding
components will not reset, the forwarding plane will keep forwarding, after the new control plane
software completed its own initialization and finish building the forwarding table shadow in the
control plane, the control plane will retrieve the forwarding tables from the forwarding planes,
204 SJ-20230719162004-003 | 2023-10-30 (R1.0)

20 ISSU Feature
compares them with the forwarding table shadow, only the difference will be wrote into the for-
warding components
 Scenario 1:
The new software version only change control planes features, In this condition ,the CPU
will reset to load the new software and the forwarding components will not reset and there
are no difference between forwarding tables in the forwarding plane and the tables shadow
in the software so the services will not interrupted.
 Scenario 2:
Both the functions of control plane and forwarding plane change in the new software .
In this condition , because the there are difference between the forwarding tables int the for-
warding plane and the tables shadow in the control plane, so rewrriting the forwarding tables
will interrupted some kinds of service in 30 seconds the service interrupt time depends on
the concrete difference
Principle
Figure 20-2 shows the control card ISSU mechanism.
Figure 20-2 ISSU Mechanism—Control Card
Initial Status: Check the compatibility of the ISSU version, upgrade the standby control card to a
new version, the version of the former active control card does not need to be changed.
Step 1: The active and standby control switchover. The standby control card with the new ver-
sion becomes the active control card
Step 2,3: The service processing card is interactive with the active control card with new ver-
sion, the line card sets up quickly and completes the upgrade.
Step 4: The standby control card upgrades to the new version.
Figure 20-3 shows the line card ISSU mechanism.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 205

Figure 20-3 ISSU Mechanism—Line Card
When the software of the control plane and the forwarding plane changes, only the CPU needs
to reset. After the line card reboots, the control card synchronizes all the configurations with the
line card: The forwarding configuration will be downloaded to PP at the same time and reduce
the interruption time. The configuration of PON MAC will be retrieved and handled by the soft-
ware, and then download to PON MAC again. The alarm info and configuration of ONU will be
retrieved and stored into the OLT line card.
206 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Chapter 21
Energy-Saving Features
Principle
The principle of the OLT energy-saving technique is as follows: the system automatically de-
tect operation status or service load of functional modules, including interfaces, cards, and fans.
When a module in idle or in low-load mode, the module is shutdown or is into low power con-
sumption mode, to reduce the overall power consumption of the system.
Interface Automatic Shutdown
 Automatic shutdown of high speed interfaces

The OLT detect the status of high speed interfaces. When the OLT detects that a high
speed interface is idle, the OLT shuts down the interface to save energy. The interface auto-
matically recovers from shutdown status when it is to be used.
à When the OLT detects that there is no traffic on a service card, the OLT shuts down the
high speed interface connected to the service card to reduce the power consumption of
the switching and control card.
à When the OLT detects that a PON interface has no optical module, the OLT automatical-
ly shuts down the interface circuit.
 Automatic shutdown of idle interfaces
The OLT detect the status of PON interfaces. When the OLT detects that a PON interface is
idle, the OLT shuts down the interface circuit and its optical module to save energy. The in-
terface automatically recovers from shutdown status when it is to be used.
Card Automatic Shutdown
The OLT detect the status of interface cards. When the OLT detects that an interface card is
unconfigured or type-mismatched, the OLT shuts off the power of the interface card, so that the
idle card consumes no power. The interface card automatically recovers from power-off status
when it is to be used.
All cards of the OLT supports electromechanical management. When a card is installed on the
shelf, the proper status is "INSERVICE". If no services are configured on the card, operators
can shut off the power of the card by CLI commands to save energy. If the card type is incon-
SJ-20230719162004-003 | 2023-10-30 (R1.0) 207

sistent with the configured card type, the OLT will recognized the mismatch and shuts off the
power of the card.
Fan Speed Automatic Adjustment
The OLT supports the following policies for fan speed adjustment.
 Temperature-controlled speed adjustment: automatically adjusts the fan rotation speed ac-
cording to ambient temperature of the shelf.
 PID speed adjustment: automatically adjusts the fan rotation speed according to card
firmware temperature.
Manual speed adjustment: configures the fan rotation speed manually.
208 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Chapter 22
High Availability Features
Table of Contents
Watchdog Monitoring Mechanism............................................................................................ 209
System Exception Monitoring and Log Record........................................................................211
System Resource Monitoring................................................................................................... 212
Internal Communication Verification.........................................................................................214
Dual BOOT, Roll-back from Upgrade Failure and NSR...........................................................216
IP Graceful Restart...................................................................................................................217
NSR.......................................................................................................................................... 219
Master/Slave Main Control Handover...................................................................................... 221
22.1 Watchdog Monitoring Mechanism

Both the main control boards and service cards of ZXA10 C6XX support watchdog monitoring
mechanism:
 Watchdog monitoring for Linux Kernel boot
The main control board and line card of the C6XX support 1 minute timing watchdog in or-
der to monitor Linux Kernel start-up procedure. The board will re-start if the Kernel does not
start successful.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 209

Figure 22-1 Watchdog Monitoring for Linux Kernel Boot
 Watchdog detection for kernel running

The kernel supports system running watchdog function, if the kernel hangs while software
running, the system running watchdog works and the board will be restarted.
Figure 22-2 Watchdog Detection For Kernel Running
 Watchdog detection for administration process
210 SJ-20230719162004-003 | 2023-10-30 (R1.0)

22 High Availability Features
The first process of the kernel is administration process, which trigger the watchdog while
running, if the administration process does not feed the dog during the period of the watch-
dog time, the board will be restarted.
 Watchdog detection for multi-core running
The NXP T2080 (4 dual-threaded cores) is adopted by main control board and switch board,
and the NXP T1020 (dual core) is adopted by line card, management process starts an
watchdog for each core, if there is no feeding during a period of watchdog time, the board
will be restarted.
22.2 System Exception Monitoring and Log Record

 Record for exceptional log
ZXA10 C6XX supports exceptional log and record its information, such like type, vector,
function call stacks, register of the processor, message of the function, related code seg-
ment and dll information of the process.
The record of the main control board will be stored in “/sysdisk0/run_log/Exc_Omp.txt”, and
the record of line card will be stored in “/sysdisk0/run_log/Exc_pp.txt”.
 Endless-loop detection
ZXA10 C6XX supports endless-loop detection. If a process is always on running status, the
state is called exception states while the process running time is more than configured time
and the exception recorded.
 Deadlock detection
ZXA10 C6XX supports deadlock detection. If a process is blocked while dealing with the
message, when the time of this status is more than configured deadlock time will be record-
ed.
 Process abnormal suspension detection
ZXA10 C6XX supports process abnormal suspension detection, the exception log will be
recorded while the process abnormal suspension detected.
 Process exception exit detection
ZXA10 C6XX supports process exception exit detection, which can detect if the process run-
ning or not, and record the exception log while the process no running.
 Key process detection
ZXA10 C6XX supports key process detection. If a key process does not run in a long time
period, and the time is more than the configured time, the exception log will be recorded.
 Memory waterline control
ZXA10 C6XX supports memory waterline control:
Linux kernel uses three level threshold to manage the RAM: min, low and high. There is no
control in kernel while the free RAM more than “high level”; The kernel will reclaim the mem-
SJ-20230719162004-003 | 2023-10-30 (R1.0) 211

ory until free RAM higher than “high level” while free RAM lower than “low level”; The kernel
will push SIGURG signal and record the exception log while free RAM lower than “min level”
, then restart the board.
The OLT also can support process threshold control, when the RAM used by a process
higher than configured threshold level, the RAM can not be allotted to other new non-key
process and the non-key process will be recorded and restarted. But if the RAM applied by a
key process, the board will be restarted.
22.3 System Resource Monitoring

 CPU utilization monitoring
The main control board and line card of the C6XX can support CPU utilization monitoring
alarm, if the utilization the CPU is more than a threshold value which can be configured, the
utilization alarm will be reported.
 Memory utilization monitoring
The main control board and line card of the C6XX can support RAM utilization monitoring
alarm, if the utilization the RAM is more than a threshold value which can be configured, the
utilization alarm will be reported.
 Temperature monitoring
There is a temperature sensor on each fan card of the C6XX, when system powers on, fan
card will adjust the fan speed depend on the temperature of the fan card until the fan speed
is configured by main control board.
There are temperature sensors on the main control board of the OLT, which the temperature
of the main control board will be environment temperature. When system running, the fan
speed will be adjusted according to the temperature read through the line card temperature
sensors and the main control board temperature sensors.
ZXA10 C6XX also supports environment over-temperature alarm, the fans forcibly operate
at the highest speed to protect the product while the environment temperature higher than
the configured threshold value.
The CPU and Switch chipset of the main control card, the CPU and NP of the line card,
which can support temperature read, each chipset can support four temperature alarms:
à Minor (long time working highest temperature)
à Major (short time working highest temperature)
à Fatal (highest temperature)
à Board off down temperature
The chipset temperature is read by main control board periodically. When the temperature
of a chipset is higher than major threshold value, the fans operates at the highest speed to
212 SJ-20230719162004-003 | 2023-10-30 (R1.0)

protect chipset. The board will be restarted when the temperature of the chipset is higher
than the power down temperature threshold, and alarm reported.
Figure 22-3 Temperature Monitoring
 Fan card monitoring

 ZXA10 C6XX supports card offline alarm (fan card plug out or offline), fan speed abnormal
alarm (while fan speed more or less than the 15% of configured speed ), fan speed status
abnormal alarm( while fan speed lower than the lowest speed)
SJ-20230719162004-003 | 2023-10-30 (R1.0) 213

 Power monitoring
ZXA10 C6XX supports power card offline alarm and power down alarm, low-voltage and
over-voltage alarm
 Card offline monitoring
ZXA10 C6XX supports slave main control card offline alarm and line card offline alarm.
 Other system monitoring items
ZXA10 C6XX also supports the monitoring of the following items:
à Uplink port
à Transceiver module
22.4 Internal Communication Verification

There are heartbeat detection through ZXA10 C6XX main control board and line cards, if the
main control board cannot get the heartbeat message in a period time, there will be a line-card
offline alarm
Heartbeat detection for board management
1. Add board through command line interface, the board states displays as offline;
2. After the board plug in, board will shows as online state through board-scan detection, the
board states displays as “hwonline”.
3. The configuration request will be sent to main control board after the line card software run-
ning, then, the main control board will response “ACK” message, which carry configuration
type.
4. The configuration type will be compared with the line card real type, and sent heartbeat
message to main control board (two-second interval).
5. The heartbeat message contains the line card status, if the state is configing (match), the
main control board will configure the line card, if the state is “typemismatch” (unmatched),
the main control board will do not configure the line card.
6. The line card will display as “inservice” state after the main control board configuring the line
card.
7. If the heartbeat message lose 5 times (10 seconds), the line card will be configured as “
hwonline” state again by main control board, and will be restarted. When the line card starts
up, this online flow will be triggered again.
214 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Figure 22-4 Heartbeat Detection for Board Management
Heartbeat detection for application process
The first process started in main control board and line card of ZXA10 C6XX is called manage-
ment process, all other application process will be created and managed by this management
process, each application process deals with a special service and function.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 215

The heartbeat message will be sent through management process and each application
process, if the heartbeat message lose a given times, the management process will reset the
application process.
22.5 Dual BOOT, Roll-back from Upgrade Failure and NSR

 Dual boot
The main control board and line card of the ZXA10 C6XX support dual boot, when an ex-
ceptional event happens, such like reboot or power down while updating, which result in a
updating failure, the boot will roll back to the old boot.
Figure 22-5 Dual Boot
 Roll-back from upgrading failure

The proposed product OLT supports roll back function while software updating failure, if the
failure happens while the software updating, the software will roll back to the old version.
216 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Figure 22-6 Roll-Back From Upgrading Failure
 NSR
The proposed product OLT supports NSR, which can achieve zero interruption while mas-
ter-slave switch
NSR(Non-Stop Routing) is a high HA technology, which can achieve control plane and for-
warding plane zero interruption and protection, which also means that, the end users will do
not get any sense when master board switch to the slave board.
22.6 IP Graceful Restart

Overview
In many situations, occasional interruption of a router is unpredictable, which may cause the in-
terruption of the forwarding data flow and the route oscillation. If the control function of a router
can be separated from the forwarding function, a certain policy can be used to reduce the im-
pact on the restarted router and its neighbors caused by an interruption event to the minimum
extent. The type of the policy is Graceful Restart (GR).
SJ-20230719162004-003 | 2023-10-30 (R1.0) 217

This chapter describes the applications of IP GR in the following fields.

 Applying IP GR in OSPF
 Applying IP GR in IS-IS
 Applying IP GR in BGP
OSPF/IS-IS GR
This policy is:

1. Other routers on the network keep their link states during the IS-IS/OSPF restart period.
2. The restarted router keeps its forwarding information before the restart in a short period, that
is, the FIB can keep steady on the restarted router in a short period, thus not affecting the
forwarding of the data flow.
3. After the router is restarted, the router finishes the LSP/Link State Advertisement (LSA) syn-
chronization with its neighbor routers quickly.
4. The router calculates Shortest Path First (SPF) after the LSP/LSA database synchroniza-
tion.
With this policy, the restarted router still can forward data during the restart period, and the
neighbor routers still can operate properly during the restart period. The restart will not cause
any route oscillation.
BGP GR
At present, the routing protocols only run on the Management Process Units (MPUs) of a
router. The routing protocols do not run on a standby board. After active/standby changeover,
the routing protocols run on the standby board.
To support the GR capability, the route protocol needs to accomplish the following tasks.
 Prevent the neighbor relationship between the neighbor routers and the restarted router
from being oscillated during the restart period.
 After the restart, the restarted router synchronizes the routing information with its neighbor
routers as soon as possible, and then updates the local routing information.
The BGP GR principle on a GR router and a helper router is described as follows:
 GR Router
1. When initiating to establish the BGP neighbor relationship, R1 and R2 negotiate the GR
capability through OPEN messages.
2. When the R1 is restarted, routes are kept on the interface cards for forwarding data.
3. The R1 establishes a new Transfer Control Protocol (TCP) connection with the neighbor
R2. In the BGP OPEN message, When the Restart state field in the BGP OPEN mes-
sage is set to 1, it indicates that the router is restarted just now. At the same time, the
router advertises the value of restart time to neighbors (this value should be less than the
218 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Holdtime value in the OPEN message). In addition, the router also needs to inform the
neighbors of the supported address family route GR.
4. After establishing BGP neighbor relationship with R2 successfully, R1 receives and
processes the route updates from the neighbor and starts the Wait-For-EOR timer.
5. The R1 puts the local BGP route calculation off until it receives the End-of-RIB flags from
all GR-Aware BGP neighbors or until the local Wait-For-EOR timer times out.
6. The R1 calculates routes and sends route updates to the neighbors. After the updates
are completed, R1 sends the End-of-RIB flags to the neighbors.
 Helper Router
1. When initiating to establish BGP neighbor relationship, R2 negotiates with R1 about the
GR capability, and it records R1 as a GR-Capable router.
2. When R1 is restarted, R2 may be aware that the TCP connection between itself and R1
is disconnected, or maybe R2 does not detect the disconnection before a new TCP con-
nection is established between them. If R2 does not detect the disconnection, go to Step
4. Otherwise, go to Step 3.
3. The R2 keeps the routes sent from the restarted router R1 and marks the stale flags. Af-
ter that, R2 starts the Restart Timer.
4. The restarted router initiates to establish a new connection, deletes the Restart Timer,
and starts the Wait-For-EOR Timer.
5. If the Restart Timer times out before the new connection is established, or if R2 receives
the OPEN message (for the new connection) whose Forwarding state is not 1 (The For-
warding state value 0 indicates that the restarted router does not support nonstop for-
warding of the corresponding address family routes), or if the OPEN message does not
contain the corresponding AFI/SAFI address family support information, R2 goes to Step
8.
6. Otherwise, R2 sends route updates to the restarted router. After that, it sends the End-
Of-RIB flags.
7. If the Wait-For-EOR Timer times out before the End-Of-RIB flags are sent, R2 goes to
Step 8.
8. The kept routes of the restarted router are cleared. The data is forwarded in accordance
with the normal BGP forwarding flow.
22.7 NSR
Overview
In a network application, device faults resulting from various factors may cause the interruption
of network services. To minimize the influence of device faults on the whole network, it is re-
SJ-20230719162004-003 | 2023-10-30 (R1.0) 219

quired to design a high-reliability device to improve the system fault tolerance and fault recovery
speed.
The high reliability is one of the important indexes to judge a device. At present, the reliability
technology includes:
 GR: a series of standards defined in IETF, which ensures that the package forwarding oper-
ation is not interrupted when the protocol is restarted. This function minimizes the influence
of faults on the whole network.
 NSR: a higher reliability technology. It ensures that the route between the forwarding plane
and the control plane is not interrupted after the switchover between the active/standby con-
trol planes. With this function, the device faults almost have no influence on the whole net-
work.
Traditionally, route convergence happens when the device has a fault. During the route conver-
gence, both loops and black holes may occur, which have serious influence on the network.
With the NSR function, a fault is recovered within the device, so there is no influence on the
network. The NSR function synchronizes valid information in real time between the processing
units of the active/standby control planes. During the active/standby switchover, the NSR func-
tion ensures that the route between the forwarding plane and the control plane is not interrupt-
ed. After the switchover, extra protocol recovery procedures with its neighbors are not required.
NSR Principle
After the NSR function is enabled for the device, the normal handling flow is as follows:
1. Input packages are sent to the processing unit of the active control plane.
2. After receiving the input packages, the processing unit of the active control plane process-
es these packages, generates necessary check information, and then sends all packages to
the processing unit of the standby control plane.
3. After receiving the packages from the processing unit of the active control plane, the pro-
cessing unit of the standby control plane processes all information, and then sends a com-
plete message to the processing unit of the active control plane.
4. After receiving the complete message from the processing unit of the standby control plane,
the processing unit of the active control plane sends all output packages generated by itself.
The device with the NSR function synchronizes the information in real time between the pro-
cessing units of the active/standby control planes, which ensures that the status and process-
ing logics of the processing units of the active/standby control planes are the same. When the
processing unit of the active control plane is faulty, the active/standby switchover happens. The
processing unit of the standby control plane immediately becomes active. In this case, the ser-
vices of both the forwarding plane and the control plane are not interrupted, and extra protocol
recovery procedures with its neighbors are not required.
220 SJ-20230719162004-003 | 2023-10-30 (R1.0)

22.8 Master/Slave Main Control Handover

Master/slave handover means the handover between the master main control board and the
slave main-control board. When the master main control board operates improperly (powered
off or reset manually), if the slave main-control board is online, the system will implement han-
dover automatically. This handover is transparent to applications at upper layer.
Master/slave main-control board handover shields off the influence due to the faults on the main
switching board. Applications at upper layer are not affected, which ensures the timely handling
of system data information.
The automatic master/slave handover is triggered when the master main-control plane is
restarted. In addition, you can run the master/slave handover command or press the mas-
ter/slave handover button on the main-control board to trigger the master/slave handover.
The master/slave handover is implemented by the process modules operating on the main-con-
trol board. The flow of master/slave handover is as follows:
1. Control the handover order of application process, and then send slave-to-master and mas-
ter-to-slave messages to application processes, that is, the master/slave handover of appli-
cation programs.
2. Set the master/slave state of boards, and interact with communication modules for handover
of communication links with periphery boards, that is, the communication link handover.
During this period, the intermediate state handover of application processes and data synchro-
nization (including the time when data is synchronized) are completed by application processes
themselves.
For the boards with master/slave configuration, if a fault occurs on the master main-control
board, the slave board needs to know the fault quickly and implement the handover. Therefore,
it is necessary to use a mate board scan thread to scan the state of the mate board in real time.
When the master/slave state or in-place state changes, the scan thread will inform the corre-
sponding main-control process to trigger the master/slave handover flow quickly.
When the thread scans that the master board operates improperly and the slave board oper-
ates properly, it will trigger the handover. The procedure of handover is implemented by the cor-
responding process module of the main-control.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 221

Chapter 23
MPLS Features
Description
Multi-Protocol Label Switch, MPLS operates at a layer that lies between traditional definitions of
layer 2 (data link layer) and layer 3 (network layer). In an MPLS network, data packets are as-
signed labels. Packet-forwarding decisions are made solely on the contents of this label, with-
out the need to examine the packet itself. MPLS supports label stacking that can build overlay
network architecture that multi-service forwarding on same bearing network.
OLT can act as a LER (Label Edge Router), and setup MPLS tunnels by IP route topology.
User services are overlaid on this IP/MPLS network by PWE3 encapsulation that includes
SAToP and Ethernet mode. The MPLS service in C6XX focuses on MPLS L2VPN application
including wholesale, mobile backhaul scenarios. The Multi-Protocol Label Switch (MPLS) archi-
tecture is used for high-speed data switching. MPLS provides network data flow with capacities
such as destination finding, routing, switching, and forwarding.
MPLS uses a traditional IP forwarding mode outside the MPLS domain and uses label switching
mode in the MPLS domain without looking up the IP information, as shown in Figure 23-1.
Figure 23-1 MPLS Working Principle
Within the MPLS domain, all routers run MPLS label distribution protocol, such as Label Distri-
bution Protocol (LDP) and resource ReSerVation Protocol (RSVP). Through these protocol, de-
vices in the MPLS domain will be distributed with corresponding labels.
The procedure of forwarding an IP packet in the MPLS domain is described below.
222 SJ-20230719162004-003 | 2023-10-30 (R1.0)

23 MPLS Features
1. The ingress Label Edge Router (LER) receives the IP packet, and distributes a label to this
packet for identification.
2. When the backbone Label Switched Router (LSR) receives the identified packet, it searches
its label forwarding table and replaces the label in the packet with a new outbound label.
3. When the egress LER receives the packet, it removes the label and implements traditional
IP forwarding on the third layer.
Principle
Figure 23-2 shows the MPLS implementation principle.
Figure 23-2 MPLS Implementation Principle
The implementation of MPLS in C6XX is subject to the principle of three-plane isolation:

The management plane supports telnet, ssh, console, snmp, and rmon. These are device man-
agement methods used for configuration and management of operation.
The control plane integrates multiple protocols and service control modules, which are used to
support frames switching and packets forwarding. C6XX supports IPv4/IPv6 dual stack, which
SJ-20230719162004-003 | 2023-10-30 (R1.0) 223

can work simultaneously and forward packets through binding the interface to the protocol
stack.
The forwarding plane realizes frame switching and packet forwarding. MPLS Bear Subsystem
includes L2VPN processing, PW handling, label handling, Routing, Load balancing, Redundan-
cy, MPLS OAM, CoS mapping between MPLS TC and CoS, and Performance Monitor.
Features and Specifications
The OLT C6XX supports following key MPLS features.

 Supporting IPv4/IPv6 MPLS.
 Implementing label distribution, including static MPLS label configuration and dynamic con-
figuration by Label Distribution Protocol (LDP).
à Supporting LDP protocol in accordance with RFC 3036.
à Supporting DoU mode.
à Supporting DoD mode.
à Supporting Inter-Area LDP in accordance with RFC 5283.
à Supporting Nonstop Forwarding (NSF) and MPLS LDP Graceful Restart in accordance
with RFC 3478.
 Supporting PWE3 encapsulation, type of SAToP E1/T1, Ethernet tag/raw.
 Supporting MPLS L2VPN Ethernet services, including VPWS and VPLS/H-VPLS.
 Supporting MPLS L3VPN Ethernet services, including BGP/MPLS IPv4/IPv6 VPN.
 Supporting MPLS OAM, includes MPLS ping/trace route, PW VCCV.
MPLS L2VPN
C6XX uses MPLS L2VPN technology to support Ethernet point -to-point Services (E-Line), Eth-
ernet point-to-multipoint Services（E-Tree）and Ethernet multipoint-to-multipoint Services（E-
LAN）.
The implementation of MPLS L2VPN is to encapsulate ATM cells, FR frames, and Ethernet
frames to MPLS frames, and design VPN network to enable VPN member sites communicate in
MPLS domain.
 Supporting VPWS in accordance with RFC 4448.
 Supporting VPLS and H-VPLS in accordance with RFC 4762.
 Supporting MPLS Pseudowire (PW) and FEC types 128 and 129 in accordance with RFC
3985.
 Supporting PW AII, SAI, and TAI in accordance with RFC 5003.
 Supporting static PW and establishing PW by LDP signaling in accordance with RFC 4447.
 Supporting multi-segments Pseudowire.
 Supporting Ethernet PW in both raw mode and tagged mode in accordance with RFC 4448.
224 SJ-20230719162004-003 | 2023-10-30 (R1.0)

23 MPLS Features
 Supporting negotiation of control word in accordance with RFC4385.

VPLS (Virtual Private LAN Service)
VPLS is to provide Ethernet emulation services on MPLS network. It connects several Local
Area Networks (LANs) / Virtual Local Area Networks (VLANs) together. It belongs to multi-
point-to-multipoint L2VPN service. The principle is shown in Figure 23-3.
Figure 23-3 VPLS Working Principle
Users can implement LANs of their own through Metropolitan Area Network (MAN) or Wide
Area Network (WAN).
VPWS (Virtual Private Wire Service)
VPWS is used to establish a special link and provide layer 2 transparent transmission service
on the basic of the MPLS network. It belongs to point-to-point L2VPN service. The principle is
shown in Figure 23-4.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 225

Figure 23-4 VPWS Working Principle
VPWS working mode: point-to-point.

The establishment procedure of a VPWS VC is described below.
1. LSP establishment: A Label Switch Path (LSP) is established through MPLS network.
2. VC allocation: Local PE configures a VCID, allocates a VC label and interacts with the re-
mote PE.
MPLS L3VPN
MPLS L3VPN is a kind of IP VPN based on MPLS technology. It is also called L3VPN, which
applies MPLS technology to routers and switches. MPLS VPN simplifies the route selection
mode of core routers, and it realizes IP virtual private network by means of the label switching
of conventional routing technology.
MPLS VPN can be used to construct broadband Intranet and Extranet, which can satisfy the re-
quirements of many services cleverly.
MPLS VPN can utilize the powerful transmission capability of a public backbone network to re-
duce the construction costs of the Intranet, and greatly improve the operation and management
flexibility of user networks. Meanwhile, it meets the user requirements for data transmission se-
curity, real time and broad band, convenience.
MPLS L3VPN Features:
 MPLS L3VPN uses L3 technology. Every VPN has its own VPN-ID. Every VPN user can on-
ly communicate with the members belonging to the same VPN, and only VPN members can
enter the VPN.
 In MPLS VPN, the Service Provider (SP) allocates an RD to every VPN. The RD is unique in
SP network.
 Forwarding table contains a unique address, called VPN-IP address, which is formed
through the connection of the RD and user IP address. The VPN-IP address is unique in the
network. The address table is stored in the forwarding table.
226 SJ-20230719162004-003 | 2023-10-30 (R1.0)

23 MPLS Features
 BGP is a routing information distribution protocol, which uses multi-protocol extension and
common attributes to define VPN connectivity. In MPLS VPN, BGP only advertises mes-
sages to the members in the same VPN, and provides basic security by means of traffic
split.
 VPN forwarding table contains a label that corresponds to the VPN-IP address. The label is
used to send data to the corresponding destination. Since the label replaces the IP address,
user can keep its own address structure. The data can be transmitted without Network Ad-
dress Translation (NAT). According to the data ingress, the corresponding router will select
a special VPN forwarding table that only contains a valid destination address in VPN. Router
selects a specified VPN forwarding table according to the ingress. The VPN forwarding table
contains the valid destination addresses only.
C6XX supports MPLS L3VPN Ethernet services, including BGP/MPLS IPv4/IPv6 VPN.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 227

Chapter 24
QoS Features
Table of Contents
QoS Description....................................................................................................................... 228
QoS Application Scenario........................................................................................................ 228
QoS Principle............................................................................................................................230
24.1 QoS Description

The ZXA10 C600/C650/C620 provides an H-QoS mechanism, which provides different meth-
ods for guaranteeing service quality for specific users and specific applications.
The service traffic between the OLT and ONU passes through different physical and logical in-
terfaces. Different Layer 2 ports requires different QoS granularities, and there is a hierarchi-
cal structure between different granularities, to flexibly satisfy operators' requirements. The in-
tegrated QoS processing procedure for the service that passes through the PON system includ-
ing the ONU and OLT is as follows:
On the ONU, the service traffic is associated with the GEM and T-CONT through a configured
mapping relationship. In the upstream direction, the service traffic is scheduled to the OLT
through the QoS processing achieved by DBA from the ONU to the OLT.
On the OLT PON board, a user with multiple services can be identified through a virtual port
(vport), or a service-port. That is to say, the PON board supports two-level QoS.
On the OLT uplink ports, the physical ports and VLANs based on Ethernet also support the
QoS processing based on each flow.
24.2 QoS Application Scenario

L2 QoS Scenario
The L2 QoS scenario is a most common application scenario of the ZXA10 C600/C650/C620
OLT. It can be classified into the following two types:
 QoS based on service types (Class of Services)
Traditionally, operators deploy BRASs. The upper-layer BRAS implements the downstream
bandwidth control per service per user, and the access network implements QoS in accor-
dance with service types.
228 SJ-20230719162004-003 | 2023-10-30 (R1.0)

24 QoS Features
Configuration: uplink board + PON interface board/Ethernet downlink board.

à Downstream service
The uplink Ethernet ports are configured with the priority identification function. The map-
ping relationship between the priority of the service type and the egress queue is con-
figured on the PON port. The egress queue implements the SP, DWRR and SP+DWRR
scheduling.
In the BRAS rate-limit scenario, the L2 QoS does not limit rate of downstream traffic. The
OLT supports to mark color marking on packets according to packet CoS values. When
multiple service flows enter a queue of the same service type and congestion occurs, the
queue performs WRED drop on packets according to packet colors, and ensure the high-
er throughput of green packets.
à Upstream service
On the PON interface board, the ONU schedules the service traffic to the OLT accord-
ing to the bandwidth parameters configured through DBA. The upstream priority identi-
fication function is configured on the VPORT port on the PON board. The mapping rela-
tionship between the priority of the service type and the upstream egress queue is con-
figured on the upstream port. The upstream queue implements the SP, DWRR and SP
+DWRR scheduling.
 H-QoS implemented per service per user
When the OLT upper-layer device of an operator does not control the service traffic of each
user, the H-QoS per service per user must be implemented on the OLT, which prevents a
single user from using too much bandwidth on a shared PON port. The operator implements
H-QoS control to each user through the QoS package of the OLT, ensures the fair band-
width allocation among users, and ensure priority scheduling among different services for
each user. When multiple operators share the same OLT, each operator has an individual
uplink port.
Configuration: uplink board + PON interface board. The QoS is implemented in stages. The
service-level QoS is implemented in the uplink board, and H-QoS is implemented in the
PON interface board.
à Downstream service
The uplink Ethernet port implements the priority identification function.
The rate limit is configure on the PON interface board. Both service-based rate limit and
user-based rate limit support traffic monitoring and traffic shaping. The traffic monitoring
parameters includes PIR/CIR/PBS/CBS, Color blind/Color aware, Coupling, RFC/MEF/
Enhanced MEF. The traffic shaping parameters include PIR/CIR/PBS/CBS). WRED can
be configured on queues to process the color marked by the previous traffic monitoring.
à Upstream service
SJ-20230719162004-003 | 2023-10-30 (R1.0) 229

The DBA parameters that schedule the ONU T-CONT traffic to the OLT, virtual port
(VPORT) priority identification, the rate limitation parameters (PIR/CIR/PBS/CBS) of the
user service traffic, and also rate limitation (PIR/CIR/PBS/CBS) based on service-port on
the PON interface board.
The mapping relationship between priorities and the upstream egress queue is config-
ured on the uplink board. The queue is configured with SP, DWRR, WFQ queue, weight,
and color-sensitive WRED.
L3 QoS Scenario
In the scenario where the OLT is used as an L3 router, the OLT only needs to implement the
layer 3 forwarding of service traffic. The L3 priority mapping is added in the QoS. The applica-
tion scenario can be classified in to the following:
 Downstream direction: The DSCP to CoS mapping of priorities is configured at the ingress
of the upstream port.
 Upstream direction: The CoS to DSCP mapping of priorities is supported at the egress of
the upstream port.
Other application scenarios are the same as those of L2 QoS.
24.3 QoS Principle

Downstream H-QoS Scheduling Principle
For downstream services, when a port of the control and switching board is connected to the
upstream, the uplink Ethernet port entity implements the priority identification. On the inter-
nal port between the control and switching board and the PON interface board, the congestion
avoidance and queue scheduling are implemented. The PON interface board supports the ser-
vice-port traffic monitoring (CIR/PIR). The VPORT (user level) implements the traffic monitor
and provides congestion avoidance and queue scheduling, see Figure 24-1.
230 SJ-20230719162004-003 | 2023-10-30 (R1.0)

24 QoS Features
Figure 24-1 Downstream H-QoS Scheduling
Figure 24-2 shows the downstream traffic flow and congestion within the OLT.
Figure 24-2 Downstream Traffic Flow and Congestion
SJ-20230719162004-003 | 2023-10-30 (R1.0) 231

Through the H-QoS mechanism, if the CIR configuration is not exceeded, the bandwidth of the
CIR per service per user and EIR of each stream can be configured according to weights.
 QoS features of downstream services on the uplink board
à Ethernet port: Supports the priority identification of downstream services in the ingress
direction. During link aggregation of multiple ports, the QoS attributes (including egress
priority enqueue and queue scheduling) of all the ports in the smart group are the same.
à The uplink board allocates a group of VoQ queues to each service card. When data
packets enter VoQ queues, the packets are scheduled to individual card according to
service type priorities. A group of VoQ queues contains eight queues and one schedul-
ing unit. If congestion occurs, the congestion avoidance and queue scheduling function
is implemented. By default, data packets enter a queue in accordance with the priority, to
achieve the SP scheduling.
à The uplink port supports the downstream rate limitation.
 QoS features of downstream services on the PON interface board
The packets forwarded to the PON interface board find the VPORT of the corresponding
user through the L2 switching. A VPORT can be considered as a logical Ethernet port. Multi-
ple VPORTs can be configured on a PON port. A VPORT corresponds to an FTTH user. In
the QoS level, the data traffic that enters a VPORT can be classified as required. Except the
L2 CoS traffic classification, the service-port-based can be used. .
Besides the VPORT control in the user level, the QoS based on the user service traffic can
also be used.
à Each ONU supports one or multiple VPORTs. The user-based traffic monitoring can be
implemented through the configuration of the parameters such as CIR/PIR/CBS/PBS on
the VPORT.
à A service-port-based traffic is a service traffic converted from the data traffic in the
VPORT and identified through the VLAN/VLAN+cos conversion relationship. Each ser-
vice-port-based traffic can implement upstream and downstream traffic monitoring. The
service-based traffic control can be implemented through the configuration of the para-
meters such as CIR/PIR/CBS/PBS on the service-port.
à Beside service-port-based traffic limit, the service-level rate limit can be implemented by
configuring traffic shaping on corresponding queues. In this way, CIR bandwidth is guar-
anteed and the surplus bandwidth can be internally scheduled using SP+WRR schedul-
ing.
à The downstream of each VPORT includes several queues, providing congestion avoid-
ance and queue scheduling functions to implement output traffic shaping for each user.
232 SJ-20230719162004-003 | 2023-10-30 (R1.0)

24 QoS Features
à Based on the multicast SCB feature of the PON port, the PON interface board provides
an SCB VPORT of a special user to the video IPTV services. This VPORT has multiple
priority queues.
The downstream congestion processing procedure is described as follows:
1. The VPORT of each user enters a queue according to different services. Packets are
processed in two routes according to the CIR/PIR configuration of this service-port. The CIR
traffic and EIR traffic are scheduled by the different scheduler.
Each VPORT is configured with CIR and EIR schedulers in different levels. The packets of
CIR in different levels of each VPORT are scheduled with DWRR scheduling according to
the queue level by the scheduler in the corresponding level. Each VPORT has four queues.
They are Q1 to Q4 in a descending sequence. The CIR traffic in Q1 is scheduled by the
green DWRR1 scheduler, and the EIR traffic is scheduled by the yellow DWRR1 scheduler.
The weight of a scheduler is calculated according to the CIR/PIR parameters of the ser-
vice-port-based traffic. The PIR value, the total rate limit of the VPORT, is used to limit the
maximum output scheduling traffic of this VPORT.
2. The VPORT scheduled traffics, together with PON protocol traffics (OMCI, OAM), and multi-
cast traffics, are scheduled using SP scheduling on the PON port.
3. After the CIR and EIR traffic is processed as described above, it is scheduled with the SP+
DWRR scheduling again. After the SP+DWRR scheduling, the CIR traffic is configured with
the scheduling weight factor of the green DWRR scheduler. After the SP+DWRR sched-
uling, the EIR traffic is configured with the scheduling weight factor of the yellow DWRR
scheduler.
4. The PON port supports the traffic rate limit in the PON port level, performs the SP schedul-
ing to the CIR and EIR traffic, and guarantees the CIR packets to be scheduled preferential-
ly.
The above procedure describes the rate limit of the service-port traffic and the scheduling of
the enqueue procedure. If the L2 CoS enqueue and the total rate limit of the VPORT is config-
ured in each queue, which means that, the rate limit of all queues in the VPORT is the same,
the scheduling weight of all queues are calculated according to the configured VPORT parame-
ters.
Upstream H-QoS Scheduling Principle
Figure 24-3 shows the upstream traffic flow and congestion within the OLT.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 233

Figure 24-3 Upstream Traffic Flow and Congestion
ONU local priority scheduling and PON DBA achieve two-level H-QoS scheduling. The up-
stream scheduling from the ONU to the OLT uses the DBA scheduling specified by the PON
standards. The DBA algorithm ensures the bandwidth fair among ONUs.
The DBA control of the upstream traffic on the GPON and XG-PON ports is scheduled based
on T-CONT. T-CONT are classified into the following five types as service required, refer to Ta-
ble 24-1.
Table 24-1 T-CONT Type

Description Type 1 Type 2 Type 3 Type 4 Type 5
Fixed bandwidth RF 0 0 0 RF
Assured band- 0 RA RA 0 RA
width
Maximum band- RM = RF RM = R A RM > R A RM RM ≥ RF + RA

width
Traffic attribute Assured Assured Unassured Best effort Unassured
T-CONT of different types can be configured with different parameters. There are three types
of bandwidth: fixed bandwidth, assured bandwidth and maximum bandwidth. The fixed and as-
sured bandwidth cannot exceed the total upstream bandwidth of the PON port. The bandwidth
is assigned in the following sequence:
1. The T-CONT bandwidth in Type 1 and Type 2 is assured.
234 SJ-20230719162004-003 | 2023-10-30 (R1.0)

24 QoS Features
2. The surplus bandwidth is assigned to the unassured bandwidth of Type 3 and Type 5. The
traffic that can be obtained by T-CONT is calculated according to the weight factor RF + RA.
3. The surplus bandwidth is assigned to the best effort bandwidth of other types such as Type
4, and the weight factor is RM – RF – RA.
 QoS on the upstream PON board.
The PON interface board supports upstream traffic limit configuration on service port and
VPORT. The PON interface board also supports traffic color marking for uplink board.
The PON interface board colors the CIR packets of the user traffic packets to green and col-
ors the EIR packets to yellow.
 QoS on the upstream uplink board.
On the egress direction of the uplink ports, packets enter a queue according to the priori-
ties. The queue scheduler supports SP + WFQ. The uplink board can recognize the color
of packets, and uses color-sensitive WRED to make green packets getting through and dis-
carding yellow packets when congestion occurs.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 235

Chapter 25
IPv6 Features
Table of Contents
IPv6 Overview.......................................................................................................................... 236
IPv6 Address............................................................................................................................ 237
NDP.......................................................................................................................................... 250
DHCPv6.................................................................................................................................... 251
ICMPv6..................................................................................................................................... 254
25.1 IPv6 Overview

Internet Protocol Version 6 (IPv6) is a new version of the Internet Protocol. The significant
changes from IPv4 to IPv6 are as follows:
 Expanded addressing capabilities
IPv6 increases the IP address size from 32 bits to 128 bits, to support more levels of ad-
dressing hierarchy, a much greater number of addressable nodes, and simpler auto-configu-
ration of addresses. The scalability of multicast routing is improved by adding a "scope" field
to multicast addresses. And a new type of address called an "anycast address" is defined,
used to send a packet to any one of a group of nodes.
 Header format simplification
Some IPv4 header fields have been dropped or made optional, to reduce the common-case
processing cost of packet handling and to limit the bandwidth cost of the IPv6 header.
 Improved support for extensions and options
Changes in the way IP header options are encoded allows for more efficient forwarding, less
stringent limits on the length of options, and greater flexibility for introducing new options in
the future.
 Flow labeling capability
A new capability is added to enable the labeling of packets belonging to particular traffic
"flows" for which the sender requests special handling, such as non-default quality of service
or "real-time" service.
 Authentication and privacy capabilities
Extensions to support authentication, data integrity, and (optional) data confidentiality are
specified for IPv6.
236 SJ-20230719162004-003 | 2023-10-30 (R1.0)

25 IPv6 Features
25.2 IPv6 Address

IPv6 Address Overview
Internet Protocol (IP) version 6 is a new IP protocol, designed to replace IP version 4, the Inter-
net protocol that is predominantly deployed and extensively used throughout the world.
However, the original design did not anticipate the following conditions:
 Recent exponential growth of the Internet and the impending exhaustion of the Internet Pro-
tocol version 4 (IPv4) address space.
 Growth of the Internet and the ability of Internet backbone routers to maintain large routing
tables.
 Need for simpler auto configuration and renumbering.
 Requirement for security at the IP level.
 Need for better support to real-time delivery of data, also called Quality of Service (QoS).
Note
Features such as IP Security Protocol (IPSec) and QoS have been specified for both versions of IP.
Internet Protocol Version 6 (IPv6) features a huge address capacity up to 128 bits, which is de-
scribed as follows:
 It provides 2128 different IPv6 addresses, that is, the number of the allocable addresses
around the world is 340,282,366,920,938,463,463,374,607,431,768,211,456.
 20 2
It provides 2.2×10 addresses per cm if addresses are allocated based on ground area.
IPv4 and IPv6 Header Format
The following are differences between IPv4 and IPv6 in header format.
The header formats of IPv4 and IPv6 as shown in Figure 25-1 and Figure 25-2 respectively.
(Numbers in the figures refer to bit numbers.)
SJ-20230719162004-003 | 2023-10-30 (R1.0) 237

Figure 25-1 IPv4 Header Format
Figure 25-2 IPv6 Header Format
IPv6 header is simpler than IPv4 header in structure because many fields in IPv4 header that
are not frequently used are deleted from IPv6 header, and are put into its options and header
extension, which are defined more strictly.
 IPv4 contains ten fields with fixed length, two address spaces and some options, while IPv6
contains only six fields and two address spaces.
 Although IPv6 header occupies 40 bytes, which is 1.6 times of IPv4 header with 24 bytes, it
does not consume too much memory capacity due to its fixed length (the length of the IPv4
header is variable).
 The following six fields are deleted from IPv4 header: header length, type of service, identifi-
er, flags, fragmented offsets and header checksum. Names and some functions of the three
fields of total length, protocol and Time to Live (TTL) are changed, and its optional functions
are completely changed. Apart from this, two fields are added: traffic type and flow label.
 IPv6 header format is greatly simplified, which effectively pares down overhead of process-
ing headers by a router or switch. At the same time, IPv6 enhances the support to the ex-
tension header and options, which not only allows more efficient forwarding, but also pro-
vides sufficient support for future loading of new applications to networks. Each IPv6 packet
238 SJ-20230719162004-003 | 2023-10-30 (R1.0)

25 IPv6 Features
can have 0, 1 or more extension headers. Each extension header is determined by the "next
header" domain of the previous header.
25.2.1 Address Classification

Overview
Request For Comments (RFC) contains a "map" of IPv6 address space, which describes how
the address space is allocated, the different types of address allocation, the prefixes (the start-
ing few bits in address allocation) and the length of address allocation, which is a part of the
whole address space. Table 25-1 shows allocation of IPv6 address space.
Table 25-1 IPv6 Address Space

Allocation Prefix Fraction of Address Space
Reserved 0000 0000 1/256
Unallocated 0000 0001 1/256
Reserved for NSAP allocation 0000 001 1/128
Reserved for IPX allocation 0000 010 1/128
Unallocated 0001 1/32
Aggregatable global unicast ad- 001 [2,3] 1/8

dress
Unallocated 010 1/8
Unallocated 011 1/8
Unallocated 100 1/8
Unallocated 101 1/8
Unallocated 110 1/8
Unallocated 1110 1/16
Unallocated 1111 1110 0 1/512
Link local unicast address 1111 1110 10 [FE8] 1/1024
Site local unicast address 1111 1110 11 [FEC] 1/1024
SJ-20230719162004-003 | 2023-10-30 (R1.0) 239

Allocation Prefix Fraction of Address Space
Multicast address 1111 1111 [FF] 1/256
Note
The hex number in [] in this table refers to the starting and ending hex numbers of the corresponding ad-
dress.
Broadcast address in IPv6 is not valid any more. RFC defines three types of IPv6 address:
 Unicast
It is the identifier of a single interface. The packets sent to a unicast address are transmitted
to the interface with this address identifier.
 Multicast
It is the identifier of a group of interfaces. These interfaces belong to different nodes. The
packets sent to a multicast address are transmitted to all the interfaces with this address
identifier.
 Anycast
It is the identifier of a group of interfaces. These interfaces belong to different nodes. The
packets sent to an anycast address are transmitted to an interface with this address identifi-
er (selecting the nearest one by calculating the distance based on routing protocol).
An IPv6 unicast address can be regarded as an entity with two fields. One field is used to iden-
tify networks and the other is used to identify interfaces of nodes on this network. In the subse-
quent description of the specific unicast address types, the user finds that the network identifier
can be divided into several parts, each of which identifies different network parts.
Unicast Address
Functions of an IPv6 unicast address are subject to Classless Inter-Domain Routing (CIDR),
which is the same as that of an IPv4 address. That is, an address is divided into two parts upon
a specific boundary. The high bit part of an address includes a prefix for routing and the low bit
part includes identifiers of network interfaces.
In the IPv6 addressing system structure, any IPv6 unicast address requires an interface identifi-
er. An interface identifier is very similar to the 48-bit Media Access Control (MAC) address. The
MAC addresses are encoded through hardware in a network interface card. They are burned by
the manufacturer into a network interface card and are globally unique. There are no two net-
work interface cards with an identical MAC address. Such addresses can be used to uniquely
identify the interfaces at the network link-layer.
The interface identifier of an IPv6 host address is based on the Institute of Electrical and Elec-
tronics Engineers (IEEE) EUI-64 format, which creates a locally and globally unique 64-bit inter-
face identifier based on the existing MAC addresses.
240 SJ-20230719162004-003 | 2023-10-30 (R1.0)

25 IPv6 Features
These 64-bit interface identifiers can address one by one globally and can uniquely identify the
interface of each network. This means that, in theory, there are up to 264 different physical in-
terfaces and about 1.8 x 1019 different addresses, which, however, only occupy half of the IPv6
address space. It is enough in the foreseeable future at least.
The IPv6 unicast address can be classified into the following categories:
 Aggregatable Global Unicast Address
This is another kind of aggregation, which is independent of an Internet Service Provider (
ISP). The provider-based aggregated addresses must be changed as a provider changes,
while the exchange-based addresses are directly located by an IPv6 switching entity. The
exchange provides address blocks, and users and providers conclude contracts for the net-
work access.
Such network access is either directly provided by a provider, or indirectly provided by an
exchange. However, the routing is through the exchange. In this way, a user needs not to
address again when it changes a provider. At the same time, users are allowed to use multi-
ple ISPs to process single-block network address.
Aggregatable global unicast addresses include all the addresses whose three starting bits
are 001, which can be used as prefixes for other unallocated unicast. Table 25-2 lists the
aggregatable global unicast address fields.
Table 25-2 Aggregatable Global Unicast Address Fields

3 13 8 24 16 64
FP TLA ID RES NLA ID SLA ID Interface identifier
Table 25-2 includes the following fields.

à FP field
This is the 3-bit format prefix in an IPv6 address, indicating to which address category in
the IPv6 address space this address belongs. Currently, the field is 001, indicating this is
an aggregatable global unicast address.
à TLA ID field
This is the top-level aggregation identifier, including the routing information about the ad-
dresses at the highest level. Here, it refers to the routing information with the most hosts
in network interconnection. Currently, this field is 13 bits and can obtain at most 8,192
different top level routes.
à RES field
This is an 8-bit field and reserved for future use. It is likely to be used for extending the
top- or next-level aggregation identifier field.
à NLA ID field
SJ-20230719162004-003 | 2023-10-30 (R1.0) 241

This is the next-level aggregation identifier with 24 bits. This identifier is used by some
institutions (including large-size ISPs and other institutions that provide public network
access) to control the top-level aggregation for address space arrangement.
Such institutions can divide this 24-bit field for use in accordance with their own addressing
hierarchical structures. In this way, an entity can divide two bits of address space into four
internal top-level routes, and allocate the other 22 bits of address space to other entities (for
example, a small local ISP).
When these entities obtain enough address space, they can subdivide the obtained space in
the same way as mentioned above.
à SLA ID field
This is the site aggregation identifier and is used by some institutions to arrange their in-
ternal network structures. Each institution can create its own internal hierarchical network
structure in the same way as that of IPv4.
When the 16-bit field is dedicated to the plane address space, there are at most 65,535
different subnets available. If the first eight bits are used for the internal advanced routing
of this institution, then there will be 255 advanced subnets available, and each advanced
subnet can have up to 255 sub-subnets.
à Interface identifier field
This is a 64-bit field, containing 64-bit values of the IEEE EUI-64 interface identifier.
 Special Address & Reserved Address
In the first 1/256 IPv6 address space, the first 8 bits 0000 0000 of all the addresses are re-
served. Most of the vacant address spaces are used for special addresses, including:
à Undesignated address
This is an all-zero address and is used if no valid address is available. For example, if
a host does not obtain an IPv6 address upon its initial startup from the network, it can
use this address. That is, it can specify this address for the source address of the IPv6
packet when it sends out a request for configuration information. This address can be ex-
pressed as 0:0:0:0:0:0:0:0, or expressed as ::.
à Loopback address
In IPv4, the loopback address is defined as 127.0.0.1. Any packet that sends a loopback
address must be sent to a network interface through a protocol stack, instead of being
sent to the network link. The network interface itself should accept these packets in the
same way as it receives packets from external nodes, and transmits them back to the
protocol stack.
The loopback function is used for software test and configuration. Except the lowest bit,
all the other bits of an IPv6 loopback address are 0, that is, a loopback address can be
expressed as 0:0:0:0:0:0:0:1 or ::1.
242 SJ-20230719162004-003 | 2023-10-30 (R1.0)

25 IPv6 Features
à IPv6 address embedded with IPv4 address

In the RFC, IPv6 provides two kinds of addresses. One is the IPv4-compatible address,
which allows the IPv6 node to access IPv4 nodes that do not support IPv6.. The other
is the IPv4-mapping address, which allows the IPv6 router to transmit IPv6 packets over
the IPv4 network in tunnel mode, where the nodes understand both IPv4 and IPv6.
The high-order 80 bits of these two kinds of addresses are all set to zeros, and the low-
order 32 bits contain the IPv4 address. If the middle 16 bits of an address are set to
FFFF, it indicates that this address is the IPv6 address mapping to IPv4 address. Table
25-3 lists the address structures of these two kinds of addresses.
Table 25-3 Structure of the IPv6 Address Embedded With IPv4 Address
IPv4 Compatible Address
80 16 32
0000.................................0000 0000 IPv4 address
IPv4 image address
80 16 32
0000.................................0000 FFFF IPv4 address
 Link Local Address and Site-Local Address

Using the network Model 10 address to translate IPv4 network addresses provides an option
for the institutions that do not want to request globally unique IPv4 network addresses.
A router that resides outside of an institution but used by the institution shall not forward
these addresses. It can neither prevent these addresses from being forwarded, nor distin-
guish these addresses from other valid IPv4 addresses. It is comparatively easier to make
configurations for a router to enable it to forward these addresses.
To implement this function, IPv6 allocates two different address segments from the globally
unique Internet space. Table 25-4 is originated from RFC, indicating the structures of link-lo-
cal and site-local addresses.
Table 25-4 Structures of Link-local Address and Site-local Address

Link-local Address
10 54 64
1111111010 0 Interface identifier
Site-local Address
10 38 16 64
1111111011 0 Subnet identifier Interface identifier
SJ-20230719162004-003 | 2023-10-30 (R1.0) 243

Link-local addresses are used in a single network link for host numbering. The address iden-
tified by the first ten bits of the prefix is the link-local address. Routers do not process the
packets with link-local addresses at their source end and destination end because they nev-
er forward these packets.
The middle 54 bits of this address are set to zero, its 64-bit interface identifier is in the same
IEEE structure as mentioned in the foregoing paragraphs, and the part of this address space
64
allows some networks to connect up to 2 -1 hosts.
Link-local addresses are used for the single network link and site-local addresses are used
for sites. It means that site-local addresses can be used to transmit data in the interconnect-
ed networks but cannot be directly routed to the global Internet from a site.
Routers within a site can only forward packets within the site instead of forwarding them out-
side of the site. The 10-bit prefix of a site-local address is immediately followed by a succes-
sion of zeros, which is slightly different from that of a link-local address. The subnet identifi-
er of a site-local address is 16-bit, and its interface identifier is still the 64-bit IEEE-based ad-
dress.
Note that the special behavior of site-local addresses has been removed from RFC. Ad-
dresses such as fec0::/10 need to be treated as common unicast addresses.
 Open Systems Interconnection (OSI) Network Service Access Point (NSAP) Address and
Internetwork Packet Exchange (IPX) Address
One of the IPv6 objectives is to unify the whole network world for among IP, IPX, and OSI
networks. To support this interoperability, IPv6 reserves 1/128 address space for OSI NSAP
address and network IPX address respectively.
At present, the IPX addresses have not been precisely defined. Refer to RFC for description
of the NSAP address allocation.
Multicast Address
The format of the IPv6 multicast address is different from that of the IPv6 unicast address. Mul-
ticast addresses can only be used as destination addresses. No packet uses a multicast ad-
dress as the source address. Table 25-5 lists the format of a multicast address.
Table 25-5 Multicast Address Format

8 4 4 112
1111111 Flags Scope Group identifier
The first byte of the address format is set to full-one, identifying it as a multicast address. The
multicast address occupies the entire 1/256 of the IPv6 address space. The other parts except
the first byte of the multicast address format contain the following three fields:
 Flags field
244 SJ-20230719162004-003 | 2023-10-30 (R1.0)

25 IPv6 Features
This field consists of four single bit flags. Currently, only bit-4 is designated to indicate that
whether this address is a well-known multicast address designated by the Internet number-
ing institution, or a temporary multicast address used in a specific occasion.
If this flag bit is set to zero, it indicates that this address is a well-known address. If this flag
bit is set to one, it indicates that this address is a temporary address. The other three flag
bits are reserved for future use. The initialization value is 0.
 Scope field
This is a 4-bit field and is used to indicate the range of multicast. That is, whether a multicast
group only includes nodes within the same local network, the same site or the same institu-
tion, or includes nodes that reside anywhere in the IPv6 global address space. The possible
values 4-bit value ranges from 0 to 15. Table 25-6 lists the corresponding range.
Table 25-6 Multicast Scope Values

Hex Decimal Value
0 0 Reserved
1 1 Node-local range
2 2 Link-local range
3 3 Reserved
4 4 Management-local range
5 5 Site-local range
6 6 Unallocated
7 7 Unallocated
8 8 Institution-local range
9 9 Unallocated
10 A Unallocated
11 B Unallocated
12 C Unallocated
13 D Unallocated
14 E Global range
15 F Reserved
 Group ID field
The 112-bit multicast ID field identifies a multicast group within a specified range perma-
nently or temporarily.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 245

Anycast Address
A multicast address can be shared by many nodes in a sense. All the nodes of the members
of a multicast address expect to receive all the packets sent to this address. A router connect-
ing to five different local Ethernet networks should forward a copy of these multicast packets
to each network respectively (supposing at least one node of each network subscribers to this
multicast address).
Anycast addresses are similar to multicast addresses. Although the two are in the same case
that an anycast address can be shared by multiple nodes, only one node of an anycast address
expects to receive the packet sent to the anycast address.
Anycast is helpful in providing services, especially those requiring no relationship between
client and server, such as, a domain name server and a time server. A domain name server is
nothing but a name server, which provides the same performance whether it is located closely
or remotely.
Similarly, a closely located time server is preferable in terms of accuracy. Therefore, when a
host sends a request to an anycast address to obtain information, it is the nearest server asso-
ciated to this anycast address that shall respond.
Anycast addresses are allocated outside of the normal IPv6 unicast address space. Anycast
addresses cannot be distinguished from unicast addresses in their forms, and each member of
an anycast address should be explicitly configured to identify an anycast address.
25.2.2 Address Expression Way

Overview
An IPv4 address is expressed in four parts separated by dots, that is, four numbers separated
by dots. The following are some legal IPv4 addresses expressed by decimal integer: 0.5.3.1,
127.0.0.1, 201.199.244.101.
An IPv4 address is expressed as a group of four 2-bit hex integers or four 8-bit binary integers,
of which the latter one is seldom used.
The length of an IPv6 address is four times greater than an IPv4 address, and the complica-
cy of expression for an IPv6 address is also four times greater than an IPv4 address. An IPv6
address can be basically expressed as X:X:X:X:X:X:X:X, among which X is 4-bit hex integers
(16-bit). Each number contains four bits, each integer contains four numbers and each address
contains eight integers. There are totally 128 bits (4 x 4 x 8 = 128). The following are some legal
IPv6 addresses:
CDCD: 910A:2222:5498:8475:1111:3900:2020
1030:0:0:0:C9B4:FF12:48AA:1A2B
2000:0:0:0:0:0:0:1
246 SJ-20230719162004-003 | 2023-10-30 (R1.0)

25 IPv6 Features
All these integers are hex integers and those from A to F represent 10 to 15. Each integer of an
address must be indicated except for the starting zero. This is a relatively standard way to ex-
press an IPv6 address. Apart from this, there are two more ways that are clearer and easier to
use.
Some IPv6 addresses contain a succession of zeros, similar to the second and the third exam-
ples as mentioned above. In this case, the succession of zeros can be represented by "pacing",
as provided in the relevant standard.
That is to say, the address 2000:0:0:0:0:0:0:1 can be expressed as 2000::1, of which the two
colons mean that the address can be extended to a complete 128-bit address. In this method,
only when the 16-bit group is all-zero, can it be substituted by two colons, which can only be
used once in the address.
Table 25-7 lists examples for compressed formats of IPv6 addresses.
Table 25-7 IPv6 Address Compression

Add Type Normal Format Compressed Format
Unicast address 1080:0:0:0:8:800:200C:417A 1080::8:800:200C:417A
Multicast address FF01:0:0:0:0:0:0:101 FF01::101
Loopback address 0:0:0:0:0:0:0:1 ::1
Unspecified address 0:0:0:0:0:0:0:0 ::
In the environment mixed with IPv4 and IPv6, there may be a third way. The least signif-
icant 32-bit in an IPv6 address can be used to express an IPv4 address in a mixed way:
X:X:X:X:X:X:d.d.d.d, among which X represents a 16-bit and d indicates a 8-bit decimal integer.
For example, the address 0:0:0:0:0:0:10.0.0.1 is a legal IPv4 address. Therefore, this address
is expressed as: 10.0.0.1 by combining the two possible expressions.
An IPv6 address consists of two parts: subnet prefix and interface identifier. An IP node ad-
dress is expected to be expressed in a way similar to that of a CIDR address, as an address
carrying an extra value, indicating how many bits of the address is the mask.
An IPv6 node address indicates the length of a prefix by separating the length from the IPv6 ad-
dress with a slash.
For example, in the address of
1030:0:0:0:C9B4:FF12:48AA:1A2B/60, the length of the prefix for routing is 60-bits
IPv6 Host Address
An IPv6 host has many IPv6 addresses even if it has only one single interface. An IPv6 host
can have the following unicast addresses simultaneously.
 The link-local address of each interface
SJ-20230719162004-003 | 2023-10-30 (R1.0) 247

 The unicast address of each interface, which can be a site-local address or one or more ag-
gregatable global addresses
 Loopback address (::1) of a loopback interface
In addition, each host must always keep receiving the data from the following multicast ad-
dresses.
 Multicast addresses (FF01::1) of all the nodes within the node-local range
 Multicast addresses (FF02::1) of all the nodes within the link-local range
 Multicast address of the solicited-node (if the solicited-node group is added to an interface of
the host)
 Multicast address of a multicast group (if any multicast group is added to an interface of the
host)
IPv6 Router Address
The following unicast addresses can be allocated to an IPv6 router:

 Link-local address of each interface
 Unicast address of each interface, which can be a site-local address or one or more aggre-
gatable global addresses
 Subnet-router anycast address
 Other anycast addresses (optional)
 Loopback address (::1) of a loopback interface
Similarly, apart from these addresses, a router must always keep listening to the data flow from
the following multicast addresses.
 Multicast addresses (FF01::1) of all the nodes within the node-local range
 Multicast addresses (FF02::1) of all the nodes within the link-local range
 Multicast addresses (FF02::2) of all the routers within the link-local range
 Multicast addresses (FF05::2) of all the routers within the site-local range
 Multicast address of the solicited-node (if the solicited-node group is added to an interface of
the router)
 Multicast address of a multicast group (if any multicast group is added to an interface of the
router)
25.2.3 IPv6 Address Auto Configuration Technology

Overview
The state auto configuration employs plug-and-play mode to insert a node into the IPv6 network
and starts it up without any manual interference. IPv6 has two different mechanisms to shore up
the plug-and-play network connection.
248 SJ-20230719162004-003 | 2023-10-30 (R1.0)

25 IPv6 Features
State auto configuration
 Boot protocol (BOOTstrap Protocol (BOOTP))

 Dynamic Host Configuration Protocol (DHCP)
Both of the two mechanisms allow IP nodes to obtain configuration information from a special
BOOTP server or the DHCP server. These protocols use the state auto configuration, that is, a
server must retain and manage the state information about each node.
Stateless auto configuration
Apart from state auto configuration, IPv6 also employs a type of auto configuration service
named stateless auto configuration.
For the stateless auto configuration, the local link must support multicast. The network interface
must be able to send and receive multicast packets. In the stateless auto configuration process,
the relevant nodes must meet the following requirements.
 A node for auto configuration must determine its own link-local address.
 Authenticate this link-local address to make sure that it is unique in the link.
 The node must determine the information to be configured. Such information can be the IP
address of this node, other configuration information, or both of them. In case an IP address
is needed, the node must determine whether to obtain it through the stateless auto configu-
ration or through the state auto configuration.
The procedure is as follows:
1. In the stateless auto configuration process, the host adds its network adapter MAC address
after the 1111111010 prefix of the link-local address to create a link-local unicast address.
IEEE has modified the network adapter MAC address from 48-bit to 64-bit. If the network
adapter MAC address used by the host is still 48-bit, the IPv6 network adapter driver will
convert the 48-bit MAC address to the 64-bit MAC address in accordance with an IEEE for-
mula.
2. The host sends a neighbor discovery request to the address to check whether the address
is unique.
If there is no response to the request, it indicates that the link-local unicast address config-
ured by the host itself is unique. Otherwise, the host will use an interface ID randomly creat-
ed to form a new link-local unicast address.
3. Taking the address as the source address, the host sends a router solicitation in the multi-
cast way to all the routers within the local link to request configuration information. Routers
respond to it with a router advertisement containing the prefix of an aggregatable global uni-
cast address and other relevant configuration information.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 249

The host automatically uses the global address prefix obtained from routers and its own in-
terface ID to automatically configure a global address to communicate with other hosts with-
in the Internet.
25.3 NDP
The Neighbor Discovery Protocol (NDP) implements the router discovery function of the Ad-
dress Resolution Protocol (ARP) and the Internet Control Message Protocol (ICMP) as well as
all functions of the redirection protocol in IPv4. It also provides a neighbor unreachability detec-
tion mechanism.
When one IPv6 node appears on the network, the other IPv6 nodes on the link that directly con-
nects with the node can discover the node through the neighbor discovery protocol and can
further obtain its link layer address. IPv6 nodes can also search for routers through the neigh-
bor discovery protocol and maintain the reachability information about the active neighboring
nodes on the path. The neighbor discovery protocol solves the interactions between nodes on
the same link.
The IPv6 NDP provides a group of solutions for solving communication-related problems.
 The NDP supports address resolution, that is, it can resolve the IPv6 address of one IPv6
node interface into the corresponding link layer address.
 The NDP supports router discovery. A host can detect the existence of routers through the
NDP and determine the IDs of the routers willing to forward packets.
 The NDP supports prefix discovery. A router can distribute prefix information through the
NDP to the other connected links.
 The NDP also supports neighbor unreachability detection. A node can determine the bidirec-
tional reachability of peer communication entities through the NDP.
 The NDP also supports Duplicate Address Detection (DAD). The addresses configured on a
node cannot become valid addresses until they pass DAD.
All these functions of the NDP are mostly implemented by NDP packets loaded inside ICMPv6
packets. For this reason, the NDP defines five types of ICMPv6 packets: Router Solicitation (
RS) packets, Router Advertisement (RA) packets, Neighbor Solicitation (NS) packets, Neighbor
Advertisement (NA) packets, and redirection packets.
A router periodically sends RA packets, and may also use them as a response to the RS pack-
ets it has received from hosts. Each RA packet may also contain prefix information, link con-
figuration information and IPv6 protocol parameters. It indicates the existence of routers, and
routers can forward the packet. The RA packet carries the information about the routers. Such
information helps a host to determine where the packet should be sent. The host discovers
available routers through the RA packet and constructs a list of all the discovered routers as the
default router list.
250 SJ-20230719162004-003 | 2023-10-30 (R1.0)

25 IPv6 Features
A host may send an RS packet to inquire router configuration information and router-related in-
formation. A time interval for consecutively sending RA packets has been set on each router.
The interval ranges from several seconds to several minutes. In order to avoid long waiting time
before the configuration information is obtained and the communication starts, the host may in-
tegrate the sending of RS packets as a part of its startup process.
A node can send an NS packet to interpret the link layer address of another node to verify the
reachability of that node and the address uniqueness of a specific link.
A node can send an NA packet as the response to an NS packet. It also sends unsolicited NA
packets to notify its own link layer address changes to other nodes.
When a new address is generated on a node, the node needs to send a neighbor request to
other nodes on the link to enquire whether the address has been used. If the address has been
used, the node using the address responds with an NA packet. If the node where the address is
generated does not receive any response after multiple detections (the number is configurable),
the address becomes valid.
25.4 DHCPv6
DHCPv6 Overview
DHCPv6 is an automatic address allocation protocol defined by IETF on IPv6 networks.

Through DHCPv6, a network node can request IPv6 addresses and some other configuration
parameters from a DHCPv6 server. The network node also can obtain IPv6 addresses through
other methods, and just obtain other network parameters from the DHCPv6 server.
On an IPv6 network, a DHCP client uses a reserved multicast address that is valid on a link to
locate the DHCPv6 server. Therefore, it is required that the client and the server should be on
the same link. However, in some applications, considering management, economy and exten-
sion, it is required that a client can communicate with a server that is not on the same link with
the client. This function is implemented by a DHCPv6 relay. A DHCPv6 relay can relay access
requests from other clients or relays.
Figure 25-3 shows the relationships between DHCPv6 clients, relays and a server.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 251

Figure 25-3 Relation Among DHCPv6 Client, Relay and Server
DHCPv6 Features
Each DHCPv6 client or server has a unique identifier, that is, a DHCP Unique Identifier (DUID
). There are several modes to generate DUIDs. The lengths of DUIDs are different. Not every
message needs to carry a DUID, therefore a DUID is contained in the option information.
Identity Association (IA) is an abstract concept used by DHCPv6 servers and clients to identify,
group and management multiple addresses. A network interface needs at least one IA to man-
age the IPv6 address information obtained on this interface. An IA must be associated with a
unique network interface. Different IAs are identified by IAIDs. The IPv6 address information al-
located by DHCPv6 is contained in IAs. An IA can carry the information about several address-
es.
DHCPv6 uses UDP to transport the protocol packets. The detection port on clients is port 546,
and the detection port on servers and relays is port 547. Clients always use multicast packets
to start interactions. DHCPv6 defines two multicast addresses. One is the multicast address
(FF05::1:3) of all local DHCP servers, and the other is the multicast address (FF02::1:2) of all
servers and relay agents.
DHCPv6 Work Flow
The standard DHCPv6 message types are as follows:

 Solicit message (1): A client uses Solicit messages to locate the position of a server.
 Advertise message (2): A server sends an Advertise message to reply to a Solicit. An Adver-
tise message contains the allocated address and option information.
 Request message (3): A client sends a Request message to a specified server to request an
address and configuration information.
 Confirm message (4): A client sends Confirm messages to any reachable server to check
whether the current IPv6 address it obtained is applicable to the connected links.
252 SJ-20230719162004-003 | 2023-10-30 (R1.0)

25 IPv6 Features
 Renew message (5): A client uses Renew messages to extend the address lease term, and
update other configuration information.
 Rebind message (6): If the renew message is not replied, a client uses a Rebind message
to extend the address lease term, and update other configuration information.
 Reply message (7): A server uses Reply message to respond Request, Renew, Rebind, Re-
lease, Decline and Information-request messages. A Reply message can carry an address
and configuration information. In an exception, a Reply message also can carry the status
code information about an error.
 Release message (8): When a client sends a Release message to a server that allocates an
address for this client, the client does not use the address (or addresses) any longer.
 Decline message (9): When a client sends a Decline message to a server, the address (or
addresses) has (have) been used on a link (or links).
 Reconfigure message (10): A server can send a Reconfigure message to a client to hint the
configuration information that the client can update.
 Information-request message (11): A client sends an Information-request message to a sev-
er to request configuration information without requesting an IP address.
 Relay-forward message (12): A relay agent sends a Relay-forward message to a server to
replay information.
 Relay-replay message (13): A server sends a Relay-replay message carrying the informa-
tion that is to be sent to a client to a rely agent.
Figure 25-4 shows the interaction procedure of DHCPv6 messages in a standard networking
environment.
SJ-20230719162004-003 | 2023-10-30 (R1.0) 253

Figure 25-4 DHCPv6 Protocol Message Interaction
25.5 ICMPv6
Description
ICMPv6 (Internet Control Message Protocol for the Internet Protocol Version 6) is one of the
basic IPv6 protocols. ICMPv6 contains two type of messages: error messages and information
messages, which are used to report the errors and information by IPv6 nodes during the mes-
sages processing.
Figure 25-5 shows the ICMPv6 message format.
254 SJ-20230719162004-003 | 2023-10-30 (R1.0)

25 IPv6 Features
Figure 25-5 ICMPv6 Message Format
The fields of ICMPv6 message are described as follows:

 Type: indicates message type. 0–127 indicate an error message, error type. 128–255 indi-
cate an information message type.
 Code: depends on the message type and provides an additional level of message granulari-
ty.
 Checksum: provides a minimal level of integrity verification for the ICMP message.
ICMPv6 Error Message Types
 Destination Unreachable
When a IPv6 node find an unreachable destination in forwarding IPv6 messages , the node
sends an ICMPv6 Destination Unreachable message with detailed reason to the source
node. Destination Unreachable messages can be divided to the following types:
à No route to destination
à Address unreachable
à Port unreachable
 Packet Too Big
When a IPv6 node find that a message exceeds the link MTU of the egress interface in for-
warding IPv6 messages, the node sends an ICMPv6 Packet Too Big message with the link
MTU value of the egress interface to the source node. Packet Too Big messages are the ba-
sis of Path MTU discovery mechanism.
 Time Exceeded
In the process of receiving and transmitting IPv6 messages, when a device receives a pack-
et whose Hop Limit is 0, or the device decrease the Hop Limit value to 0, the device send an
ICMPv6 Packet Too Big message to the source node. For the segmented messages, when
the time is exceeded, ICMPv6 Time Exceeded messages are generated as well.
 Parameter Problem
When a destination node receive a IPv6 message, it check the validation of the message. If
any of the following problems are encountered, the node sends a ICMPv6 Parameter Prob-
lem message to the source node.
à Erroneous header field encountered
à Unrecognized Next Header type encountered
SJ-20230719162004-003 | 2023-10-30 (R1.0) 255

à Unrecognized IPv6 option encountered
ICMPv6 Information Message Types
ICMPv6 information message includes the two types:

 Echo Request
 Echo Reply
ICMPv6 information message can be used to diagnose network faults, discover Path MTU, and
discover neighbors.
In the connectivity test between two nodes, the node that receives an Echo Request message
send an Echo Reply message to the source port, so that messages can be received and trans-
mitted between the two nodes.
256 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Figures
Figure 1-1 GPON Network....................................................................................... 2
Figure 1-2 Downstream Frame with FEC Codes..................................................... 6
Figure 1-3 Upstream Frame with FEC Codes......................................................... 6
Figure 1-4 GPON ONU Registration and Authentication......................................... 8
Figure 1-5 Queue Scheduling Policy Set by the OLT............................................ 11
Figure 1-6 Signal Transmission Without Ranging.................................................. 12
Figure 1-7 Signal Transmission With Ranging...................................................... 13
Figure 1-8 GPON T-CONT Types......................................................................... 14
Figure 1-9 GPON Service Multiplexing Principle................................................... 14
Figure 1-10 GPON Service Mapping Relationship (Downstream)......................... 15
Figure 1-11 GPON Service Mapping Relationship (Upstream).............................. 16
Figure 1-12 PON AES Encryption......................................................................... 17
Figure 1-13 GPON Type B Protection (An OLT PON Port Is Redundant)............. 18
Figure 1-14 GPON Type C Protection (Whole Protection).................................... 19
Figure 1-15 GPON Inter-OLT Type C Protection................................................... 20
Figure 2-1 XG-PON, GPON and RF Video Wave Length Allocation..................... 26
Figure 2-2 XG-PON DBA....................................................................................... 27
Figure 2-3 XG-PON Ranging................................................................................. 29
Figure 2-4 XG-PON XGEM Frame Structure......................................................... 30
Figure 2-5 XG-PON XGTC Payload Format.......................................................... 31
Figure 3-1 GPON and XG-PON Coexistence Through the Combo PON............... 33
SJ-20230719162004-003 | 2023-10-30 (R1.0) 257

Figure 4-1 XGS-PON Network............................................................................... 36
Figure 4-2 XGS-PON Downstream and Upstream Wave Lengths......................... 38
Figure 4-3 XGS-PON DBA..................................................................................... 40
Figure 4-4 XGS-PON Ranging............................................................................... 41
Figure 4-5 XGS-PON XGEM Frame Structure...................................................... 43
Figure 4-6 XGS-PON XGTC Payload Format....................................................... 43
Figure 5-1 P2P Access Application Scenario........................................................ 45
Figure 5-2 P2P Frequency/Time Synchronization................................................. 46
Figure 6-1 L2 Switch Principle............................................................................... 48
Figure 6-2 Unified ONU and VLAN Configuration................................................. 51
Figure 6-3 Upstream VLAN Reuse........................................................................ 52
Figure 7-1 L3 Interface Principle............................................................................ 60
Figure 7-2 ARP Proxy Application Scenario.......................................................... 62
Figure 7-3 DHCP Application Scenario.................................................................. 64
Figure 7-4 DHCP L3 Relay Principle..................................................................... 66
Figure 7-5 DHCP L2 Relay Principle..................................................................... 67
Figure 7-6 DHCP Option60 Principle..................................................................... 68
Figure 7-7 GRE Encapsulation.............................................................................. 75
Figure 7-8 VRF Architecture.................................................................................. 78
Figure 8-1 OSPF Neighbor State Machine............................................................ 88
Figure 8-2 Establishing an OSPF Neighbor Relation............................................. 89
Figure 8-3 Synchronizing OSPF Link State Databases - 1.................................... 90
Figure 8-4 Synchronizing OSPF Link State Databases - 2.................................... 91
Figure 8-5 Division of OSPF Areas....................................................................... 93
258 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Figure 8-6 Example of a Virtual Link..................................................................... 95
Figure 8-7 Example of a Stub Area....................................................................... 97
Figure 8-8 Example of a Totally Stubby Area........................................................ 98
Figure 8-9 Example of an NSSA........................................................................... 99
Figure 8-10 Example of Route Aggregation........................................................ 101
Figure 8-11 Example of OSPF Route Load Sharing............................................ 102
Figure 8-12 NSAP Address Structure.................................................................. 104
Figure 8-13 Hierarchical Structure of an IS-IS Network....................................... 105
Figure 8-14 Establishing a Neighbor in a Broadcast Link.................................... 108
Figure 8-15 Three-Handshake Mode for a Point-to-Point Link............................ 109
Figure 8-16 DIS Network Structure on Broadcast Network................................. 110
Figure 8-17 Database Synchronization of a Point-to-Point Link.......................... 112
Figure 8-18 Database Synchronization of a Broadcast Link................................ 114
Figure 8-19 Example of Route Leaking............................................................... 115
Figure 8-20 Format of a BGP Message Header.................................................. 117
Figure 8-21 State Transition During BGP Neighbor Establishment..................... 119
Figure 8-22 AS_PATH Attribute........................................................................... 121
Figure 8-23 NEXT_HOP Attribute........................................................................ 122
Figure 8-24 MED Attribute................................................................................... 123
Figure 8-25 LOCAL_PREF Attribute.................................................................... 124
Figure 8-26 BGP Load Sharing........................................................................... 126
Figure 8-27 Synchronization Between IBGP and IGP......................................... 127
Figure 9-1 VXLAN Application Scenario.............................................................. 129
Figure 9-2 VXLAN Message Encapsulation......................................................... 130
SJ-20230719162004-003 | 2023-10-30 (R1.0) 259

Figure 9-3 VXLAN Principle................................................................................. 130
Figure 10-1 EVPN Application Scenario.............................................................. 133
Figure 10-2 EVPN Concepts................................................................................ 133
Figure 11-1 Mapping of a Destination IP Address to a Destination MAC

Address................................................................................................................. 136
Figure 11-2 Multicast and IPTV Service Solution................................................ 138
Figure 12-1 Synchronization Network Clock Architecture.................................... 144
Figure 12-2 Clock-Processing Principle............................................................... 148
Figure 12-3 Synchronous Ethernet Application Scenario.................................... 150
Figure 12-4 TOD Frame Structure....................................................................... 154
Figure 12-5 PTP Message Flow.......................................................................... 155
Figure 12-6 1PPS Relationship Between the OLT and the ONU......................... 156
Figure 13-1 ETH-CCM......................................................................................... 162
Figure 13-2 ETH-RDI........................................................................................... 163
Figure 13-3 ETH-LB............................................................................................. 163
Figure 13-4 ETH-LT............................................................................................. 164
Figure 13-5 ETH-AIS............................................................................................ 165
Figure 16-1 Procedure of a DHCP User Getting Online and Offline.................... 176
Figure 16-2 Principle of Static MAC Binding....................................................... 177
Figure 16-3 Principle of MAC Address Validity Check......................................... 179
Figure 17-1 RADIUS Network Structure.............................................................. 181
Figure 17-2 TACACS+ Networking Structure...................................................... 183
Figure 17-3 TACACS+ Packets Interaction......................................................... 184
Figure 17-4 DHCP Snooping Typical Application................................................ 185
260 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Figure 17-5 DHCP Message Interaction.............................................................. 186
Figure 17-6 PPPoE+ Interaction Procedures....................................................... 187
Figure 17-7 PPPoE+ Option Format.................................................................... 188
Figure 17-8 DHCP Option 82 Interaction Procedures.......................................... 189
Figure 17-9 DHCP Option 82 Format.................................................................. 189
Figure 17-10 DHCP Option 82 Sub-Options Format........................................... 189
Figure 18-1 Scenario Where BFD Triggers a Fast ECMP Switchover................. 195
Figure 18-2 VPWS/PWE3 FRR + TE/LDP FRR Application Scenario................. 197
Figure 18-3 Scenario Where IP FRR Supports WTR.......................................... 197
Figure 18-4 Scenario Where a CE Belongs to Dual PEs..................................... 198
Figure 18-5 Multi-Point Fault Network Solution................................................... 200
Figure 18-6 OAM Mapping and Linkage Principle............................................... 201
Figure 19-1 NETCONF Protocol Layers.............................................................. 202
Figure 19-2 NETCONF Principle......................................................................... 203
Figure 20-1 OLT Forwarding and Control Plane Architecture.............................. 204
Figure 20-2 ISSU Mechanism—Control Card...................................................... 205
Figure 20-3 ISSU Mechanism—Line Card........................................................... 206
Figure 22-1 Watchdog Monitoring for Linux Kernel Boot..................................... 210
Figure 22-2 Watchdog Detection For Kernel Running......................................... 210
Figure 22-3 Temperature Monitoring................................................................... 213
Figure 22-4 Heartbeat Detection for Board Management.................................... 215
Figure 22-5 Dual Boot.......................................................................................... 216
Figure 22-6 Roll-Back From Upgrading Failure................................................... 217
Figure 23-1 MPLS Working Principle................................................................... 222
SJ-20230719162004-003 | 2023-10-30 (R1.0) 261

Figure 23-2 MPLS Implementation Principle....................................................... 223
Figure 23-3 VPLS Working Principle................................................................... 225
Figure 23-4 VPWS Working Principle.................................................................. 226
Figure 24-1 Downstream H-QoS Scheduling....................................................... 231
Figure 24-2 Downstream Traffic Flow and Congestion........................................ 231
Figure 24-3 Upstream Traffic Flow and Congestion............................................ 234
Figure 25-1 IPv4 Header Format......................................................................... 238
Figure 25-2 IPv6 Header Format......................................................................... 238
Figure 25-3 Relation Among DHCPv6 Client, Relay and Server......................... 252
Figure 25-4 DHCPv6 Protocol Message Interaction............................................ 254
Figure 25-5 ICMPv6 Message Format................................................................. 255
262 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Tables
Table 1-1 Optical Power Standard and Optical Mode Class of GPON OLT and
ONU.......................................................................................................................... 5
Table 1-2 Optical Power Budget of Combined GPON Optical Modules................... 5
Table 2-1 XG-PON and GPON.............................................................................. 24
Table 2-2 XG-PON Optical Power Budget level.................................................... 25
Table 2-3 XG-PON ODN Physical Parameters...................................................... 26
Table 4-1 XGS-PON, XG-PON and GPON........................................................... 36
Table 4-2 XGS-PON Optical Power Budget level.................................................. 38
Table 4-3 XGS-PON ODN Physical Parameters................................................... 39
Table 7-1 Routing Table Entry Descriptions.......................................................... 70
Table 7-2 Routing Source Descriptions................................................................. 71
Table 7-3 Default Administrative Distances of Different Routing Sources............. 72
Table 7-4 Path Characteristics Descriptions.......................................................... 73
Table 8-1 General Format of an OSPF Packet..................................................... 82
Table 8-2 Neighbor State Changes in Three-handshake Mode........................... 110
Table 8-3 Route Attributes and Types................................................................. 120
Table 10-1 EVPN Concept Descriptions.............................................................. 133
Table 11-1 IGMP/MLD Protocol Parameter Descriptions.................................... 139
Table 12-1 Clock Synchronization Application Scenario...................................... 146
Table 12-2 Time Synchronization Application Scenarios..................................... 153
Table 16-1 Methods of Resolving MAC Address Security Problems................... 175
Table 24-1 T-CONT Type.................................................................................... 234
SJ-20230719162004-003 | 2023-10-30 (R1.0) 263

Table 25-1 IPv6 Address Space.......................................................................... 239
Table 25-2 Aggregatable Global Unicast Address Fields.................................... 241
Table 25-3 Structure of the IPv6 Address Embedded With IPv4 Address........... 243
Table 25-4 Structures of Link-local Address and Site-local Address................... 243
Table 25-5 Multicast Address Format.................................................................. 244
Table 25-6 Multicast Scope Values..................................................................... 245
Table 25-7 IPv6 Address Compression............................................................... 247
264 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Glossary
1PPS
- 1 Pulse Per Second
AAA
- Authentication, Authorization and Accounting
ABR
- Area Border Router
ACL
- Access Control List
ACR
- Adaptive Clock Recovery
AES
- Advanced Encryption Standard
AIS
- Alarm Indication Signal
ARP
- Address Resolution Protocol
AS
- Autonomous System
ASBR
- Autonomous System Boundary Router
ASM
- Any-Source Multicast
ATM
- Asynchronous Transfer Mode
SJ-20230719162004-003 | 2023-10-30 (R1.0) 265

BC
- Boundary Clock
BDR
- Backup Designate Router
BGP
- Border Gateway Protocol
BITS
- Building Integrated Timing Supply
BNG
- Broadband Network Gateway
BOOTP
- Bootstrap Protocol
BOSS
- Business and Operation Support System
BSC
- Base Station Controller
BTS
- Base Transceiver Station
CBS
- Committed Burst Size
CCM
- Continuity Check Message
CDN
- Contents Distribution Network
CES
- Circuit Emulation Service
266 SJ-20230719162004-003 | 2023-10-30 (R1.0)

CFM
- Connectivity Fault Management
CHAP
- Challenge Handshake Authentication Protocol
CIDR
- Classless Inter-Domain Routing
CIR
- Committed Information Rate
CLNS
- ConnectionLess Network Service
CPU
- Central Processing Unit
CoS
- Class of Service
DBA
- Dynamic Bandwidth Allocation
DBD
- Database Descriptor
DHCP
- Dynamic Host Configuration Protocol
DIS
- Designate IS
DNS
- Domain Name System
DPU
- Distribution Point Unit
SJ-20230719162004-003 | 2023-10-30 (R1.0) 267

DR
- Designated Router
DSCP
- Differentiated Services Code Point
DUID
- DHCP Unique Identifier
DVMRP
- Distance Vector Multicast Routing Protocol
DWRR
- Deficit Weighted Round Robin
DoS
- Denial of Service
EBGP
- External Border Gateway Protocol
ECMP
- Equal-Cost Multi-Path routing
EEC
- Ethernet Equipment Clock
EFM
- Ethernet in the First Mile
EGP
- External Gateway Protocol
EIR
- Excess Information Rate
EMS
- Element Management System
268 SJ-20230719162004-003 | 2023-10-30 (R1.0)

EPON
- Ethernet Passive Optical Network
ESMC
- Ethernet Synchronization Message Channel
EVPN
- Ethernet VPN
FDDI
- Fiber Distributed Data Interface
FEC
- Forward Error Correction
FIB
- Forwarding Information Base
FRR
- Fast Reroute
FTP
- File Transfer Protocol
FTTB
- Fiber to the Building
FTTC
- Fiber to the Curb
FTTH
- Fiber to the Home
FTTM
- Fiber to the Mobile
FTTO
- Fiber to the Office
SJ-20230719162004-003 | 2023-10-30 (R1.0) 269

GEM
- GPON Encapsulation Method
GLONASS
- Global Navigation Satellite System
GMII
- Gigabit Medium Independent Interfac
GPON
- Gigabit Passive Optical Network
GPS
- Global Positioning System
GR
- Graceful Restart
GRE
- General Routing Encapsulation
H-QoS
- Hierarchical-QoS
HDLC
- High-level Data Link Control
HGU
- Home Gateway Unit
IA
- Identity Association
IBGP
- Interior Border Gateway Protocol
ICMP
- Internet Control Message Protocol
270 SJ-20230719162004-003 | 2023-10-30 (R1.0)

ICMPv6
- Internet Control Message Protocol for IPv6
ID
- Identifier
IEEE
- Institute of Electrical and Electronics Engineers
IETF
- Internet Engineering Task Force
IGMP
- Internet Group Management Protocol
IGMP
- Internet Group Management Protocol
IGP
- Interior Gateway Protocol
IGRP
- Interior Gateway Routing Protocol
IMS
- IP Multimedia Subsystem
IP
- Internet Protocol
IPSec
- IP Security Protocol
IPTV
- Internet Protocol Television
IPX
- Internetwork Packet Exchange protocol
SJ-20230719162004-003 | 2023-10-30 (R1.0) 271

IPv4
- Internet Protocol Version 4
IPv6
- Internet Protocol Version 6
IS-IS
- Intermediate System-to-Intermediate System
ISO
- International Organization for Standardization
ISP
- Internet Service Provider
ITU
- International Telecommunications Union
L2
- Layer 2
L3
- Layer 3
LACP
- Link Aggregation Control Protocol
LB
- Loopback
LBM
- Loopback Message
LBR
- Loopback Reply
LLID
- Logical Link Identifier
272 SJ-20230719162004-003 | 2023-10-30 (R1.0)

LPR
- Local Primary Reference
LSA
- Link State Advertisement
LSB
- Least Significant Bit
LSDB
- Link-state Database
LSP
- Label Switched Path
LSP
- Link State Packet
LSR
- Label Switch Router
LSU
- Link State Update
LT
- Link Trace
LTE
- Long Term Evolution
LTM
- Link Trace Message
LTR
- Link Trace Reply
MAC
- Media Access Control
SJ-20230719162004-003 | 2023-10-30 (R1.0) 273

MBGP
- Multiprotocol Border Gateway Protocol
MDI
- Medium Dependent Interface
MDU
- Multiple Dwelling Unit
ME
- Maintenance Entity
MED
- MULTI_EXIT_DISC
MEG
- Maintenance Entity Group
MEP
- MEG End Point
MEP
- Maintenance association End Point
MFF
- MAC-Forced Forwarding
MIP
- MEG Intermediate Point
MIP
- Maintenance Association Intermediate Point
MLD
- Multicast Listener Discovery
MOSPF
- Multicast Open Shortest Path First
274 SJ-20230719162004-003 | 2023-10-30 (R1.0)

MP
- Maintenance Point
MPCP
- Multi-Point Control Protocol
MPLS
- Multiprotocol Label Switching
MPU
- Management Process Unit
MSDP
- Multicast Source Discovery Protocol
MTU
- Maximum Transfer Unit
MTU
- Multi-Tenant Unit
MVLAN
- Multicast Virtual Local Area Network
NA
- Neighbor Advertisement
NBMA
- Non-Broadcast Multiple Access
NDP
- Neighbor Discovery Protocol
NMS
- Network Management System
NRZ
- Non-Return to Zero
SJ-20230719162004-003 | 2023-10-30 (R1.0) 275

NS
- Neighbor Solicitation
NSAP
- Network Service Access Point
NSR
- Non-Stop Routing
NSSA
- Not-So-Stubby Area
NTP
- Network Time Protocol
OAM
- Operation, Administration and Maintenance
ODF
- Optical Distribution Frame
ODN
- Optical Distribution Network
OLT
- Optical Line Terminal
OMCI
- ONT Management Control Interface
ONT
- Optical Network Terminal
ONU
- Optical Network Unit
OSI
- Open System Interconnection
276 SJ-20230719162004-003 | 2023-10-30 (R1.0)

OSPF
- Open Shortest Path First
OTDR
- Optical Time Domain Reflectometer
P2P
- Point to Point
PAP
- Password Authentication Protocol
PBS
- Peak Burst Size
PCS
- Physical Coding Sublayer
PDU
- Protocol Data Unit
PIM-DM
- Protocol Independent Multicast - Dense Mode
PIM-SM
- Protocol Independent Multicast - Sparse Mode
PIM
- Protocol Independent Multicast
PIR
- Peak Information Rate
PLOAM
- Physical Layer Operations, Administration and Maintenance
PMA
- Physical Medium Attachment
SJ-20230719162004-003 | 2023-10-30 (R1.0) 277

PMD
- Physical Medium Dependent
PON
- Passive Optical Network
POP
- Policy Operation Platform
PPP
- Point to Point Protocol
PPPoE
- Point to Point Protocol over Ethernet
PRC
- Primary Reference Clock
PRS
- Primary Reference Source
PTN
- Packet Transport Network
PTP
- Precision Time Protocol
PVID
- Port VLAN ID
QoS
- Quality of Service
RA
- Router Advertisement
RADIUS
- Remote Authentication Dial In User Service
278 SJ-20230719162004-003 | 2023-10-30 (R1.0)

RAN
- Radio Access Network
RDI
- Remote Defect Indication
RF
- Radio Frequency
RFC
- Request For Comments
RIB
- Routing Information Base
RIP
- Routing Information Protocol
RMEP
- Remote Maintenance association End Point
RNC
- Radio Network Controller
RS
- Reed Solomon
RS
- Router Solicitation
RTD
- Round Trip Delay
RTT
- Round Trip Time
SBU
- Single Business Unit
SJ-20230719162004-003 | 2023-10-30 (R1.0) 279

SEC
- SDH Equipment Clock
SFTP
- Secure File Transfer Protocol
SFU
- Single Family Unit
SMS
- Service Management System
SNMP
- Simple Network Management Protocol
SP
- Service Provider
SP
- Strict Priority
SPF
- Shortest Path First
SS
- Soft Switch
SSM
- Synchronization Status Message
SSM
- Source Specific Multicast
SSU
- Synchronization Supply Unit
TACACS+
- Terminal Access Controller Access-Control System Plus
280 SJ-20230719162004-003 | 2023-10-30 (R1.0)

TCP/IP
- Transmission Control Protocol/Internet Protocol
TCP
- Transmission Control Protocol
TDM
- Time Division Multiplexing
TDMA
- Time Division Multiple Access
TOD
- Time of Day
TPID
- Tag Protocol Identifier
TTL
- Time To Live
UDP
- User Datagram Protocol
UNI
- User Network Interface
UTC
- Universal Time Coordinated
VCI
- Virtual Channel Identifier
VLAN
- Virtual Local Area Network
VNI
- Visited Network Identity
SJ-20230719162004-003 | 2023-10-30 (R1.0) 281

VOD
- Video On Demand
VPI
- Virtual Path Identifier
VXLAN
- Virtual eXtensible LAN
VoIP
- Voice over Internet Protocol
WDM
- Wavelength Division Multiplexing
WTR
- Wait to Restore Time
XG-PON
- 10-Gigabit-Capable Passive Optical Network
XGS-PON
- 10-Gigabit-Capable Symmetric Passive Optical Network
282 SJ-20230719162004-003 | 2023-10-30 (R1.0)

ZXA10 C600&C650&C620 (V2.0.10) Optical Access Convergence Equipment Feature Description

Uploaded by

Copyright:

Available Formats

ZXA10 C600&C650&C620 (V2.0.10) Optical Access Convergence Equipment Feature Description

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ZXA10 C600&C650&C620 (V2.0.10) Optical Access Convergence Equipment Feature Description

Uploaded by

Copyright:

Available Formats

ZXA10 C600/C650/C620

Optical Access Convergence Equipment

tractual confidentiality obligations.

CORPORATION or of their respective owners.

use of or reliance on the information contained herein.

The ultimate right to interpret this product resides in ZTE CORPORATION.

Statement on the Use of Third-Party Embedded Software:

Revision No. Revision Date Revision Reason

Serial Number: SJ-20230719162004-003

Publishing Date: 2023-10-30 (R1.0)

1 GPON Access Features.........................................................................................1

This manual describes the features of the ZXA10 C600/C650/C620.

This manual is intended for:

What Is in This Manual

This manual contains the following chapters.

Chapter 6, L2 Features Describes the L2 features of ZXA10 C600/C650/C620

Chapter 7, IPv4 L3 Features Describes the IPv4 L3 features of ZXA10 C600/C650/

Chapter 9, VXLAN Feature Describes the VXLAN feature of ZXA10 C600/C650/

Chapter 12, Synchronization Features Describes the synchronization features of ZXA10

Chapter 21, Energy-Saving Features Describes the energy-saving features of ZXA10

This manual uses the following conventions.

Note: provides additional information about a topic.

1.1 GPON Physical Characteristic

SJ-20230719162004-003 | 2023-10-30 (R1.0) 1

Figure 1-1 GPON Network

BSC: Base Station Controller RNC: Radio Network Controller

SFU: Single Family Unit HGU: Home Gateway Unit

SBU: Single Business Unit DPU: Distribution Point Unit

OTT: Over The Top BTS: Base Transceiver Station

SS: Soft Switch IMS: IP Multimedia Subsystem

MDU: Multiple Dwelling Unit MTU: Maximum Transmission Unit

2 SJ-20230719162004-003 | 2023-10-30 (R1.0)

SJ-20230719162004-003 | 2023-10-30 (R1.0) 3

 ITU-T G.984.1: general characteristics

1.2 GPON Optical Layer Features

4 SJ-20230719162004-003 | 2023-10-30 (R1.0)

Mode Transmit Optical Worst Down- Transmit Optical Worst Upstream

(dBm) Cost (dB) (dBm)

B+ 1.5 5 –28 0.5 0.5 5 –27 0.5

C+ 3 7 –32 1 0.5 5 –30 0.5

Table 1-2 Optical Power Budget of Combined GPON Optical Modules

Module downstream upstream downstream upstream

B+/B+ 28.5 28.5 28 28

SJ-20230719162004-003 | 2023-10-30 (R1.0) 5

 Enables/Disables the FEC function of a single PON port.

Figure 1-2 Downstream Frame with FEC Codes

Figure 1-3 shows an upstream frame with FEC codes.

Figure 1-3 Upstream Frame with FEC Codes

1.3 GPON ONU Authentication and Registration

6 SJ-20230719162004-003 | 2023-10-30 (R1.0)

 Supports the registration mode based on the ONU password.

This feature is used to access and control the ONU.

SJ-20230719162004-003 | 2023-10-30 (R1.0) 7

Figure 1-4 GPON ONU Registration and Authentication

The registration and authentication process is as follows:

8 SJ-20230719162004-003 | 2023-10-30 (R1.0)

SJ-20230719162004-003 | 2023-10-30 (R1.0) 9

1.4 GPON DBA Features

This feature is used to dynamically allocate the GPON upstream bandwidth.

10 SJ-20230719162004-003 | 2023-10-30 (R1.0)