NE40E X1&NE40E X2 Feature Description Basic Configurations (V600R005C00 - 03)

HUAWEI NE40E-X1/NE40E-X2 Universal Service
Router
V600R005C00
Feature Description - Basic

Configurations
Issue
03
Date
2013-08-15
HUAWEI TECHNOLOGIES CO., LTD.
Copyright Huawei Technologies Co., Ltd. 2013. All rights reserved.

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

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or representations
of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address:
Huawei Industrial Base

Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website:
http://www.huawei.com
Email:
support@huawei.com
Issue 03 (2013-08-15)
Huawei Proprietary and Confidential

Copyright Huawei Technologies Co., Ltd.
HUAWEI NE40E-X1/NE40E-X2 Universal Service Router

Feature Description - Basic Configurations
About This Document
About This Document

Purpose
This document describes the basic configurations in terms of its overview, principles, and
applications.
This document together with other types of documents helps intended readers get a deep
understanding of the basic configurations.
CAUTION
Note the following precautions:
l Currently, the device supports the AES and SHA2 encryption algorithms. AES is reversible,
while SHA2 is irreversible. A protocol interworking password must be reversible, and a local
administrator password must be irreversible.
l If the plain parameter is specified, the password will be saved in plaintext in the configuration
file, which has a high security risk. Therefore, specifying the cipher parameter is
recommended. To further improve device security, periodically change the password.
l Do not set both the start and end characters of a password to "%$%$." This causes the
password to be displayed directly in the configuration file.
Related Versions
The following table lists the product versions related to this document.
Product Name
Version
HUAWEI NE40E-X1 &

NE40E-X2 Universal Service
Router
V600R005C00
Intended Audience
This document is intended for:
Issue 03 (2013-08-15)

ii

Network planning engineers
Commissioning engineers
Data configuration engineers
System maintenance engineers
About This Document
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol
Description
DANGER
DANGER indicates a hazard with a high level or medium

level of risk which, if not avoided, could result in death or
serious injury.
WARNING
WARNING indicates a hazard with a low level of risk

which, if not avoided, could result in minor or moderate
injury.
CAUTION
CAUTION indicates a potentially hazardous situation

that, if not avoided, could result in equipment damage, data
loss, performance deterioration, or unanticipated results.
TIP
TIP indicates a tip that may help you solve a problem or

save time.
NOTE
NOTE provides additional information to emphasize or

supplement important points of the main text.
Change History
Changes between document issues are cumulative. The latest document issue contains all the
changes made in earlier issues.
Changes in Issue 03 (2013-08-15)

The third commercial release.

The second commercial release.

Initial field trial release. Compared with V600R005C00SPC700, this document has the
following updates:
Issue 03 (2013-08-15)

iii

Issue 03 (2013-08-15)
About This Document
Section
Section
Description
Dynamic Module Load
1.4.12 Dynamic Module

Load
Added dynamic module

loading

iv

Contents
Contents
About This Document.....................................................................................................................ii
1 Basic Configuration.......................................................................................................................1
1.1 Introduction to Basic Configuration...............................................................................................................................2
1.2 References......................................................................................................................................................................2
1.3 Feature Enhancements....................................................................................................................................................4
1.4 Principles........................................................................................................................................................................4
1.4.1 FTP..............................................................................................................................................................................4
1.4.2 TFTP............................................................................................................................................................................9
1.4.3 Introduction to Telnet................................................................................................................................................10
1.4.4 SSH............................................................................................................................................................................16
1.4.5 User Management......................................................................................................................................................22
1.4.6 Virtual File System....................................................................................................................................................25
1.4.7 Pipe Character............................................................................................................................................................27
1.4.8 Daylight Saving Time................................................................................................................................................27
1.4.9 Timing Restart...........................................................................................................................................................28
1.4.10 MIB Interface Is Used to Optimize System Upgrade..............................................................................................28
1.4.11 NAP.........................................................................................................................................................................29
1.4.12 Dynamic Module Load............................................................................................................................................32
1.5 Applications..................................................................................................................................................................33
1.5.1 Applications of FTP...................................................................................................................................................33
1.5.2 Applications of TFTP................................................................................................................................................34
1.5.3 Applications of Telnet...............................................................................................................................................34
1.5.4 Applications of SSH..................................................................................................................................................35
1.6 Terms, Acronyms, and Abbreviations..........................................................................................................................38
2 Fast Startup...................................................................................................................................40
2.1 Introduction to Fast Startup..........................................................................................................................................41
2.2 References....................................................................................................................................................................41
2.3 Principles......................................................................................................................................................................41
2.3.1 Fast Startup After a Software Fault...........................................................................................................................42
2.3.2 Fast Startup After a Hardware Fault..........................................................................................................................42
2.3.3 Upgrade and Cold Startup.........................................................................................................................................42
2.3.4 Performance Statistics for Software-based Fast Startup............................................................................................42
Issue 03 (2013-08-15)


Contents
2.4 Applications..................................................................................................................................................................42
3 Clock Synchronization...............................................................................................................43
3.1 Introduction..................................................................................................................................................................44
3.2 References....................................................................................................................................................................44
3.3 Principles......................................................................................................................................................................44
3.3.1 Basic Concepts..........................................................................................................................................................44
3.3.2 Clock Protection Switching.......................................................................................................................................47
3.3.3 Synchronization Mode and Issues of Concern..........................................................................................................49
3.3.4 Networking Mode for Clock Synchronization..........................................................................................................51
3.4 Application...................................................................................................................................................................52
4 1588 ACR.......................................................................................................................................56
4.1 Introduction to 1588 ACR............................................................................................................................................57
4.2 References....................................................................................................................................................................57
4.3 Enhancement................................................................................................................................................................58
4.4 Principles......................................................................................................................................................................58
4.4.1 Basic Principles of 1588 ACR...................................................................................................................................58
4.5 Applications..................................................................................................................................................................61
4.6 Terms and Abbreviations..............................................................................................................................................62
5 1588v2.............................................................................................................................................63
5.1 Introduction to 1588v2.................................................................................................................................................64
5.2 References....................................................................................................................................................................66
5.3 Principles......................................................................................................................................................................67
5.3.1 Basic Concepts..........................................................................................................................................................67
5.3.2 Principle of Synchronization.....................................................................................................................................70
5.4 Application Environment.............................................................................................................................................80
6 CES ACR Clock Synchronization.............................................................................................87

6.1 Introduction..................................................................................................................................................................88
6.2 References....................................................................................................................................................................88
6.3 Principles......................................................................................................................................................................88
6.3.1 Basic Concepts..........................................................................................................................................................88
6.3.2 Basic Principles.........................................................................................................................................................89
6.4 Applications..................................................................................................................................................................89
7 Plug-and-Play...............................................................................................................................91
7.1 Introduction to Plug-and-Play......................................................................................................................................92
7.2 References....................................................................................................................................................................92
Issue 03 (2013-08-15)

vi

Contents
7.3 Principles......................................................................................................................................................................92
7.3.1 Principle of DHCP.....................................................................................................................................................92
7.3.2 Operation Principle of a DHCP Client......................................................................................................................93
7.3.3 Basic Principles of DHCP.........................................................................................................................................94
7.3.4 Operation Process of PnP........................................................................................................................................101
7.4 Applications................................................................................................................................................................102
7.5 Terms, Acronyms, and Abbreviations........................................................................................................................103
Issue 03 (2013-08-15)

vii

1 Basic Configuration
Basic Configuration
About This Chapter

1.1 Introduction to Basic Configuration
1.2 References
1.3 Feature Enhancements
1.4 Principles
1.5 Applications
1.6 Terms, Acronyms, and Abbreviations
Issue 03 (2013-08-15)


1.1 Introduction to Basic Configuration

Definition
In configuration management, the terminal service provides the access interface and humanmachine interfaces (HMIs) for users to configure devices.
The login mode includes:
l
Login through the console port
Remote login through the AUX port
Telnet server/client
Login through Secure Shell (SSH), with a password, with Revest-Shamir-Adleman

Algorithm (RSA) authentication, and with the Digital Signature Algorithm (DSA)
Login through customized user interfaces providing multiple user authentications and
authorization modes
The file transfer mode provides transmission control for system files and configuration files,
and simple remote management for the file system.
The file transfer mode includes:
l
FTP client/server
TFTP client
SSH FTP (SFTP) client/server
The following describes the principles of every protocol feature according to the type, including
the following parts:
l
FTP
TFTP
Telnet
SSH
User management
Virtual file system
Daylight saving time
Timing restart
Purpose
The terminal service provides the access interface and HMIs for users to configure devices. File
transfer provides transmission control for system files and configuration files, and simple remote
management for the file system.
1.2 References
The following table lists the references.
Issue 03 (2013-08-15)


Issue 03 (2013-08-15)
Document
No.
Document Name
Remarks
RFC 775
Directory oriented FTP commands
RFC 959
File Transfer Protocol
RFC 1635
How to Use Anonymous FTP
RFC 1350
The TFTP Protocol (Revision 2)
RFC 698
Telnet Extended ASCII Option
RFC 775
Directory oriented FTP commands
RFC 854
Telnet Protocol Specification
RFC 855
Telnet Option Specification
RFC 930
Telnet Terminal Type Option
RFC 1091
Telnet Terminal-Type Option
RFC 2119
Key words for use in RFCs to Indicate

Requirement Levels
RFC 4250
The Secure Shell (SSH) Protocol

Assigned Numbers
RFC 4251
The Secure Shell (SSH) Protocol

Architecture
RFC 4252
The Secure Shell (SSH)

Authentication Protocol
RFC 4253
The Secure Shell (SSH) Transport

Layer Protocol
This protocol supports neither

compression nor the ssh-dss public
key format.
RFC 4254
The Secure Shell (SSH) Connection

Protocol
This protocol does not support some

packets and functions, such as NP-3
forwarding, Env channel request
packets, xon-xoff channel request
packets, signal channel request
packets, exit-status channel request
packets, exit-signal channel request
packets, and port forwarding.
RFC 4344
The Secure Shell (SSH) Transport

Layer Encryption Modes
RFC 4345
Improved Arcfour Modes for the

Secure Shell (SSH) Transport Layer


Document
No.
Document Name
Remarks
draft-ietfsecshpublickeysubsystem-0
1
Authentication Mechanism that Is

Based on Public Keys
1.3 Feature Enhancements

Version
Feature Enhancement
V600R005C00SPC700
l Now supports SSL.

l Now supports FTPS in SSL.
l Now supports HTTPS inSSL.
l New supports DSA.
l When users access a device, they must be
authenticated.
V600R005C00SPC900
New supports dynamic module loading.
1.4 Principles
1.4.1 FTP
As a protocol in the TCP/IP protocol suite, the File Transfer Protocol (FTP), running at the
application layer, is used for transferring files between local and remote hosts over the Internet.
FTP, which is implemented based on the file system, has been widely used during version
upgrade, log downloading and configuration saving.
FTP is built on the client-server architecture, as shown in Figure 1-1.
Figure 1-1 FTP client/server architecture
IP Network
Server
Client
The NE40E provides the following FTP functions:

Issue 03 (2013-08-15)


FTP server: indicates that the router functions as an FTP server to which users can log in
to access files by running the FTP client program.
FTP client: indicates that the router functions as an FTP client that can access files saved
on a remote server. After running the terminal emulation program or using the Telnet
program on a PC to set up a connection to the router, a user can set up a connection to a
remote FTP server by using the FTP commands and access files saved on the remote server.
In addition to file transfer, FTP supports interactive access, format specifications, and
authentication control.
FTP provides common file operation s to help users perform simple management over the file
system as well as supporting file transfer between hosts. Users can use a PC running the FTP
client program to upload files, download files, and access file directories on the router that
functions as an FTP server, or, use the FTP client program on the router that functions as an FTP
client to transfer files to an FTP server.
At present, an FTP client can access the IPv6 address of an FTP server, and an FTP server
supports IPv6 connections.
Basic Concepts of FTP

Before using FTP, familiarize yourself with the following basic concepts about file transfer:
l
File type
ASCII mode is used for text. Data is converted from the sender's character representation
to "8-bit ASCII" before transmission, and to the receiver's character representation.
Extended Binary-Coded Decimal Interchange Code (EBCDIC) mode requires that both
ends use the EBCDIC character set.
Binary mode requires that the sender sends each file byte for byte. This mode is often
used to transfer image files and program files.
Local mode allows two hosts using different file systems to send files in binary bit
streams. The bit stream of each byte is defined by the sender.
NOTE
The NE40E supports the ASCII and binary modes. Differences between these two modes are as
follows:
l ASCII characters are used to separate carriage returns from line feeds.
l Binary characters can be transferred without format converting.
The client can select an FTP transmission mode, but by default the ASCII mode is used. The client
can use a mode switch command to switch between the two modes.
File structure
Byte stream structure is also called the file structure. A file is considered as a continuous
byte stream.
Record structure is used only for text files in either ASCII or EBCDIC mode.
Page structure files are transferred page for page with the pages numbered so the receiver
can save them without worrying about the pages being out of order.
NOTE
The NE40E supports both the record structure and the byte stream structure.
l
Issue 03 (2013-08-15)
Transfer mode

Stream mode
Data is sent as a continuous stream. For the file structure, the sender sends an End-OfFile (EOF) indicator at the end of file transfer to prompts the receiver to close the data
connection. For the record structure, a two-byte sequence number is used to indicate
the end of the record and file.
Block mode
FTP breaks a file into several blocks and each block starts with a block header.
Compressed mode
FTP compresses the bytes that are the same and consecutively sent.
NOTE
The NE40E supports the stream mode.
port command
The port command enables an interface. The command format is port a,b,c,d,e,f. a,b,c,d
specifies the IP address of an interface, in dotted decimal notation; e,f, which consists of
two decimal numbers, specifies the interface number calculated based on the formula of
e x 256 + f. For example:
ftp> debug
Debugging On .
ftp> ls
---> PORT 10,164,9,96,5,28
Here, 10.164.9.96 is an IP address; the values 5 and 28 are used to calculate the interface
number 1308 (5 x 256 + 28 = 1308).
FTP Connections
Figure 1-2 shows the process of file transfer through FTP.
Figure 1-2 File transfer through FTP
User
User Interface
User Protocol
Interpreter
File
System
User Data
Transfer
Function
Control
Connection Server Protocol
Interpreter
Data
Connection
Server Data
Transfer
Function
Client
File
System
Server
FTP uses two TCP connections to transfer files. They are:

Issue 03 (2013-08-15)


Control connection
A control connection is set up between the FTP client and the FTP server. The server enables
common port 21 and then waits for a connection request from the client; the client enables
common port 21 and then sends a request for setting up a connection to the server.
A control connection always waits for communication between the client and the server,
transmits related commands from the client to the server, and then responses from the server
to the client.
Data connection
The server uses port 20 for data connections. Generally, the server can either open or close
a data connection actively. For files sent from the client to the server in the form of streams,
however, only the client can close a data connection.
FTP transfers each file in streams, using an EOF indicator to identify the end of a file.
Therefore, a new data connection is required for each file or directory list to be transferred.
When a file is being transferred between the client and the server, it indicates that a data
connection is set up.
FTP
In the current system, FTP manages the control connection by using User Protocol Interpretation
(User-PI) and Server Protocol Interpretation (Server-PI) and transfers files by using the User
Data Transport Process (User-DTP) and Server Data Transport Process (Server-DTP).
l
FTP client
The FTP User Interface (UI) provides an interactive command line interface (CLI) for users,
which receives and interprets command lines input by users and offers help information.
After receiving a command on the UI, FTP triggers User-PI to convert the command into
a standard FTP command, and then manages the control connection to the FTP client.
After a login command is input, User-PI creates a control connection between the client
and the server.
After a directory operation command is input, User-PI sends and receives control data
between the client and the server.
After a file transfer command is input, User-PI enables User-DTP to transfer files
between the client and the server. User-DTP is responsible for creating a data connection
to the FTP server for data exchange. The data connection is temporarily set up. That is,
a data connection is set up when files or directory lists need to be transferred and
disconnected when the transfer process is complete or a disconnection request is
received.
FTP server
Server-PI listens to FTP standard port 21 to wait for connection requests from the FTP
client. After receiving a login connection request from the FTP client, the FTP server
handles the request and sends a reply.
After a login command is received, the login authentication process is triggered. If the
login authentication succeeds, a control connection to the FTP client is set up.
After files are received, Server-DTP and User-DTP are triggered to create a data
connection to transfer files.
Server-DTP supports both active and passive data connection requests. By default, ServerDTP is in the active state.
Issue 03 (2013-08-15)


When Server-DTP is transferring data, a user can forcibly disconnect the connection. Upon
receiving a disconnection request, Server-DTP stops transferring data and disconnects the
connection. Normally, a data connection is automatically disconnected when file transfer
is complete.
Process of Setting Up an FTP Connection

The process of setting up an FTP data connection by using active mode is as follows:
1.
The server enables port 21 to wait for a connection request from the client.
2.
The client sends a connection request to the server.
3.
After the request is received, a control connection is set up between the temporary port on
the client and port 21 on the server.
4.
The client sends a command for setting up a data connection to the server.
5.
The client chooses a temporary port for the data connection and sends the port number by
using the port command to the server over the control connection.
6.
The server sends a request to the client for setting up a data connection to the temporary
port on the client.
7.
After the request is received by the client, the data connection between the temporary port
on the client and port 20 on the server is set up.
The process of setting up an FTP data connection by using passive mode is as follows:
1.
The server enables port 21 to wait for a connection request from the client.
2.
The client sends a connection request to the server.
3.
After the request is received, a control connection is set up between the temporary port on
the client and port 21 on the server.
4.
The client sends a command for setting up a data connection to the server.
5.
The client sends a command string PASV to the server to request the port number.
6.
The server chooses a temporary port for the data connection and sends the port number to
the client over the control connection.
7.
The server sends a request to the client for setting up a data connection.
8.
The data connection between the temporary port on the client and the temporary port for
the data connection on the server is set up.
Figure 1-3 Process of setting up an FTP connection

Port 2345
PORT 10,168,2,45,9,42->
Port 2346
<-Port 2346
FTP Client
10.168.2.45/32
Issue 03 (2013-08-15)
Port 21
Port 20
FTP Server


Figure 1-3 shows the process of setting up an FTP connection, assuming that the number of the
temporary port for the control connection is 2345 and the number of the temporary port for the
data connection is 2346.
1.4.2 TFTP
The Trivial File Transfer Protocol (TFTP) is a simple protocol for file transfer.
The TFTP client supports file upload and download by using TFTP. To ensure simple
implementation, TFTP utilizes the User Datagram Protocol (UDP) as its transport protocol.
Compared with FTP, TFTP does not require complicated interaction interfaces and
authentication control. Therefore, TFTP is applicable in a networking environment without
complicated interactions between the client and the server. For example, you can obtain the
memory image of the system through TFTP when the system is started up. To preserve the small
size of TFTP packets, TFTP is realized based on UDP.
Presently, the NE40E implements the TFTP client rather than the TFTP server. The TFTP client
can upload and download files.
Basic Concepts of TFTP

l
Operation code
TFTP packet header contains a two-byte operation code, with values defined as follows:
1: Read request (RRQ): indicates a read request (RRQ).
2: Write request (WRQ): indicates a write request (WRQ).
3: Data (DATA): indicates data packets.
4: Acknowledgment (ACK): indicates a positive reply packet.
5: Error (ERROR): indicates error packets.
File type
TFTP supports the following file types:
Binary type: is used to transfer program files.
ASCII type: is used to transfer text files.
Currently, the NE40E can act only as the TFTP client and only the binary transfer type is
available.
Basic Principle of TFTP

l
A user name and password are not required.

This is because TFTP is designed for the bootstrap process.
TFTP transfer
The client initiates the TFTP transfer.
To download files, the client sends an RRQ to the server. The server then accepts the
request and sends a data packet to the client. After receiving the data packet, the client
sends an ACK packet to the server.
To upload files, the client sends a WRQ to the server. After the server accepts the request,
the client sends a data packet to the server and waits for an ACK packet from the server.
Issue 03 (2013-08-15)


Support for IPv6

At present, the TFTP client supports access to the IPv6 host address.
1.4.3 Introduction to Telnet

The Telecommunication Network Protocol (Telnet) is derived from ARPANET, which is one
of the earliest Internet applications released in 1969. Telnet enables a terminal to remotely log
in to a server and provides an interactive operation interface. Through Telnet, a login user of
one host can log in to other hosts to configure and manage them without being physically
connected to each of them.
Basic Concepts of Telnet

l
NVT
The Network Virtual Terminal (NVT) is a virtual device from which both ends of a Telnet
connection, the client and the server, map their real terminal to and from. By using the
NVT, Telnet can operate between any hosts (any operating systems) or terminals.
That is, the client operating system must map to the NVT whatever type of terminal the
user is using. The server must then map the NVT to whatever terminal type the server
supports.
Figure 1-4 shows conversion between physical terminals and the NVT.
Figure 1-4 Conversion between physical terminals and the NVT
Telnet client
Terminal
Telnet server
Terminal driver
Internet
Local
character set
NVT
character set
Remote
character set
NVT ASCII
NVT ASCII is a 7-bit ASCII character set. Each 7-bit character is sent as an 8-bit byte,
with the high-order bit set to 0. The Internet protocol suite including FTP and the Simple
Mail Transfer Protocol (SMTP) uses NVT ASCII.
IAC
Telnet uses in-band signaling in both directions. The byte 0xff is called the Interpret As
Command (IAC). The next byte is the command byte.
Commands and their meanings are listed as follows:
SE: suboption end
SB: suboption begin
WILL: option negotiation
WONT: option negotiation
DO: option negotiation
DONT: option negotiation
Issue 03 (2013-08-15)

10

IAC: data byte 255

Table 1-1 Telnet command set defined in RFCs
Name
Code (Decimal Notation)
Description
EOF
236
End of file
SUSP
237
Suspend current process (job

control)
ABORT
238
Abort process
EOR
239
End of record
SE
240
Suboption end
NOP
241
No operation
DM
242
Data mark
BRK
243
Break
IP
244
Interrupt process
AO
245
Abort output
AYT
246
Are you there?
EC
247
Escape character
EL
248
Erase line
GA
249
Go ahead
SB
250
Suboption begin
WILL
251
Option negotiation
WONT
252
Option negotiation
DO
253
Option negotiation
DONT
254
Option negotiation
IAC
255
Data byte 255
Telnet connection
A Telnet connection is a TCP connection used to transmit data with Telnet control
information.
Telnet client/server mode

Telnet adopts the client/server mode. Figure 1-5 shows the schematic diagram of the Telnet
client/server mode.
Issue 03 (2013-08-15)

11

Figure 1-5 Schematic diagram of the Telnet client/server mode
Telnet server
Pseudo
terminal driver
TCP/IP
Telnet client
TCP
connection
Terminal
driver
TCP/IP
Kernel
Kernel
User at a
terminal
Login shell
The preceding diagram shows that:

Telnet uses TCP.
All echo messages of the Telnet connection are output to the terminal.
The server interacts directly with the pseudo terminal.
Commands and data are transmitted between the server and the client through the TCP
connection.
The client logs in to the server.
Principle of Telnet
Telnet is designed to operate between any two hosts or terminals. The client operating system
maps to the NVT whatever type of terminal the user is using. The server then maps the NVT to
whatever terminal type the server supports. The types of clients and terminals are ignored.
Communication ends are simply assumed as being connected to the NVTs.
NOTE
Telnet adopts the symmetric mode. Theoretically, there must be an NVT at each of the two ends of a Telnet
connection.
The two ends of a Telnet connection send WILL, WONT, DO, or DONT requests for option
negotiation. The options to be negotiated include echo, character set of command change, and
line mode.
This section describes the operating principles of Telnet:
l
Requests in a Telnet connection

Either end of a Telnet connection can initiate a request to the other end. Table 1-2 shows
different requests and their meanings.
Table 1-2 Description of requests for a Telnet connection
Request
Description
Response
WILL
Issue 03 (2013-08-15)
WONT

DO
DONT
12

Request
Description
Response
WILL
Sender wants to
enable option
Receiver
says OK
Receiver
says NO
WONT
Sender wants to
disable option
Receiver
must say
OK
DO
Sender wants
receiver to enable
option
Receiver
says OK
Receiver
says NO
DONT
Sender wants
receiver to
disable option
Receiver
must say
OK(1)
NOTE
When the sender sends an "option disable" request, such as WONT and DONT, the receiver must
accept the request.
When the sender sends an "option enable" request, such as WILL and DO, the receiver can either
accept or reject the request.
l If the receiver accepts the request, the option is enabled immediately.
l If the receiver rejects the request, the option remains disabled, but the sender can retain the
features as the NVT.
Option negotiation
Option negotiation requires three bytes:
The IAC type, the byte for WILL, DO, WONT or DONT, and the option ID.
The following example illustrates the process of option negotiation.
The server needs to enable the "remote traffic control" with the option ID 33, and the client
grants the request. The commands exchanged between the server and client are as follows:
On the server: <IAC,WILL,33>
On the client: <IAC,DO,33>
Suboption negotiation
Certain options require more information than the option ID. For example, if the sender
requires the receiver to specify the terminal type, the receiver must respond with an ASCII
string to specify the terminal type.
The format of the commands for suboption negotiation is as follows:
< IAC, SB, option code, contents of suboption, IAC, SE >
A complete process of suboption negotiation is as follows:
The sender sends a DO or WILL command carrying an option ID to request that the
option be enabled.
The receiver returns a WILL or DO command carrying the option ID to accept the
request.
After the preceding two steps, both ends agree to enable the option.
Issue 03 (2013-08-15)

13

One end of the connection starts suboption negotiation by sending a request composed
of the SB, suboption ID, and SE in sequence.
The opposite end responds to the request for suboption negotiation by sending a
command composed of the SB, suboption ID, related negotiation information, and SE
in sequence.
The receiver returns a DO or WILL command to accept the negotiation information
about the suboption.
If there are no additional suboptions to be negotiated, the negotiation ends.
NOTE
In the preceding process, the receiver is assumed to accept the request from the sender. In practice,
the receiver can reject requests from the sender at any time as required.
The following example illustrates the process of terminal type negotiation.

The client needs to enable the "terminal type" with the option ID 24. The server grants the
request and sends a request for querying the client terminal type. The client then sends to
the server another request carrying its terminal type "DELL PC". The commands exchanged
between the server and client are as follows:
On the client: <IAC, WILL, 24>
On the server: <IAC, WILL, 33>
On the server: <IAC, SB, 24, 1, IAC, SE>
On the client: <IAC, SB, 24, 0, "D", "E", "L", "L", "P", "C", IAC, SE>
NOTE
l Only the sender that sends the DO command can request terminal type information.
l Only the sender that sends the WILL command can provide terminal type information.
Terminal type information cannot be sent automatically but only in request-response mode.
The terminal type is an NVT ASCII string of case insensitive characters.
Operating modes
Telnet has the following operating modes:
Half-duplex
Character at a time
Line at a time
Line mode
IPv6 Telnet Features Supported by the router

At present, the Telnet client can access hosts with IPv6 addresses; the Telnet server can receive
requests for connections from hosts with IPv6 addresses.
Telnet Services Provided by the router

The router provides the following Telnet services:
l
Telnet server
A user runs the Telnet client application on a PC to log in and configure and manage the
router.
Issue 03 (2013-08-15)

14

The standard port number for a Telnet server is 23. If attackers access the standard port
continuously, the bandwidth is consumed and the performance of the server is degraded.
As a result, legitimate users cannot access the port.
In this case, you can configure another port number to replace the standard port number
23. Attackers who do not know the new port number will still send requests for socket
connections to port 23. The Telnet server will reject the requests after detecting the wrong
port number. This effectively prevents bandwidth consumption and waste of system
resources caused by an attack on the standard Telnet server port.
l
Telnet client
After running the emulation terminal program or Telnet client application on a PC to
connect to the router, a user runs the telnet command to log in to the device and manage
it. As shown in Figure 1-6, Router A can function as both a Telnet server and a Telnet
client.
Figure 1-6 Router A functioning as a Telnet client
Telnet Session 1
Telnet Session 2
Telnet Server
PC
RouterA
RouterB
Terminal redirection
As shown in Figure 1-7, a user runs the Telnet client application and logs in to the router
through a specified port, and then sets up connections with the devices connected to the
router through asynchronous serial interfaces. The typical application is that the devices
directly connected to the router through asynchronous serial interfaces are remotely
configured and maintained.
Issue 03 (2013-08-15)

15

Figure 1-7 Terminal redirection
PC
Ethernet
Router
Async0
Async1
Router 1
Lan Switch
Async8/16
Async2
Modem
Router 2
NOTE
Only the routers having asynchronous serial interfaces support terminal redirection.
1.4.4 SSH
SSH is short for Secure Shell. Its standard port number is 22.
Data transmission in Telnet mode is prone to attack, because it does not have a secure
authentication mode and use TCP to transmit data in plain text. Simple Telnet access is also
vulnerable to Denial of Service (DoS) attacks, IP address spoofing, and route spoofing.
With the increasing emphasis on network security, data transmission in plain text used by
traditional Telnet and FTP is becoming unacceptable. SSH is a network security protocol that
provides secure remote access and other secure network services on an insecure network by
encrypting network data.
SSH uses TCP to exchange data and builds a secure channel based on TCP. In addition to standard
port 22, SSH supports access through other service ports to prevent attacks.
SSH supports password authentication, Digital-Signature Algorithm (DSA) and Revest-ShamirAdleman Algorithm (RSA) authentication. It uses DES, 3DES, and AES encryption to prevent
password interception, ensuring the integrity and reliability of the data and guarantee the secure
data transmission. In particular, RSA and DSA authentication supports the combined use of
symmetric and asymmetric encryption. This implements secure key exchange and finally secures
the session process.
By virtue of data encryption in transmission and more secure authentication, SSH is widely used
and has become one of the more important network protocols.
SSH has two versions: SSH1 (SSH 1.5) and SSH2 (SSH 2.0). Both are different and
incompatible. SSH2.0 is superior to SSH 1.5 in security, functions, and performance.
Issue 03 (2013-08-15)

16

Devices that can function as the STelnet client and server support both SSH1 (SSH 1.5) and
SSH2 (SSH 2.0). Devices that can function as the SFTP client and server support SSH2 (SSH
2.0).
Secure Telnet (STelnet) enables users to remotely and securely log in to the device, and provides
the interactive configuration interface. All data exchanges based on STelnet are encrypted. This
ensures the security of sessions.
The SSH File Transfer Protocol (SFTP) enables users to log in to the device securely for file
management from a remote device. This improves the security of data transmission for the
remote system update. Meanwhile, the client function provided by SFTP enables users to log in
to the remote device for secure file transmission.
Basic Concepts of SSH

l
SFTP
SFTP guarantees secure file transfer over an insecure network by authenticating the client
and encrypting data in bidirectional mode.
STelnet
STelnet ensures secure Telnet services. It guarantees secure file transfer on a traditional
insecure network by authenticating the client and encrypting data in bidirectional mode.
RSA authentication
RSA authentication is based on the private key of the client. It is a public key encryption
architecture and an asymmetric encryption algorithm. RSA is mainly used to help solve the
problem of factoring large numbers by transmitting the keys of the symmetric encryption
algorithm, which can improve encryption efficiency and simplify key management.
The server checks whether the SSH user, public key, and digital user signature are valid.
If all of them are valid, the user is permitted to access the server; if any of them is invalid,
the authentication fails and the user is denied access.
DSA authentication
The digital signature algorithm (DSA) is an asymmetric encryption algorithm used the
authenticating clients. DSA algorithm consists of a public key and a private key.
Like RSA, the server checks whether the SSH user, public key, and digital user signature
are valid. If all of them are valid, the user is permitted to access the server; if any of them
is invalid, the authentication fails and the user access is denied.
Compared with RSA authentication, DSA authentication adopts the DSA encryption mode
and is widely used.
In many cases, SSH only supports DSA to authenticate the server and the client.
In SSH, DSA authentication takes precedence over RSA authentication.
Password authentication
Password authentication is based on the user name and password.
On the server, the AAA module assigns a login password to each authorized user. The
server has the mappings between user names and passwords. When a user requests access
the server, the server authenticates the user name and password. If either of them fails to
pass authentication, the access is denied.
l
Issue 03 (2013-08-15)
RSA-password authentication and DSA-Password authentication

17

The server can authenticate the client by checking both the public key and the password.
It allows user access only when both public key and password are consistent with those
configured on the server.
l
ALL authentication
The server can authenticate the client by checking both the public key and the password.
It allows user access when either the public key or the password is consistent with those
configured on the server.
SSH Features Supported by the Device

l
Basic SSH functions

Different encryption algorithms for incoming and outgoing data
Different MAC algorithms for incoming and outgoing data
Encryption algorithms of 3DES-cbc, DES and Advanced Encryption Standard
(AES128)
HMAC-sha1 authentication algorithm
HMAC algorithm, including shal, shal-96,sha2-256,sha2-256-96, md5, and md5-96.
diffie-hellman-group1-sha1, diffie-hellman-group-exchange-sha1 algorithms for key
exchange
Public key format of SSH-RSA
Public key format of SSH-DSA
Key re-exchange (It indicates renegotiation of the key. During this process, the
algorithm and the key used for the algorithm are negotiated.)
Public key authentication and password authentication
SSH client function

The SSH client function allows users to establish SSH connections with a UNIX host or
the device supporting the SSH server. Figure 1-8 and Figure 1-9 show the establishment
of an SSH connection in the Local Area Network (LAN) and in the Wide Area Network
(WAN) respectively.
Figure 1-8 Establishing an SSH connection in a LAN
WorkStation
Router
Ethernet 100BASE-TX
Server
LapTop
PC
PC running SSH client
Issue 03 (2013-08-15)

18

Figure 1-9 Establishing an SSH connection in a WAN

Local LAN
Remote LAN
WAN
Router
SSH Router
PC run SSH client
PC
SSH for SFTP

SFTP is based on SSH2.0. It guarantees secure file transfer on a traditional insecure network
by authenticating the client and encrypting data in bidirectional mode.
An SFTP-enabled device can provide the following functions:
Acting as the SFTP client or the SFTP server
Being enabled with or disabled from SFTP services (By default, SFTP services are
disabled.)
Setting the default directory that the SFTP client is allowed to access
SSH for STelnet

An STelnet-enabled device can provide the following functions:
Acting as the STelnet client or the STelnet server
Being enabled with or disabled from STelnet services. (By default, STelnet services are
disabled.)
SSH for non-standard ports

The standard SSH listening port number is 22. When attackers continuously access the port,
the bandwidth and performance of the server is reduced and authorized users are prevented
from accessing this port. This is known as a DoS attack.
To address the problem, you can change the listening port to another port on the SSH server.
This prevents attackers from consuming bandwidth and system resources. Authorized users
can still access the SSH server through non-standard ports to decrease DoS attacks.
Applications of this function are as follows:
The STelnet client can access the server using a non-standard port.
The listening port can be set on the SSH server.
SSH for IPv6

At present, the SSH client can access an IPv6 host address and the SSH server can set up
an IPv6 connection.
Principles of SSH
SSH uses the traditional client/server (C/S) application model. Its security is guaranteed by using
the following modes:
Data encryption: Through the negotiation between the client and the server, an encryption key
is generated and used in data symmetric encryption. This ensures confidentiality during data
transmission.
Issue 03 (2013-08-15)

19

Data integrity: Through the negotiation between the client and the server, an integrity key is
generated and used to uniquely identify a session link. All session packets are identified by the
integrity key. Any modifications made by the third party during transmission can be discovered
by the receiver based on the integrity key. The receiver can discard these modified packets to
ensure the data integrity.
Authority authentication: There are multiple authentication modes. Authority authentication
allows only valid users to have a session with the server, improving system security and
safeguarding the benefits of valid users.
Establishment of an SSH Connection

The SSH connection goes through six phases during the entire communication process, as shown
in Figure 1-10. The SSH connection is established through negotiation. The following is the
entire SSH negotiation procedure.
Figure 1-10 Establishment of an SSH connection
Version Negotiation
Algorithm Negotiation
Key Exchange
User Authentication
Session request
Interactive session
1.
Version negotiation
In the version negotiation phase, the SSH client sends a request for setting up a TCP
connection to the SSH server. After the TCP connection is set up, the SSH server and SSH
client negotiate the SSH version. After a matched version protocol is obtained, different
version protocols correspond to different state machine processes. If the version of the client
matches that of the server, the key negotiation starts; otherwise, the SSH server tears down
the TCP connection.
2.
Algorithm negotiation
In the algorithm negotiation phase, the sender sends algorithm negotiation messages to the
receiver, together with their parameters, such as the random cookie, key exchange
algorithm, host key algorithm, Message Authentication Code (MAC) method, and
supported language.
After receiving these algorithm negotiation messages, the receiver compares the received
algorithm list set with the local algorithm list set. If the key exchange algorithm, public key
Issue 03 (2013-08-15)

20

encryption algorithm, or MAC algorithm is not found, the receiver tears down the
connection with the sender and the algorithm negotiation fails.
3.
Key exchange
After the server and client negotiate the version, the server sends the client a packet
containing the server's host public key, the server public key, the supported encryption
algorithm, the authentication algorithm, the protocol extension flag, and an 8-byte cookie.
This packet is sent in simple text.Then, the server and client calculate a 16-byte session ID
using the same parameter. The client also randomly generates a 32-byte session key used
to encrypt data. The client does not send the session key to the server, but use the mostsignificant 16 bytes of the session key to XOR the 16-byte session ID to obtain a result.
The client then arranges the result using the Most Significant Bit (MSB) first rule and
obtains a multiple precision (MP) integer. Then the client encrypts the MP integer using a
public key with a smaller module value, arranges the result using the MSB first rule again,
and obtains a new value. Then the client uses a public key with a larger module value to
encrypt the new value.
The server is now in the waiting state. When receiving a key generation message from the
client, the server then returns a key generation message to the client, which indicates that
key exchange is complete and that the new key should be used for communications. If the
server fails to receive a key generation message from the client, it returns a key exchange
failure message and tears down the connection.
4.
User authentication
After obtaining the session key, the SSH server authenticates the SSH client. The SSH
client sends the identity information to the SSH server. After a specific authentication mode
is configured on the SSH server, the client sends an authentication request. If the
authentication succeeds or the connection with the server expires, the connection is
terminated.
The SSH server authenticates a user in one of the following methods:
l In RSA, DSA authentication, the client generates an RSA, DSA key pair and sends the
public key to the server. When a user initiates an authentication request, the client
randomly generates a text encrypted with the private key and sends it to the server. The
server decrypts it by using the public key. If decryption succeeds, the server considers
this user trustable and grants access rights. If decryption fails, the server tears down the
connection.
l Password authentication is implemented based on AAA. Like Telnet and FTP, SSH
supports local database authentication and remote RADIUS server authentication. The
SSH server compares the user name and password of an SSH client with the preconfigured ones. If both are matched, authentication succeeds.
5.
Session request
After user authentication is completed, the client sends a session request to the server. The
session requests include the running of Shell and commands. At the same time, the server
waits to process the request from the client. During this phase, the server responds to the
client with an SSH_SMSG_SUCCESS message after successfully processing a request
from the client. If the server fails to process or identify the request, it responds with an
SSH_SMSG_FAILURE message.
Possible causes for the authentication failure are as follows:
l The server fails to process the request.
l The server cannot identify the request.
Issue 03 (2013-08-15)

21

6.
Interactive session
After the session request is accepted, the SSH connection enters the interactive session
mode. In this phase, data is transmitted bidirectionally.
a.
The client sends a packet with the encrypted command to the server.
b.
After receiving the packet, the server decrypts the packet and runs the command. Then,
the server packages the encrypted command execution results and sends the packet to
the client.
c.
Upon receiving the packet, the client decrypts it and displays the command execution
results on the terminal.
1.4.5 User Management

Users can log in to the device to configure, monitor, and maintain local or remote network devices
only after user interfaces, user management, and terminal services are configured. User
interfaces provide the login place, user management ensures login security, and terminal services
offer login protocols.
The device supports the following login modes:
l
Login through the console port
Local or remote login through the AUX port
Local or remote login through Telnet or SSH
User management (consisting of user interface configurations, user view configurations, and
terminal services) provides secure login and operations, implementing unified management over
different user interfaces.
User Interface
A User Interface (UI), which is presented as a user interface view, enables users to log in to the
device. Through the user interface, you can configure the parameters on all physical and logical
interfaces that work in asynchronous and interactive modes. In this manner, you can manage,
authenticate, and authorize the login users.
l
The system supports the following user interfaces:

Console port: is a linear port on the device's main control board.
Each main control board provides a console port that conforms to the EIA/TIA-232
standard, type DCE. The serial port of the user terminal can directly connect to the
console port of the device to implement local device configurations.
AUX port: is also a linear port on the device's main control board.
Each main control board provides an AUX port that conforms to the EIA/TIA-232
standard, type DTE. The terminal can perform remote access to the device through the
Modem on the AUX port.
Virtual Terminal (VTY) is a kind of virtual interface indicating a logical terminal line.
When you set up a Telnet or SSH connection with the device through a terminal, you
set up a VTY. You can also perform local or remote access to the device through the
virtual connection established through VTY.
Numbering of user interfaces

You can number a user interface using one of the following methods:
Issue 03 (2013-08-15)

22

Relative numbering
The format of relative numbering is: user interface type + number.
Relative numbering indicates that the interfaces of the same type are numbered. Relative
numbering uniquely specifies a user interface of the same type. Relative numbering
must comply with the following rules:
Number of the CON port: CON 0
Number of the AUX port: AUX 0
Number of the VTY: The first VTY is 0, the second VTY is 1, and so on
Absolute numbering
Absolute numbering uniquely specifies a user interface or a group of user interfaces.
Absolute numbers start with 0 and are allocated in the sequence of the CON port, the
AUX port, and the VTY.
On a main control board, only one CON port or AUX port is present but a maximum
of 20 VTYs are present. (The VTYs ranging from 1 to 14 are provided for ordinary
Telnet or SSH users and those ranging from 16 to 20 are reserved for Network
Management System (NMS) users.) In the system view, the allowable maximum
number of user interfaces can be set; the default value is 5.
By default, the absolute numbering of the CON port, the AUX port, and the VTY is
shown in Table 1-3.
Table 1-3 Example for the absolute numbering of user interfaces
Absolute
Numbering
User Interface
CON0
33
AUX0
34
VTY0: the first VTY
35
VTY1: the second VTY
36
VTY2: the third VTY
37
VTY3: the fourth VTY
38
VTY4: the fifth VTY
NOTE
Different devices may have different absolute numbering methods for AUX ports and VTYs. In the
previous examples, the numbers ranging from 1 to 32 are reserved for VTYs. TTY is a synchronous
or asynchronous terminal line, which is related to specific physical devices. In this document, the
commands for viewing absolute numbering and relative numbering have been provided.
User Login
In the absence of user authentication, any user can configure a device after it is connected to the
PC through the console port.
Issue 03 (2013-08-15)

23

After the IP address is assigned to the main control board or the interface board, any remote user
can use Telnet or SSH to log in to the device, or set up the PPP connection with the device to
access the network.
Therefore, the device and network are vulnerable to attacks. In this case, users should be created
for the device and passwords should be set for users so that the device can manage users. SSH
users are configured with RSA authentication and other users are configured with AAA. For
more information, refer to the AAA Feature Description.
User Classification
Users of the device can be classified into the following types based on the type of service used.
l
HyperTerminal users: indicate those who log in to the device through the console port or
AUX port.
Telnet users: indicate those who log in to the device through Telnet.
FTP users: indicate those who transfer files by setting up the FTP connection with the
device.
PPP users: indicate those who access the network by setting up the PPP connection, such
as dialup and PPPoA, with the device.
SSH users: indicate those who perform remote access to the network by setting up the SSH
connection with the device, including the STelnet mode and the SFTP mode.
NMS users: indicate those who set up a connection with the device through SNMP or Telnet
to manage devices in machine-to-machine mode.
One user can obtain multiple services simultaneously to perform multiple functions. VTY users,
namely, Telnet or SSH users, need to be bound to admission protocols in the user interface view
before they log in.
User Priorities
The system supports hierarchical management over HyperTerminal users and VTY users.
The greater the number, the higher the user level. The level of the command that a user can run
is determined by the user's level.
l
In the case of password authentication, the level of the command that the user can run
depends on the level of the user interface.
In the case of AAA authentication, the command the user can run depends on the level of
the local user specified in the AAA configuration.
A user can run the commands whose levels are equal to or lower than the user's level. For
example, the level 2 user can access the commands at levels 0, 1, and 2. The level 3 user can
access the commands at levels 0, 1, 2, and 3.
Through the super command, the user can be switched from a lower level to a higher level. The
switched user level is determined by the level of the command configured by the super
command.
NOTE
One-to-one mapping exists between user levels and command lines.
Issue 03 (2013-08-15)

24

User Authentication
After users are configured, the system authenticates them when they log in to the device.
l
Password authentication: In this mode, users can log in to the device by entering passwords
rather than usernames. This mode is configured based on the terminal line. A password can
be configured for a terminal line or a group of terminal lines.
AAA authentication: includes AAA local and AAA remote authentication. In AAA local
authentication, users need enter both the usernames and passwords on the local device. If
necessary, users also need to enter user attributes, such as user rights and FTP paths. In
AAA remote authentication, user information needs to be configured on the AAA server.
In general, AAA server authentication is used for VTY users; AAA local authentication is
used for console users. For more information, refer to the AAA Feature Description.
Planning Users
The network administrator can plan the users of the device as required.
l
Usually, at least a HyperTerminal user needs to be created on the device.
Telnet or SSH users need to be configured to implement remote login to the device through
Telnet or SSH.
FTP or SFTP users need to be configured to enable remote users to upload or download
files to or from the device.
PPP users need to be configured to enable users to access the network through the PPP
connection established with the device.
1.4.6 Virtual File System

The virtual file system, that is easy-to-use and tailorable, has two functions, namely, managing
the storage device and managing the files that are stored on the device. In the file system, users
can create, delete, modify, and rename a file or a directory, and view the contents of a file. To
manage mass storage devices more effectively and ignore the differences of bottom-layer storage
devices, the mass storage device must support the virtual file system that is easy-to-use and
tailorable.
Basic Concepts
l
Storage device: a hardware device used to store data
File: a mechanism used for the system to store and manage information
Directory: a mechanism used by the system to integrate and organize files and to provide
a logical container of files
Managing Storage Devices

l
Repairing the storage device with the abnormal file system

When the file system on a storage device fails, the device terminal prompts that the fault
should be rectified.
Formatting the storage device

When the repair of the file system fails or when the data on the storage device is no longer
needed, the storage device can simply be reformatted. However, all data on the device will
be lost.
Issue 03 (2013-08-15)

25

If reformatting the storage device fails, a physical fault may occur.
Managing File Directories

When transmitting files between the client and the server, directories needs to be set up in the
file system. The specific operations are as follows:
l
Display the current directory.
Change the current directory.
Display directories or file information.
Create a directory.
Delete a directory.
NOTE
Either the absolute path or relative path is applicable.
Managing Files
You can perform the following operations for files:
l
Display file contents.
Copy files.
Move files. Changing the file storage location.
Rename files. Changing the names of existing files.
Delete files. Deleting existing files and actually moving files to the recycle bin. This
operation is reversible. The wildcard (*) can be used to delete multiple files at a time.
Delete files from the recycle bin. This operation is irreversible.
Restore deleted files. Restoring files from the recycle bin. Restoring deleted files is a reverse
operation of deleting files.
Miscellaneous
l
Executing batch files

A batch file is created and executed to automat several tasks. Batch files must be created
on the client and uploaded to the device.
This operation need edit batch files on the client and upload batch files to the device.
Configuring the prompt mode of the file system

If data is lost or damaged during file management, the system should provide prompts as
to corrective steps.
CAUTION
If the prompt mode is set as quiet, the system does not provide prompts when data is lost because
of user misoperations such as the accidentally deleting files. Therefore, this quiet mode should
be used with caution.
Issue 03 (2013-08-15)

26

1.4.7 Pipe Character

The pipe character is used to filter and then display the output of display commands according
to the rules set by a user.
During device maintenance, a display command may output a lot of information, only a part of
which has real value to the user, for example, the status of interfaces, the status of OSPF peers,
and the Cyclic Redundancy Check (CRC) statistics of interfaces (used to determine or locate a
fault). If all the output of a display command remains unfiltered, users cannot readily obtain
pertinent information. The pipe character filters out irrelevant information of the command
output, insuring the desired information stands out to help users rapidly determine the exact
nature of the problem.
Filtration rules of the pipe character are as follows:
l
include + regular expression

In this mode, the lines containing user-specified contents are displayed.
begin + regular expression

In this mode, the lines from the first line containing user-specified contents are displayed.
exclude + regular expression

In this mode, the lines not containing user-specified contents are displayed.
count
In this mode, the lines to be output are counted and only the line numbers are displayed.
Special Processing of the Table-form Output

The output of certain display commands contains tables such as FIB and ARP tables. A table is
composed of the table heading, table tail, and table text (entries). If the table heading and tail
are included in the pipe character filtration, they are probably filtered out. This is not convenient.
It is necessary, therefore, that table headings and tails are not included in the filtration process.
Generally, all display commands need to support the pipe character. The display commands
that meet the following requirements, however, do not necessarily support the pipe character:
l
Commands whose output information is stable can be displayed in current screen.
Commands whose output information does not vary with configurations, dynamic data,
and specifications.
Commands used in the diagnostic view, such as commands used to collect information.
1.4.8 Daylight Saving Time

Daylight Saving Time (DST), also referred to as summer time, is a convention established by
communities for prolonging daylight hours and saving resources such as the cost of lighting
office buildings and schools.
In high latitude areas, the sun rises earlier in summer than in the winter. To reduce evening usage
of incandescent lighting and save energy, clocks are adjusted forward one hour in the spring. At
present, about 110 countries around the world adopt DST.
Users can customize the DST zone according to their countries' or regions' convention. Users
can set when and how clocks are adjusted forward, usually an hour. With DST enabled, the
Issue 03 (2013-08-15)

27

system time is adjusted accordingly; when it is time to end DST, the system time automatically
returns to normal.
1.4.9 Timing Restart

The system supports timing restart when, at a specified time, the system automatically restarts
and updates system files. Such a device upgrade needs to be performed at the exact right time.
After a timing restart is configured, maintenance personnel just need to prepare software
packages, system image files, and to set the time and files for the automatic device restart.
1.4.10 MIB Interface Is Used to Optimize System Upgrade

In a cluster, version upgrading becomes complex. A user needs to download the system startup
file to the system's master board, and then to copy it to the master and slave boards of other
chassis. After copying the system startup file, the user then needs to configure the startup settings
for each chassis. This requires a lot of work on the part of the user.
During the system upgrade, how the device processes the MIB is optimized and what the NMS
operates on the device is simplified.
When the user downloads the startup file to the master board through the NMS, the device
directly synchronizes the file to the slave board or the master and slave boards on other chassis
if in a cluster. The system queries the file index according to the file type and name (including
the startup file, PAF&License files, configuration file, and patch). The NMS then sets the file
for the next startup according to the file index. This setting is automatically synchronized to the
slave boards. In a cluster, this setting can also be synchronized to the master and slave boards
of other chassis without additional configurations. This greatly reduces the user's workload on
configuring and uploading startup-related files.
Before downloading version-related files (including the startup file, PAF&License files,
configuration file, and patch) from the FTP server, the device checks the remaining memory of
the master and slave boards in each chassis. If the available memory is insufficient, the earliest
created system file is automatically deleted to ensure sufficient memory. In the case that the
device contains only files for the current and next startup and does not have enough memory to
save the file to be downloaded, an error message is returned and the download operation is
canceled.
When the system upgrade is simplified through the MIB interface, the following functions are
emphasized:
l
The device checks the available memory to ensure that the remaining memory is enough
to store at least one system file for the upgrade.
The object hwFlhOperMemSize is added to huaweiFlhOpTable of HUAWEI-FLASHMAN-MIB. The value of this object is used to specify the size of the reserved memory (in
KB). This object is optional during file uploading, and its default value is 0. If the value
remains 0, no more memory needs to be reserved. If the value of this object is not 0, files
are deleted when available memory is insufficient. There must be two system files, namely,
the currently-used system file and the rollback file. The earlier created system file is first
deleted, and then if the available memory is still insufficient, an error message is returned.
In this case, the user needs to manually delete enough remaining files until the available
memory is sufficient.
Issue 03 (2013-08-15)
The needed file is downloaded and synchronized between the system master and slave
boards and between chassis.
28

After the file is successfully downloaded to the master board of the system, the file is
automatically synchronized to the slave board of the system as well as the master and slave
boards of other chassis. If the file already exists and is not the file for the current startup,
the file will be automatically overwritten. If the file already exists and is the file for the
current startup, an error message is returned.
l
The index of the specified file is queried.

The system provides a MIB table for querying a file index through the real-time obtaining
file index operation. The NMS sets the file for the next startup of the device according to
the index.
The file for the next startup is set and synchronized between the system master and slave
boards and other chassis.
The NMS sets the file for next startup through hwSysReloadScheduleTable. After the
master board of the system is specified, the system automatically synchronizes the file for
the next startup to the slave board of the system as well as the master and slave boards of
other chassis.
1.4.11 NAP
As a Layer 3 protocol, the Neighbor Access Protocol (NAP) helps users to remotely log in to a
device with default configurations and then to configure the device. A NAP connection can be
established as long as the device to be configured and the local device are physically connected.
As shown in Figure 1-11, Router A and Router B are devices on the current network, and
Router C is a device with default configurations. Router B and Router C are connected via a
single hop, both supporting NAP.
Figure 1-11 Establishing a NAP connection
1
2
Network
PC
RouterA
RouterB
Master device
RouterC
Slave device
Master interface
Slave interface
1
2
3
NAP negotiation
IP address allocation
Remote login
During NAP negotiation and IP address allocation, the device on the current network and the
device with default configurations act as the master device and slave device respectively, and
the two physical interfaces connecting the two devices are called the master interface (on the
master device) and the slave interface (on the slave device). During remote login, the master
device and slave device act as the client and server respectively.
Issue 03 (2013-08-15)

29

Format of a NAP packet

NAP packets are encapsulated into UDP packets, using the UDP port 53535. The destination IP
address of NAP packets is the reserved multicast address 224.0.0.128, and the source IP address
is the address configured for the sending interface. If the sending interface has no IP address,
0.0.0.0 is used as the source IP address of NAP packets. The TTL of NAP packets is 1. Figure
1-12 shows the format of a NAP packet.
Figure 1-12 Format of a NAP packet
0
1
Version
4 byte
Protocol Type TLV Number
Reserved
Checksum
Length
TLV1 (n byte)
TLV2 (n byte)
...
TLVn (n byte)
Major fields in a NAP packet are described as follows:

l
Version: indicates the version number of NAP. The value is 01.
Type: indicates the type of a NAP packet. There are five types of NAP packets. Table
1-4 lists these five types and their corresponding values.
Table 1-4 Description of the Type field in a NAP packet
Issue 03 (2013-08-15)
Value
Type
01
Detect packet
02
Response packet
03
Establish packet (confirming the establishment of a

neighbor relationship)
04
Hello packet
05
Close packet
TLVn: indicates the variable-sized TLV data area. This field consists of three parts: data
type, data length, and data.
30

NAP Negotiation
By default, a NAP-supporting device is a slave device and its interface is a slave interface,
responsible for listening to rather than sending packets. After the NAP master and slave devices
are configured, the listening function is enabled on the slave interface by default. After NAP is
enabled on the master interface on the master device, the device sends a Detect packet to discover
neighbors, and then enters the NAP negotiation phase. The NAP negotiation process is shown
in Figure 1-13.
Figure 1-13 NAP negotiation
Master device
Slave device
Proto
cal pa
cket
Analyzing
ACK
ACK
1.
The NAP slave device initiates the process, and the listening function is enabled on the
slave interface by default. Then, the slave device waits for a Detect packet from the master
device.
2.
The master device sends a Detect packet through the master interface to discover neighbors.
3.
After receiving the Detect packet, the slave device analyzes it.
4.
The master and slave devices enter the NAP negotiation phase.
5.
The slave device sends a Response packet through the slave interface. After receiving the
packet, the master device replies with an Establish packet. Then, the NAP neighbor
relationship is established.
IP Address Allocation
To simplify both the configuration of service IP addresses for the master and slave interfaces
and the maintenance for current NAP connections during the configuration, you need to
configure IP addresses for the master and slave interfaces separately.
By default, NAP allocates IP addresses in the address pool (10.167.253.0/24) to the master and
slave interfaces. If an address conflict occurs, select either of the following two methods to
manually configure the interface addresses: Specify a NAP IP address pool, and IP addresses
will be automatically allocated based on a NAP address allocation algorithm. Configure IP
addresses of the same network segment for the master and slave interfaces.
Issue 03 (2013-08-15)

31

Remote Login
l
After IP address allocation, the master device logs in to the slave device through Telnet,
enters the interactive interface, and initializes the slave device.
If the slave device has only default configurations, the master device can log in to the slave
device without a user name and a password.
If the slave device is configured with a user name and a password, the master device has
to pass authentication before remotely logging in to the slave device through NAP.
NOTE
The slave device with default configurations checks the source address of a remote Telnet connection. If
the Telnet source address is the NAP address of the master device, the slave device considers that the master
device has the highest user level (the same as that of the console interface) and allows the master device
to directly log in without being authenticated. If the Telnet source address is not the NAP address of the
master device, the remote login is bound to fail. This ensures the system security of the device with default
configurations.
When the NAP-based connection is terminated, temporary primary and secondary IP addresses
allocated to the master and slave devices are automatically released. After configuring a device
with default configurations, you can globally disable the slave interface attribute on the device
to reject other NAP negotiation requests. In addition, the existing neighbor relationships are torn
down and allocated IP addresses are released automatically. After the slave interface attribute
is globally disabled on a slave device, interfaces on the slave device can function as only master
interfaces to initiate connections to other devices with default configurations. In this manner,
system security is guaranteed.
1.4.12 Dynamic Module Load

Purpose
Software upgrade is a common method to add new services on a network. This method, however,
has the following deficiencies:
1.
An upgrade process is complex. An upgrade involves all service configurations, and

configurations may change or be incompatible after an upgrade. In addition, errors easily
occur due to misoperations.
2.
An upgrade process affects services.
In addition, operators have different requirements for functions. If a function is required by

operator A but not operator B, the function must be enabled on operator A's network but disabled
on operator B's network. This situation makes an upgrade process more complex. The PAF/
license feature can enable and disable specified functions, but it has the following deficiencies:
l
The system must be restarted after a PAF/license controlled feature is enabled or disabled,
so that the configuration can take effect.
The PAF/license feature does not have a mechanism to fight against attacks.
Dynamic module load is the answer to these problems. Dynamic module load allows you to
install the module patch package for a desired function, without upgrading or powering off your
device.
Issue 03 (2013-08-15)

32

Related Concepts
Dynamic module load is a method for deploying new services. Dynamic module load is
implemented by installing the module patch package for a desired function using the installmodule command.
Implementation
Dynamic module load is implemented by means of the patch load mechanism. The procedure
is as follows:
1.
Convert a desired function module into a patch package.
2.
Install the module's patch package by running the install-module command.
3.
Activate the module's patch package.
Dynamic module load is available only to authorized users. If the process fails, the user
cannot enable the specified function even by unlawful methods, improving device security.
In addition, this feature does not require you to power off your device, minimizing service
interruptions.
Benefits
1.5 Applications
1.5.1 Applications of FTP
l
Device functioning as an FTP client

A user logs in to the FTP server from the device acting as an FTP client and then downloads
files from the server to the client storage device.
In Figure 1-14, the device with the IP address of 172.16.105.111 acts as the FTP client.
The user then can log in to the FTP server from the client through FTP.
Figure 1-14 Networking diagram of the device functioning as an FTP client
IP Network
Server
172.16.105.110/24
GE2/0/0
Router
172.16.105.111/24
Device functioning as an FTP server

A user logs in to the client from a HyperTerminal. The device functions as an FTP server,
and downloads files from the FTP server. In Figure 1-15, the device with the IP address
of 172.16.104.110 acts as the FTP server.
Issue 03 (2013-08-15)

33

Figure 1-15 Networking diagram of the device functioning as an FTP server
Server
172.16.104.110/24
console cable
1.5.2 Applications of TFTP

Downloading or Uploading Files Through TFTP
A user can use TFTP to upload or download files to or from the server in a simple interaction
environment. Currently, the device acts only as a TFTP client.
Figure 1-16 shows the networking of downloading or uploading files through TFTP.
Figure 1-16 Networking diagram of uploading or downloading files through TFTP
Router
TFTP Client
10.111.16.160/24
Server
PC
1.5.3 Applications of Telnet

Telnet applies to remote login to configure, monitor, and maintain the remote or local devices
running device.
As shown in Figure 1-17, the user on Router A logs in to the remote Router B through Telnet.
Figure 1-17 Networking diagram of login through Telnet
GE1/0/0
1.1.1.1/24
RouterA
Issue 03 (2013-08-15)
GE1/0/0
1.1.1.2/24
RouterB

34

1.5.4 Applications of SSH

Attackers cannot pass authentication because they cannot provide the correct private key or
password. In addition, they cannot obtain the session key between another client and the server.
Only the server and the related client can decrypt packets exchanged between them. Even if
attackers intercept packets exchanged between the server and the client, they cannot decrypt the
packets. In this manner, secure data transmission on the network is guaranteed.
l
SSH for STelnet

The STelnet client is based on SSH2 and the STelnet server is based on SSHv1.x and
SSHv2. The client and the server set up a secure connection through negotiation. The client
can then log in to the server using Telnet. Figure 1-18 shows the networking of SSH for
STelnet.
Figure 1-18 Networking diagram of SSH for STelnet
Stelnet Client
SSH Server
A device can function as the STelnet server. Alternatively, it can function as the STelnet
client to access other STelnet servers.
STelnet services can be enabled or disabled as required and they must be configured on
global mode. By default, STelnet services are disabled.
l
SSH for SFTP

SFTP is based on SSH2.0, which supports two authentication modes: password
authentication and RSA authentication. To access the server using a client, an authorized
user needs to enter the correct user name, password, and private key to pass the
authentication on the server. After that, the user can use SFTP that is similar to FTP to
manage remote file transfer on the network. The system uses the negotiated session key to
encrypt the user's data.
A device can function as the SFTP server. Alternatively, it can function as the SFTP
client to access other SFTP servers.
SFTP services can be enabled or disabled as required and they must be configured on
global mode. By default, SFTP services are disabled.
Different users are allowed to use SFTP to access different file directories. Users can
access only the set SFTP directories. Available files for different users are isolated from
each other.
Issue 03 (2013-08-15)

35

Figure 1-19 Networking diagram of SSH for SFTP
SFTP Client
legal user
SFTP Server
Network
SSH Client
setting port
VPN
SFTP Server
SFTP Client
attacker
SSH for the private network

A device can function as either an STelnet client or an SFTP client. Therefore, the client
(device) on a public network can set up a Socket connection with the server in a VPN:
The STelnet client can access the SSH server on the private network.
The SFTP client can access the SSH server on the private network.
Figure 1-20 Networking diagram of SSH for the private network
SSH Client
legal user
Network
SSH Client
setting port
SSH Server
VPN
SSH Client
attacker
Issue 03 (2013-08-15)
SSH for non-standard ports

36

The standard SSH listening port number is 22. If attackers continuously access this port,
the available bandwidth and the performance of the server are reduced and authorized users
cannot access this port.
To address this problem, you can change the listening port on the SSH server to a nonstandard port. The port change is invisible to attackers, so they continue to send socket
connection requests to the standard listening port 22. If the SSH server detects that the
connection requests are not forwarded to the actual listening port, it denies the requests.
Only authorized clients can set up socket connections with the SSH server using nonstandard ports. The client and the server then negotiate the SSH version, algorithms and
session keys. User authentication, session request, and interactive session are performed
subsequently.
SSH can be used on intermediate switching devices or edge devices on a network to secure
user access and device management.
Figure 1-21 Networking diagram of SSH for non-standard ports
SSH Client
legal user
Network
SSH Client
setting port
SSH Server
SSH Client
attacker
SSH for RADIUS

If password authentication is required, SSH calls the interface provided by AAA in the
same manner as FTP and Telnet. After user authentication is configured as RADIUS in
AAA, and when SSH authentication is enabled, the SSH server sends the authentication
information (user name and password) to the RADIUS server (which is compatible with
the HWTACACS server). The RADIUS server then sends the authentication result (pass
or fail) to the SSH server where it is determined whether or not to establish a connection
with the SSH client.
Figure 1-22 SSH for RADIUS
SSH Client
Issue 03 (2013-08-15)
SSH Server

RADIUS Server
37

SSH for ACLs

The SSH server uses ACLs to limit the call-in and call-out rights of SSH users. This prevents
unauthorized users from establishing TCP connections or entering the SSH negotiation
phase, thus improving the security of the SSH server.
Figure 1-23 Networking diagram of SSH for ACLs
ACL
SSH Client
SSH Server

Terms
Issue 03 (2013-08-15)
Terms
Description
FTP
In the TCP/IP protocol suite, the File Transfer Protocol (FTP) is applied
to the application layer. It is used to transfer files between local and remote
hosts. FTP is implemented based on the file system.
TFTP
TFTP is short for Trivial File Transfer Protocol.
Telnet
The Telecommunication Network Protocol (Telnet) is applied to the

application layer in the TCP/IP protocol suite. Telnet enables a terminal
to remotely log in to a server, presenting an interactive operation interface.
NVT
The Network Virtual Terminal (NVT) is a bidirectional virtual device, to

and from which both ends of the connection, the client and the server, map
their physical terminals. Because of the use of uniformed NVT, Telnet
can operate between any two hosts (on any operating system) or terminals.
SSH
Secure Shell (SSH) uses multiple encryption and authentication modes to

solve the problem of data encryption and user authentication in traditional
services. In virtue of its mature public key or private key system, SSH
provides an encryption channel between the client and the server. This
solves the problem of insecurity caused when data, such as passwords, are
transmitted over the network in plain text. SSH also supports multiple
authentication modes, such as CA and the smart card, which solves the
authentication problem and eliminates such insecurity factors as the manin-the-middle attack.
SFTP
The Secure File Transfer Protocol (SFTP) is an SSH-based upper-layer

application, which provides secure file transmission.

38

Terms
Description
STelnet
The Secure Shell Telnet (STelnet) is an SSH-based upper-layer

application, which provides secure login operations.
TLS
TLS is a protocol based on the Netscape's SSL 3.0 protocol. TLS replaces
the vulnerability of SSL, which was vulnerable to man-in-the-middle
attack and used a weak MAC construction. The successors of SSL are
TLS 1.0 and TLS 1.1, which are defined by IETF. HTTPS, LDAP and
SNMP are some of the protocols that continue to use SSL.
Abbreviations
Issue 03 (2013-08-15)
Abbreviations
Full Name
AAA
Authentication, Authorization, Accounting
ACL
Access control list
AES
Advanced Encryption Standard
CON
Console, Primary terminal line
FTP
File Transfer Protocol
FTPS
FTP Secure
IETF
Internet Engineering Task Force
MAC
Message Authentication Code
NAP
Neighbor Access Protocol
NVT
Network Virtual Terminal
RSA
Revest, Shamir and Adleman
SFTP
Secure File Transfer Protocol
SSH
Secure Shell
SSL
Secure Socket Layer
TACACS
Terminal Access Controller Access Control System
Telnet
Telecommunication network protocol
TFTP
Trivial File Transfer Protocol
TTY
Terminal controller (A/S or SA)
VPN
Virtual Private Network
VRP
Versatile router platform

39

2 Fast Startup
Fast Startup
About This Chapter

2.1 Introduction to Fast Startup
2.2 References
2.3 Principles
2.4 Applications
Issue 03 (2013-08-15)

40

2 Fast Startup
2.1 Introduction to Fast Startup

Purpose
As the Internet develops, the demands for fast fault recovery are increasing. When faults occur
and devices must be restarted, the restart must be completed as quickly as possible in order to
minimize fault recovery time.
Because devices have appropriate fast startup routines for all types of fault recovery scenarios,
the startup routine a device uses depends on the type of fault. Choosing the appropriate startup
routine begins with the system software decision making center which chooses the routine based
on different kinds of fault recovery configurations, as shown in Figure 2-1.
Figure 2-1 Startup modes
Enable fast restart
Configuration file
Startup normally
Cold Startup
Hardware Fault
Restarting
judgement center
Software Fault
Fast startup
Software-based fast
startup
Benefits
This feature brings the following benefits to carriers:
l
Service down time caused by device faults is reduced.
Enhanced network reliability improves an operator's competitive position.
This feature brings the following benefits to users:

N/A.
2.2 References
None.
2.3 Principles
Issue 03 (2013-08-15)

41

2 Fast Startup
2.3.1 Fast Startup After a Software Fault

After a software fault occurs, the device monitoring process reports a software exception and
instructs the device management module to restart the device using a fast startup routine.
The Basic Input/Output System (BIOS) is not restarted during the process to reduce overall
startup time. Before the restart, the forwarding engine on the data forwarding plane stops traffic.
Applications on the control plane are restarted without fault detection. After the restart, the
forwarding engine on the data forwarding plane starts traffic once again.
2.3.2 Fast Startup After a Hardware Fault

After a hardware fault occurs, the device is restarted in hot startup mode. BootLoad restart is
not part of the startup process, reducing startup time.
2.3.3 Upgrade and Cold Startup

After a software or hardware upgrade, system firmware needs to be re-loaded. When the device
is powered on, the power-on-self-test is performed on all components simultaneously. Because
components do not have to perform a self-test one by one, overall startup time is reduced.
2.3.4 Performance Statistics for Software-based Fast Startup

No.
Item
Performance Statistics (in

Seconds)
Entire system
180
MPU
120
NPUI
120
2.4 Applications
None.

Terms
None.
Abbreviations
None.
Issue 03 (2013-08-15)

42

3 Clock Synchronization
Clock Synchronization
About This Chapter

3.1 Introduction
3.2 References
3.3 Principles
3.4 Application
Issue 03 (2013-08-15)

43

3.1 Introduction
Definition
Frequency synchronization, also called clock synchronization, allows one clock signal to pulse
at the same frequency as another clock signal, ensuring that all the devices on a communication
network share the same global time.
Purpose
Clock synchronization is a technology that limits the clock frequencies of digital network
elements (NEs) to a tolerable range. If the clock frequency of an NE is beyond the tolerable error
range, bit errors and jitter may occur, deteriorating networking transmission performance.
3.2 References
The following table lists the references of this feature.
Document No.
Document Name
ITU-T G.813
Timing characteristics of SDH equipment slave clocks (SEC)

(1996)
ITU-T O.172
Jitter and wander measuring equipment for digital systems which

are based on the synchronous digital hierarchy (SDH)
ITU-T G.781
Synchronization layer functions
ITU-T G.783
Characteristics of synchronous digital hierarchy (SDH) equipment

functional blocks
ITU-T G.8264
Distribution of timing information through packet switch networks
ITU-T G.704
Synchronous frame structures used at 1544, 6312, 2048, 8448 and

44 736 kbit/s hierarchical levels
ANSI T.101
Specifications for interface synchronization
3.3 Principles
3.3.1 Basic Concepts
Ethernet Clock Synchronization Technology
Ethernet clock synchronization technology is used to transmit clock signals over the physical
layer on the Ethernet network. A device has multiple Ethernet links and any Ethernet link can
Issue 03 (2013-08-15)

44

provide clock signals. The device can either select a manually specified Ethernet link or select
an Ethernet link by using the algorithm for selecting the reference clock source. The clock whose
signals are actually transmitted is the reference clock source The clock phase-locked loop (PLL)
traces the reference clock source to generate the system clock. The device then transmits clock
signals from the system clock to its downstream devices over Ethernet links.
Timing Loop
Over time, the precision of clocks on a network degrade due to a timing loop. In most situations,
all devices on a network synchronize their clocks from the same source. The device transmits a
clock signal to its downstream devices, and the downstream devices transmit the clock signal to
their downstream devices until the clock signal reaches every device on the network. Lastly the
clock signal returns to the device that first imported the reference clock. By the time the device
synchronizes its clock with the clock signal, a timing loop has occurred. This loop results in a
gradual degradation of the precision of clocks on the network. Therefore, preventing timing
loops must be considered during network design.
Clock Source
A device that provides clock signals to a local device is called a clock source. A local device
may have multiple clock sources.
Clock sources are classified into the following types:
l
External clock source

The local device uses the clock interface provided by its clock board to search for a higher
level clock. External clock sources are classified into BITS0, BITS1, and PTP clock
sources, and support four types of signals: 2 MHz, 2 Mbit/s, dcls, and 1 pps.
Line clock source

The local device uses the clock board to extract clock signals from Synchronous Transport
Module Level N (STM-N) , Plesiochronous Digital Hierarchy (PDH) or Ethernet line
signals.
Internal clock source

The local device uses its own clock (for example, the clock provided by its clock board) as
the working clock for an interface.
SSM
The Synchronization Status Message (SSM), also called the synchronization quality message,
directly reflects transmission level of a synchronous timing signal.
SSMs can indicate clock source quality and are transmitted over Ethernet synchronization
messaging channels (ESMCs). The reference clock source of a device is determined by the SSM
clock source selection algorithm.
If SSMs are used for selecting a reference clock source, quality levels (QLs) of clock sources
are first compared. If the quality levels of two or more clock sources are the same, the priorities
of these clock sources are then compared. If SSMs are not used, the priorities of clock sources
are compared directly.
Issue 03 (2013-08-15)

45

Clock Working Mode

The working modes of clocks are classified into the following types:
l
Tracing state
The slave clock traces clock signals provided by the higher level clock. The clock signals
may be provided by either the master clock or the internal clock of the higher-level network
element (NE).
Free running state

After losing all external clock sources, the slave clock loses clock memory or remains in
the hold-in state for a long time. As a result, the oscillator inside the slave clock works in
the free running state.
Hold-in state
After losing all clock sources, the slave clock enters the hold-in state. The slave clock uses
the last clock source as its final reference clock source. Next, the slave clock adopts the
timing frequency similar to that of the last clock source to ensure that there is only a small
difference between the frequencies of the provided clock signals and those of the reference
clock source.
Priorities of Clock Sources

Priority order of information for reference clock source selection: SSM > Priority of clock source
> Clock source type
l
Priority order of SSM information for reference clock source selection: PRC > SSUA >
SSUB > SEC > DNU
Candidate reference clock sources must be configured with priorities. A clock source whose
quality level is DNU cannot be a candidate reference clock source.
Priority order of clock sources for reference clock source selection: 1 > 2 > ... > 254 > 255
A smaller priority value indicates a higher priority of a clock source.
Priority order of clock source types for reference clock source selection: BITS clock source
> Interface clock source > PTP clock source
Priority order of interface information for reference clock source selection: Slot ID > Card
ID > Interface ID
The interface name is in the format of slot ID/card ID/interface ID. The smaller the slot ID,
the higher the priority of the interface clock source. If slot IDs are the same, the smaller
the card ID, the higher the priority of the interface clock source. If card IDs are also the
same, the smaller the interface ID, the higher the priority of the interface clock source.
Threshold SSM Levels That a BITS External Clock Source Outputs

The SSM level output by the external clock source BITS0 is the SSM level of the clock source
that the 2M-1 PLL traces.
The SSM level output by the external clock source BITS1 is the SSM level of the clock source
that the 2M-2 PLL traces.
The threshold for SSM levels output by a BITS external clock refers to the lowest level that can
be output by the clock. If the BITS external clock outputs an SSM level that is below the
threshold, the clock signal will be blocked and an alarm will be reported.
Issue 03 (2013-08-15)

46

Selection of Clock Sources in Frequency Offset Detection and Non-frequency

Offset Detection Modes
A clock source can be selected in either frequency offset detection or non-frequency offset
detection mode.
l
In frequency offset detection mode, results are used for reference clock source selection.
In non-frequency offset detection mode, frequency offset detection is not performed on

clock sources.
Frequency offset detection results affect the selection of a system reference clock source, but do
not affect the selection of a reference clock source from a 2 M interface.
3.3.2 Clock Protection Switching

Overview
On a synchronization network, each device can trace the same clock source level by level through
clock synchronization paths to implement clock synchronization on the entire network. Usually,
each device has more than one path for tracing clock sources. These clock sources may originate
from either the same master clock or from reference clock sources of different qualities.
It is very important to keep the clocks of all devices synchronous. To prevent the entire network
from becoming faulty due to a faulty clock synchronization path, automatic protection switching
can be configured.
Implementation
l
Manually or forcibly specifying a reference clock source

Manually and forcibly specifying the reference clock source differ in the following ways:
When a clock source exhibits the following characteristics, you cannot manually specify
it to be a reference clock source:
The clock source is disabled. You cannot forcibly specify it to be the reference clock
source.
The clock source is in the Abnormal state or its QL is DNU. The system clock enters
the hold-in state.
The quality level (QL) of the clock source is DNU or is not highest among all clock
sources.
When a clock source is disabled, you cannot forcibly specify it to be the reference clock
source. When the reference clock source is in the Abnormal state or its QL is DNU, the
system clock enters the hold-in state.
Manually or forcibly specifying a reference clock source is used to designate a particular
and fixed clock source for a clock board to trace. The active and standby clock boards can
be configured to trace different clock sources.
As shown in Figure 3-1, on the master clock Router A, the active clock board has been
manually set to trace the BITS1 external clock and the standby clock board has been set to
trace the BITS2 external clock. Under normal circumstances, the master clock traces the
BITSI external clock. If the active clock board is faulty, a switchover occurs between the
active and standby clock boards. After the switchover, Router A traces the BITS2 external
clock, Router B traces the clock of Router A, and Router C traces the clock of Router B.
Issue 03 (2013-08-15)

47

The problem with this method is that all of the routers on the network are set to trace the
clock of Router A. If Router A is faulty, the entire network has no reference clock. All of
the routers are in the free oscillation state.
Figure 3-1 Networking diagram for manually specifying the reference clock source
BITS1
CLK-IN
POS
ATM
Router A
CLK-IN
Router B
Router C
BITS2
Protection switching based on the SSM level

The SSM is a group of codes used to indicate the quality level of clocks on a synchronization
network. At present, ITU-T specifies four bits for coding. These four bits are called the
Synchronous Status Message Byte (SSMB). Table 3-1 describes the SSM level codes
defined by ITU-T. These codes specify 16 levels of quality for synchronized sources.
Table 3-1 SSM Level Codes
QL
Coding
PRC
0100
SSUA
0100
SSUB
1000
SEC
1011
DNU
1111
The SSM levels are arranged in descending order as follows:

Primary Reference Clock (PRC) > Primary level SSU (SSU-A) > Second level SSU (SSUB) > SDH Equipment Clock (SEC) > Do not use for synchronization (DNU)
Candidate reference clock sources must be configured with SSM levels. A clock source
whose quality level is DNU cannot be a candidate reference clock source.
The SSM level of a line clock source can be extracted from a line processing unit (LPU)
and reported to the main processing unit (MPU). The MPU then sends the SSM level to
the clock board. The MPU can also forcibly set the SSM level of the line clock source.
NOTE
BITS clocks fall into two types: 2.048 Mbit/s and 2.048 MHz. If the BITS clock is 2.048 Mbit/s, the
clock module can extract the SSM level from clock signals. If the BITS clock is 2.048 MHz, you
need to manually specify the SSM level.
Issue 03 (2013-08-15)

48

Protection switching based on prioritized clock sources

When there are multiple lines of clock sources, you can configure different priorities for
sorting them out.
In normal situations, SSMs are not used for reference clock source selection, and a clock
board uses the clock source with the highest priority as the reference clock source. If the
clock source with the highest priority fails, the clock board uses the clock source with the
second highest priority. By default, priorities of clock sources are not set and therefore are
not used for reference clock source selection.
Boards Participating in Clock Protection Switching

Clock protection switching involves the following boards:
l
LPU
An LPU inserts and extracts the S1 byte. The S1 byte sent by the clock board is inserted
into the section overhead of the LPU. The S1 byte is then extracted from the section
overhead of the LPU and sent to the clock board for processing.
Clock board
A clock board extracts the SSM level from an external clock and implements protection
switching for the clock source. After receiving the SSM level sent by an LPU, the clock
board determines which clock source to trace based on the SSM level. The LPU implements
clock protection switching and sends the SSM level of the current clock source to other
LPUs.
Clock Source Selection in Either Recovery or Non-recovery Switching Mode

A clock source can be selected in either recovery switching or non-recovery switching mode.
l
In the recovery switching mode, the selector selects the optimal clock source as the
reference by using the reference clock source selection algorithm.
In non-recovery switching mode, the slave reference clock source is selected. If this
reference cannot be not found, the non-recovery switching mode changes to the recovery
switching mode.
3.3.3 Synchronization Mode and Issues of Concern

There are two ways to synchronize digital communications networks:
l
Pseudo synchronization
Master/slave synchronization
Pseudo Synchronization
Pseudo synchronization refers to situations in which each switching site has its own highly
accurate and highly stable independent clock. The clocks of the switching sites are not
synchronized. Differences in clock frequency and phasing between different switching sites are,
however, very small. They do not affect data transmissions and can be ignored.
Pseudo synchronization is generally used when digital communications networks from different
countries interact. Most countries make use of cesium clocks on their networks.
Issue 03 (2013-08-15)

49

Master/Slave Synchronization
Master/slave synchronization refers to situations in which a highly accurate clock is set as the
internal master clock for a network. Clocks at all sites within the network trace the master clock.
Each sub-site traces a higher level clock until the highest level network element is reached.
There are two types of master/slave synchronization:
l
Direct master/slave synchronization
Level-based master/slave synchronization
Figure 3-2 shows direct master/slave synchronization. All of the slave clocks synchronize
directly with the primary reference clock. Direct master/slave synchronization is used on
networks with relatively simple structures.
Figure 3-2 Direct master/slave synchronization
Primary
reference clock
Slave clock
Slave clock
Slave clock
Figure 3-3 shows level-based master/slave synchronization. Devices on the network are divided
into three levels. Level two clocks synchronize with the level one reference clock. Level three
clocks synchronize with level two clocks. Level-based master/slave synchronization is used on
networks that are larger scale and have more complicated structures.
Figure 3-3 Level-based master/slave synchronization
Level-1 reference clock
Level-2 slave clock
Level-3 slave clock
Issue 03 (2013-08-15)

50

Master/slave synchronization is generally used to synchronize a country's domestic digital

communications network or internal regional networks. The national digital communications
network or regional network has a highly accurate master clock. Other network elements on the
national or regional network use the master clock as the reference clock.
To improve the reliability of master/slave synchronization, two master clocks are set on the
network. There is an active master clock and a standby master clock. Both are cesium clocks.
Under normal circumstances, each network element traces the master clock The standby master
clock also traces the master clock. If the active master clock is faulty, the standby master clock
takes over and becomes the reference clock for the entire network. After the fault is repaired and
the master clock recovers, there is a switchover. The original active master clock becomes active
again and serves as the reference clock.
3.3.4 Networking Mode for Clock Synchronization

Transmitting Clock Signals Through a Clock Interface
A clock interface provided by a clock board exports the clock of the network element where the
board is located to other SDH network elements.
The MPU of the NE40E provides two BITS input clocks. A clock board has four clock interfaces:
l
Two input clock interfaces: obtain clock signals by connecting to the synchronized network.
Two output clock interfaces: provide downstream devices with clock signals by connecting
to downstream input clock interfaces.
As shown in Figure 3-4, Router A traces the BITS clock and uses clock cables to connect the
clock output interface of Router A with that of Router B. Router B and Router C are also
connected through clock cables. Router C traces the clock of Router B and, finally, all three
router are synchronized with the BITS clock.
Figure 3-4 Transmitting clock signals through a clock interface
BITS
CLK-IN
CLK-IN
CLK-OUT
Router A
CLK-IN
CLK-OUT
Router B
Router C
The networking previously described can only be used to connect devices at the same site. The
distance between the router cannot exceed 200 meters.
Transmitting Clock Signals Through an Ethernet/SDH/PDH Link

A synchronized Ethernet network can transmit clock signals. The system uses a clock module
(clock board) to transmit a high-precision system clock to all Ethernet/SDH/PDH interface cards.
The Ethernet/SDH/PDH interfaces then use this high-precision clock as the basis for data
transmissions. On the receiver side, the Ethernet/SDH/PDH interface decodes the synchronized
Issue 03 (2013-08-15)

51

clock information and, after frequency division, sends it to the clock board. The clock board
judges the quality of the clocks reported by the interfaces, selects the most precise one, and
synchronizes the system clock to that clock.
To select the source correctly and perform clock link protection, SSMs must be transmitted along
with clock information. On SDH networks, clock levels are differentiated by the outbound
overhead byte in the SDH. An Ethernet network has no outbound channel, so the SSM domain
of Ethernet OAM is used to provide downstream devices with clock level information. On SDH
networks, SSM levels are transmitted using sa4 to sa8 bits of the TS0 timeslot.
As shown in Figure 3-5, Router A traces the BITS clock. There is a link connecting Router A
and Router B. Router B and Router C are connected through Ethernet links. Router C traces the
clock of Router B. Finally, clocks of all three router synchronize with the BITS clock.
Figure 3-5 Transmitting clock signals through an Ethernet link
BITS
CLK-IN
Ethernet
Router A
Ethernet
Router C
Router B
3.4 Application
Link Network Topology
As shown in Figure 3-6, Router B and the external clock device are connected. Router B serves
as the master clock station for the network. The external clock of Router B serves as the reference
clock for this station and for the network. Router B stores clock information in code streams on
Ethernet or SDH/PDH lines.
Figure 3-6 Networking diagram of a link network topology
External clock
E
Router A
Issue 03 (2013-08-15)
Router B
Router C
W
Router D

52

NOTE
In all of the networking diagrams for this chapter, W represents the westbound interface, and E represents
the eastbound interface.
The clock board on Router A serves as the local clock source for its network element (NE),
extracting clock information from code streams on Ethernet or SDH/PDH lines received at the
eastbound interface. The clock board on Router C also acts as the local clock source for its NE,
extracting clock information from code streams on Ethernet or SDH/PDHlines received at the
westbound interface. At the same time, clock information is attached to code streams on Ethernet
or SDH/PDH lines and these code streams are transmitted downstream to Router D. Router D
receives these code streams at the westbound interface and uses the clock information extracted
as a reference point to complete clock synchronization with the master clock station Router B.
Performance degradation of the clock on Router A will not affect the clocks on Router C and
Router D, but performance deterioration of the clock on Router C can affect the Router D clock
because Router D traces its clock through the higher level device, Router C.
Lower level NEs trace clock information stored in Ethernet or SDH/PDH through higher-level
NEs, regardless of the working modes being used by the higher level devices. If the performance
of clocks on Router B deteriorates, clock performance for the whole network will deteriorate.
If a link is very long, clock signals transmitted to a slave clock station must be transmitted a long
distance or divided into several transmissions. To ensure that slave clock stations receive high
quality clock signals, two master clocks can be set on the network to act as reference clocks.
NEs can trace either of these reference clocks. The two reference clocks must maintain
synchronization and be at the same quality level.
Ring Network Topology

As shown in Figure 3-7, Router A is the master clock station in this topology. It uses an external
clock source as its local clock and as the reference clock for this network. Other NEs trace the
clock from Router A. Clock tracing method of the slave clock station is the same as that of the
link network. The difference lies in that the slave clock station can extract clock information
from the code streams on Ethernet or SDH/PDH lines received by two interfaces. It is
recommended that the slave clock station extract clock information from the interface with the
shortest route and least transfer times. For example, Router E traces the clock through the
westbound interface and Router C traces the clock through the eastbound interface.
Issue 03 (2013-08-15)

53

Figure 3-7 Networking diagram of a ring network topology
External clock source
W
E
Router A
Router B
Router F
W
Router C
W
Router E
E
Router D
E
Mixed Topology
As shown in Figure 3-8, Router A, Router B, Router C, and Router D form a ring network
topology. Router D and Router E form a link network topology.
Serving as the master clock station, Router E uses an external clock source as the reference clock
for all the router on the network. Router E and Router D are connected by means of a low-speed
link.
Figure 3-8 Networking diagram of a mixed topology
Router A
STM-N
E
W
Router B
Router D
Router E
Router C
E
Issue 03 (2013-08-15)

54

Router A, Router B, and Router C use both eastbound and westbound interfaces to trace and
lock the clock of Router D. This Router D clock traces the clock transmitted by the master clock
station Router E. Router D extracts clock information from the STM-N signals transmitted by
Router E and uses this information to synchronize with the downstream router.
Issue 03 (2013-08-15)
Abbreviation
Full Name
AIS
Alarm Indication Signal
DNU
Do Not Use
PRC
Primary Reference Clock
QL
Quality Level
SEC
SDH Equipment Clock
SF
Signal Fail
SSM
Synchronization Status Message
SSU
Synchronization Supply Unit

55

4 1588 ACR
1588 ACR
About This Chapter

4.1 Introduction to 1588 ACR
4.2 References
4.3 Enhancement
4.4 Principles
4.5 Applications
4.6 Terms and Abbreviations
Issue 03 (2013-08-15)

56

4 1588 ACR
4.1 Introduction to 1588 ACR

Definition
The 1588 adaptive clock recovery (ACR) algorithm is used to carry out clock (frequency)
synchronization between the router and clock servers by exchanging 1588v2 messages over a
clock link that is set up by sending Layer 3 unicast packets.
Unlike 1588v2 that achieves frequency synchronization only when all devices on a network
support 1588v2, 1588 ACR is capable of implementing frequency synchronization on a network
with both 1588v2-aware devices and 1588v2-unaware devices.
After 1588 ACR is enabled on a server, the server provides 1588 ACR frequency synchronization
services for clients.
Purpose
All-IP has become the trend for future networks and services. Therefore, traditional networks
based on the Synchronous Digital Hierarchy (SDH) have to overcome various constraints before
migrating to IP packet-switched networks. Transmitting Time Division Multiplexing (TDM)
services over IP networks presents a major technological challenge. TDM services are classified
into two types: voice services and clock synchronization services. With the development of
VoIP, technologies of transmitting voice services over an IP network have become mature and
have been extensively used. However, development of technologies of transmitting clock
synchronization services over an IP network is still under way.
1588v2 is a software-based technology that carries out time and frequency synchronization. To
achieve higher accuracy, 1588v2 requires that all devices on a network support 1588v2; if not,
frequency synchronization cannot be achieved.
Derived from 1588v2, 1588 ACR implements frequency synchronization with clock servers on
a network with both 1588v2-aware devices and 1588v2-unaware devices. Therefore, in the
situation where only frequency synchronization is required, 1588 ACR is more applicable than
1588v2.
Benefits
This feature brings the following benefits to operators:
l
Frequency synchronization can be achieved on networks with both 1588v2-aware and

1588v2-unaware devices, reducing the costs of network construction.
Operators can provide more services that can meet subscribers' requirements for frequency
synchronization.
4.2 References
The following table lists the references of this document.
Issue 03 (2013-08-15)

57

4 1588 ACR
Document
Description
Remarks
IEEE
1588-2008
Precision Clock Synchronization Protocol for

Networked Measurement and Control Systems
ITU-T G.813
Timing characteristics of SDH equipment slave

clocks (SEC)
ITU-T G.823
The control of jitter and wander within digital

networks which are based on the 2048 kbit/s
hierarchy
ITU-T G.824
The control of jitter and wander within digital

networks which are based on the 1544 kbit/s
hierarchy
ITU-T G.8261
Timing and Synchronization Aspects in Packet

Networks
4.3 Enhancement
None.
4.4 Principles
4.4.1 Basic Principles of 1588 ACR
1588 ACR aims to synchronize frequencies of routers (clients) with those of clock servers
(servers) or router (Client) and router(Server).
1588 ACR sends Layer 3 unicast packets to establish a clock link between a client and a server
to exchange 1588v2 messages. 1588 ACR obtains a clock offset by comparing timestamps
carried in the 1588v2 messages, which enables the client to synchronize frequencies with the
server.
Process of 1588 ACR Clock Synchronization

1588 ACR implements clock (frequency) synchronization by adjusting time differences between
the time when the server sends 1588v2 messages and the time when the client receives the 1588v2
messages over a link that is established after negotiations. The detailed process is described as
follows:
1588 ACR clock synchronization is implemented in two modes: one-way mode and two-way
mode.
l
Issue 03 (2013-08-15)
One-way mode

58

4 1588 ACR
Figure 4-1 Clock synchronization in one-way mode
Server clock
Client clock
Data obtained
by the client
clock
t1
t2
t1
t1'
t2'
t2
t1'
t2'
1.
The server sends the client 1588v2 messages at t1 and t1' and time-stamps the
messages with t1 and t1'.
2.
The client receives the 1588v2 messages at t2 and t2' and time-stamps the messages
with t2 and t2'.
t1 and t1' are the clock time of the server, and t2 and t2' are the clock time of the client.
By comparing the sending time on the server and the receiving time on the client, 1588
ACR calculates a frequency offset between the server and client and then implements
frequency synchronization. For example, if the result of the formula (t2 - t1)/(t2' - t1') is 1,
frequencies on the server and client are the same; if not, the frequency of the client needs
to be adjusted so that it is the same as the frequency of the server.
l
Two-way mode
Figure 4-2 Clock synchronization in two-way mode
Client clock
Server clock
t1
Data obtained
by the client
clock
Sync
Delay_Req
t2
t1
t2
t3
t1
t2
t3
t4
t5
Delay_Resp
Issue 03 (2013-08-15)
t1 t2 t3 t4

59

4 1588 ACR
1.
The server clock sends a 1588 sync packet carrying a timestamp t1 to the client server
at t1.
2.
The client server receives a 1588 sync packet from the server clock at t2.
3.
The client clock sends a 1588 delay_req packet to the server clock at t3.
4.
The server clock receives the 1588 delay_req packet from the client clock at t4, and
sends a delay_resp packet to the slave clock.
The same calculation method is used in two-way and one-way modes. t1 and t2 are compared
with t3 and t4. A group of data with less jitter is used for calculation. In the same network
conditions, the clock signals with less jitter in one direction can be traced, which is more precise
than clock signal tracing in one direction.
Layer 3 Unicast Negotiation Mechanism

Layer 3 unicast negotiations can be enabled to carry out 1588 ACR frequency synchronization
as required. The principle of Layer 3 unicast negotiations is as follows:
A client initiates a negotiation with a server in the server list by sending a request to the server.
After receiving the request, the server replies with an authorization packet, implementing a 2way handshake. After the handshake is complete, the client and server exchange Layer 3 unicast
packets to set up a clock link, and then exchange 1588v2 messages over the link to achieve
frequency synchronization.
Dual-Server Protection Mechanism

1588 ACR supports the configuration of double servers. Dual server protection is performed as
follows:
After triggering a negotiation with one server, a client periodically queries the negotiation result.
If the client detects that the negotiation fails, it automatically negotiates with another server.
Alternatively, if the client successfully synchronizes with one server and detects that the
negotiation status changes due to a server failure, the client automatically negotiates with another
server. This dual server protection mechanism ensures uninterrupted communications between
the server and the client.
When only one server is configured, the client re-attempts to negotiate with the server after a
negotiation failure. This allows a client to renegotiate with a server that is only temporarily
unavailable in certain situations, such as when the server fails and then recovers or when the
server is restarted.
Duration Mechanism
On a 1588 ACR client, you can configure a duration for Announce, Sync, and delay_resp packets.
The duration value is carried in the TLV field of a packet for negotiating signaling and sent to
a server.
Generally, the client sends a packet to renegotiate with the server before the duration times out
so that the server can continue to provide the client with synchronization services.
If the link connected to the client goes Down or fails, the client cannot renegotiate with the
server. When the duration times out, the server stops sending Sync packets to the client.
Issue 03 (2013-08-15)

60

4 1588 ACR
4.5 Applications
Typical Applications of 1588 ACR
On an IP RAN shown in Figure 4-3, NodeBs need to implement only frequency synchronization
rather than phase synchronization; devices on an MPLS backbone network do not support
1588v2; the RNC-side device is connected to an IPCLK server; closed subscriber groups (CSGs)
support 1588 ACR.
NodeB1 transmits wireless services along an E1 link to a CSG, and NodeB2 transmits wireless
services along an Ethernet link to the other CSG.
Figure 4-3 Networking diagram of 1588 ACR applications on a network
BITS1
RSG1
E1
RNC
CSG
NodeB1
MPLS
Backbone
FE
RSG2
NodeB2
BITS2
1588v 2 packet
line clock signal
NodeB service
On the preceding network, CSGs support 1588 ACR and function as clients to initiate requests
for Layer 3 unicast connections to the upstream IPCLK server. The CSGs then exchange
1588v2 messages with the IPCLK server over the connections, achieving frequency recovery.
RSG1 and RSG2 are configured as clock servers for the CSGs to provide protection.
One CSG sends line clock signals carrying frequency information to NodeB1 along an E1 link.
The other CSG transmits NodeB2 frequency information either along a synchronous Ethernet
link or by sending 1588v2 messages. In this manner, both NodeBs connected to the CSGs can
achieve frequency synchronization.
Issue 03 (2013-08-15)

61

4 1588 ACR

Terms
Term
Description
Synchronizati
on
On a modern communications network, in most cases, the proper functioning

of telecommunications services requires network clock synchronization,
meaning that the frequency offset or time difference between devices must
be kept in an acceptable range. Network clock synchronization includes
frequency synchronization and time synchronization.
Time
synchronizati
on
Time synchronization, also called phase synchronization, refers to the

consistency of both frequencies and phases between signals. This means that
the phase offset between signals is always 0.
Frequency
synchronizati
on
Frequency synchronization, also called clock synchronization, refers to a

strict relationship between signals based on a constant frequency offset or a
constant phase offset, in which signals are sent or received at the same
average rate in a valid instance. In this manner, all devices on the
communications network operate at the same rate. That is, the phase
difference between signals remains a fixed value.
IEEE 1588v2
1588v2, defined by the Institute of Electrical and Electronics Engineers

(IEEE), is a standard for Precision Clock Synchronization Protocol for
Networked Measurement and Control Systems. The Precision Time
Protocol (PTP) is used for short.
PTP
Abbreviations
Abbreviation
Full Spelling
PTP
Precision Time Protocol
1588v2
Issue 03 (2013-08-15)
BITS
Building Integrated Time Supply System
BMC
Best Master Clock
ACR
Adaptive Clock Recovery

62

5 1588v2
1588v2
About This Chapter

5.1 Introduction to 1588v2
5.2 References
5.3 Principles
5.4 Application Environment
Issue 03 (2013-08-15)

63

5 1588v2
5.1 Introduction to 1588v2

Definition
l
Synchronization
This is the process of ensuring that the frequency offset or time difference between devices
is kept within a reasonable range. In a modern communications network, most
telecommunications services require network clock synchronization in order to function
properly. Network clock synchronization includes time synchronization and frequency
synchronization.
Time synchronization
Time synchronization, also called phase synchronization, means that both the frequency
of and the time between signals remain constant. In this case, the time offset between
signals is always 0.
Frequency synchronization
Frequency synchronization, also called clock synchronization, refers to a constant
frequency offset or phase offset. In this case, signals are transmitted at a constant average
rate during any given time period so that all the devices on the network can work at the
same rate.
Figure 5-1 Schematic diagram of time synchronization and frequency synchronization
Phase synchronization
Watch A
Watch B
Frequency synchronization
Watch A
Watch B
Figure 5-1 shows the differences between time synchronization and frequency
synchronization. If Watch A and Watch B always have the same time, they are in time
Issue 03 (2013-08-15)

64

5 1588v2
synchronization. If Watch A and Watch B have different time, but the time offset remains
constant, for example, 6 hours, they are in frequency synchronization.
l
IEEE 1588
IEEE 1588 is defined by the Institute of Electrical and Electronics Engineers (IEEE) as
Precision Clock Synchronization Protocol (PTP) for networked measurement and control
systems. It is called the Precision Time Protocol (PTP) for short.
IEEE 1588v1, released in 2002, applies to industrial automation and tests and
measurements fields. With the development of IP networks and the popularization of 3G
networks, the demand for time synchronization on telecommunications networks has
increased. To satisfy this need, IEEE drafted IEEE 1588v2 based on IEEE 1588v1 in June
2006, revised IEEE 1588v2 in 2007, and released IEEE 1588v2 at the end of 2008.
Targeted at telecommunications industry applications, IEEE 1588v2 improves on IEEE
1588v1 in the following aspects:
Encapsulation of Layer 2 and Layer 3 packets has been added.
The transmission rate of Sync messages is increased.
A transparent clock (TC) model has been developed.
Hardware timestamp processing has been defined.
Time-length-value (TLV) extension is used to enhance protocol features and functions.
1588v2 is a time synchronization protocol which allows for highly accurate time
synchronization between devices. It is also used to implement frequency synchronization
between devices.
Purpose
Data communications networks do not require time or frequency synchronization and, therefore,
routers on such networks do not need to support time or frequency synchronization. On IP radio
access networks (RANs), time or frequency needs to be synchronized among base transceiver
stations (BTSs). Therefore, routers on IP RANs are required to support time or frequency
synchronization.
Frequency synchronization between BTSs on an IP RAN requires that frequencies between BTSs
be synchronized to a certain level of accuracy; otherwise, calls may be dropped during mobile
handoffs. Some wireless standards require both frequency and time synchronization. Table
5-1 shows the requirements of wireless standards for time synchronization and frequency
accuracy.
Table 5-1 Requirements of wireless standards for time synchronization and frequency accuracy
Issue 03 (2013-08-15)
Wireless Standards
Requirement for
Frequency Accuracy
Requirement for Time

Synchronization
GSM
0.05 ppm
NA
WCDMA
0.05 ppm
NA
TD-SCDMA
0.05 ppm
3us
CDMA2000
0.05 ppm
3us
WiMax FDD
0.05 ppm
NA

65

5 1588v2
Wireless Standards
Requirement for
Frequency Accuracy
Requirement for Time

Synchronization
WiMax TDD
0.05 ppm
1us
LTE
0.05 ppm
In favor of time
synchronization
Different BTSs have different requirements for frequency synchronization. These requirements
can be satisfied through physical clock synchronization (including external clock input, WAN
clock input, and synchronous Ethernet clock input) and packet-based clock recovery (including
CES ACR/DCR and 1588v2).
Traditional packet-based clock recovery cannot meet the time synchronization requirement of
BTSs. For example, NTP-based time synchronization is only accurate to within one second and
1588v1-based time synchronization is only accurate to within one millisecond. To meet time
synchronization requirements, BTSs need to be connected directly to a global positioning system
(GPS). This solution, however, has some disadvantages such as GPS installation and
maintenance costs are high and communications may be vulnerable to security breaches because
a GPS uses satellites from different countries.
1588v2, with hardware assistance, provides time synchronization accuracy to within one micro
second to meet the time synchronization requirements of wireless networks. Thus, in comparison
with a GPS, 1588v2 deployment is less costly and operates independently of GPS, making
1588v2 strategically significant.
In addition, operators are paying more attention to the operation and maintenance of networks,
requiring routers to provide network quality analysis (NQA) to support high-precision delay
measurement at the 100 us level. Consequently, high-precision time synchronization between
measuring devices and measured devices is required. 1588v2 meets this requirement.
1588v2 packets are of the highest priority by default to avoid packet loss and keep clock
precision.
Benefits
This feature brings the following benefits to operators:
l
Construction and maintenance costs for time synchronization on wireless networks are
reduced.
Time synchronization and frequency synchronization on wireless networks are independent

of GPS, providing a higher level of strategic security.
High-accuracy NQA-based unidirectional delay measurement is supported.
5.2 References
The following lists the references of this document:
l
Issue 03 (2013-08-15)
IEEE 1588-2008: Precision Clock Synchronization Protocol for Networked Measurement

and Control Systems
66

5 1588v2
ITU-T G.813: Timing requirements of SDH equipment slave clocks (SEC)
ITU-T G.823: The control of jitter and wander within digital networks which are based on
the 2048 kbit/s hierarchy
ITU-T G.824: The control of jitter and wander within digital networks which are based on
the 1544 kbit/s hierarchy
ITU-T G.8261: Timing and Synchronization aspects in Packet Networks
ITU-T G.8265.1: Precision time protocol telecom profile for frequency synchronization
5.3 Principles
Clock Domain
Logically, a physical network can be divided into multiple clock domains. Each clock domain
has a reference time with which all devices in the domain are synchronized. Each clock domain
has its own reference time and these times are independent of one another.
A device can transparently transmit time signals from multiple clock domains over a bearer
network to provide specific reference times for multiple mobile operator networks. The device,
however, can join only one clock domain and can synchronize only with the synchronization
time of that clock domain.
Clock Node
Each node on a time synchronization network is a clock. The 1588v2 protocol defines the
following types of clocks:
l
Ordinary clock
An ordinary clock (OC) has only one 1588v2 clock interface (a clock interface enabled
with 1588v2) through which the OC synchronizes with an upstream node or distributes
time signals to downstream nodes.
Boundary clock
A boundary clock (BC) has multiple 1588v2 clock interfaces, one of which is used to
synchronize with an upstream node. The other interfaces are used to distribute time signals
to downstream nodes.
The following is an example of a special case: If a router obtains the standard time from a
BITS through an external time interface (which is not enabled with 1588v2) and then
distributes time signals through two 1588v2 enabled clock interfaces to downstream nodes,
this router is a BC node, as it has more than one 1588v2 clock interface.
Transparent clock
A transparent clock (TC) does not synchronize the time with other devices (unlike BCs and
OCs) but has multiple 1588v2 clock interfaces through which it transmits 1588v2 messages
and corrects message transmission delays.
TCs are classified into end-to-end (E2E) TCs and peer-to-peer (P2P) TCs.
l
Issue 03 (2013-08-15)
TC+OC
67

5 1588v2
A TC+OC is a special TC, which has the functions of both the TC and OC. On interfaces
having TC attributes, the TC+OC can transparently transmit 1588v2 messages and correct
message transmission delays. On interfaces having OC attributes, the TC+OC performs
frequency synchronization, but does not implement time synchronization.
As mentioned before, the TC corrects for transmission delays of its 1588v2 messages. If
the times on the inbound and outbound interfaces of the TC are synchronous, the message
transmission delay is determined by subtracting the time of the 1588v2 message's arrival
at the inbound interface from the time of departure at the outbound interface. If the clocks
of the TC and the BC or OC with which the TC synchronizes are asynchronous, the obtained
message transmission delay is inaccurate, causing a time offset in the BC or OC time
synchronization. As a result, the time synchronization's accuracy may be degraded.
To ensure accuracy, it is recommended that frequency synchronization between the TC and
the BC or OC be implemented through a physical clock, such as a WAN clock or
synchronous Ethernet clock. If no such physical clock is available, the TC needs to use
1588v2 Sync messages sent periodically to restore frequency and to realize time
synchronization with an upstream device.
TC+OCs are classified into E2E TC+OCs and P2P TC+OCs.
Figure 5-2 shows the location of the TC, OC, and TC+OC on a time synchronization network.
Figure 5-2 Location of the TC, OC, and TC+OC on a time synchronization network
BC1
Grandmaster clock
TC1
OC1
TC2
OC2
BC2
BC3
Cyclic path
TC3
OC3
TC4
OC4
OC5
OC6
Time Source Selection

On a 1588v2 time synchronization network, all clocks are organized into a master-slave
synchronization hierarchy with the Grandmaster (GM) clock at the top. This topology can be
statically configured or automatically generated by 1588v2 using the Best Master Clock (BMC)
algorithm.
1588v2 Announce messages are used to exchange time source information, including
information about the priority level of the GM, time strata, time accuracy, distance, and hops to
Issue 03 (2013-08-15)

68

5 1588v2
the GM between clocks. After this information has been gathered, one of the clock nodes is
selected to be the GM, the interface to be used for transmitting clock signals issued by the GM
is selected, and master and slave relationships between nodes are specified. A loop-free and fullmeshed GM-rooted spanning tree is established after completion of the process.
If a master-slave relationship has been set up between two nodes, the master node periodically
sends Announce messages to the slave node. If the slave node does not receive an Announce
message from the master node within a specified period of time, it terminates the current masterslave relationship and finds another interface with which to establish a new master-slave
relationship.
Clock Modes of a 1588v2-enabled Device

l
OC
BC
TC
E2ETC
P2PTC
E2ETCOC
P2PTCOC
TCandBC
Encapsulation Modes of a 1588v2 Packet

A 1588v2 packet can be encapsulated in either MAC or UDP mode:
l
In MAC encapsulation, VLAN IDs and 802.1p priorities are carried in 1588v2 packets.
MAC encapsulation is classified into two types:
Unicast encapsulation
Multicast encapsulation
In UDP encapsulation, Differentiated Service CodePoint (DSCP) values are carried in

1588v2 packets. UDP encapsulation is classified into two types:
Unicast encapsulation
Multicast encapsulation
Supported Link Types

Theoretically, 1588v2 supports all types of links, but at present it has only been defined for
encapsulation and implementation on Ethernet links and thus the NE40E supports only Ethernet
links.
Grandmaster
A time synchronization network is like a GM-rooted spanning tree. All other nodes synchronize
with the GM.
Issue 03 (2013-08-15)

69

5 1588v2
Master/Slave
When a pair of nodes perform time synchronization, the upstream node distributing the reference
time signals is the master node and the downstream node receiving the reference time signals is
the slave node.
5.3.2 Principle of Synchronization

The principles of 1588v2 time synchronization and NTP are the same. The master and slave
nodes exchange timing messages, and calculate the message transmission delays in two
directions (sending and receiving) according to the receiving and sending timestamps in the
exchanged timing messages. If the message transmission delays in two directions are identical,
the message transmission delay in one direction (the time offset between the slave and master
nodes) equals the delays in two directions divided by 2. Then, the slave node synchronizes with
the master node by correcting its local time according to the time offset.
In practice, the delay and jitter on the network need to be taken into account, and the sending
and receiving delays are not always identical. Therefore, message-based time synchronization,
namely, 1588v2 and NTP, cannot guarantee high synchronization accuracy. For example, NTP
can only provide the synchronization accuracy of 10 to 100 ms.
1588v2 and NTP differ in implementation.
NTP runs at the application layer, for example, on the MPU of the NE40E. The delay measured
by NTP, in addition to the link delay, includes various internal processing delays, such as the
internal congestion queuing, software scheduling, and software processing delays. These make
the message transmission delay unstable, causing message transmission delays in two directions
to be asymmetric. As a result, the accuracy of NTP-based time synchronization is low.
1588v2 presumes that the link delay is constant or changes so slowly that the change between
two synchronization processes can be ignored, and the message transmission delays in two
directions on a link are identical. Messages are time-stamped for delay measurement at the
physical layer of the LPU. This ensures that time synchronization based on the obtained link
delay is extremely accurate.
1588v2 defines two modes for the delay measurement and time synchronization mechanisms,
namely, Delay and Peer Delay (PDelay).
Delay Mode
The Delay mode is applied to end-to-end (E2E) delay measurement. Figure 5-3 shows the delay
measurement in Delay mode.
Issue 03 (2013-08-15)

70

5 1588v2
Figure 5-3 E2E delay measurement in Delay mode
Master
time
Slave
time
Timestamps
known by slave
t1
Syn
t-ms
t2
Follow_Up
Delay_Req
t-sm
t2
t1, t2
t3
t1, t2, t3
t4
Delay_Resp
t1, t2, t3, t4
NOTE
As shown in Figure 5-3, t-sm and t-ms represent the sending and receiving delays respectively and are
presumed to be identical. If they are different, they should be made identical through asymmetric delay
correction. For details about asymmetric delay correction, see the following part of this section.
Follow_Up messages are used in two-step mode. Only the one-step mode is described in this part and
Follow_UP messages are not mentioned. For details about the two-step mode, see the following part of
this section.
A master node periodically sends a Sync message carrying the sending timestamp t1 to the slave
node. When the slave node receives the Sync message, it time-stamps t2 to the message.
The slave node periodically sends the Delay_Req message carrying the sending timestamp t3 to
the master node. When the master node receives the Delay_Req message, it time-stamps t4 to
the message and returns a Delay_Resp message to the slave node.
The slave node receives a set of timestamps, including t1, t2, t3, and t4. Other elements affecting
the link delay are ignored.
The message transmission delays of the link between the master and slave nodes in two directions
equal (t4 - t1) - (t3 - t2). If the message transmission delays between both nodes are identical,
the message transmission delay in one direction is equal to [(t4 - t1) - (t3 - t2)]/2.
The time offset between the master and slave nodes equals [(t2-t1)+(t4-t3)]/2.
Based on the time offset, the slave node synchronizes with the master node.
As shown in Figure 5-4, time synchronization is repeatedly performed to ensure constant
synchronization between the master and slave nodes.
Issue 03 (2013-08-15)

71

5 1588v2
Figure 5-4 Networking diagram of the directly-connected BC and OC
BC
Master
t1
OC
Slave
Sync
t2
DelayReq
t3
t4
DelayResp
The BC and OC can be directly connected as shown in Figure 5-4. Alternatively, they can be
connected through other devices, but these devices must be TCs to ensure the accuracy of time
synchronization. The TC only transparently transmits 1588v2 messages and corrects the message
transmission delay (which requires that the TC identify these 1588v2 messages).
To ensure the high accuracy of 1588v2 time synchronization, it is required that the message
transmission delays in two directions between master and slave nodes be stable. Usually, the
link delay is stable but the transmission delay on devices is unstable. Therefore, if two nodes
performing time synchronization are connected through forwarding devices, the time
synchronization accuracy cannot be guaranteed. The solution to the problem is to perform the
transmission delay correction on these forwarding devices, which requires that the forwarding
devices be TCs.
Figure 5-5 shows how the transmission delay correction is performed on a TC.
Issue 03 (2013-08-15)

72

5 1588v2
Figure 5-5 Schematic diagram of the transmission delay correction on a TC

Message at ingress
Message at egress
Network
PTP message payload
protocol Preamble
correctionField
headers
Event message payload Network

protocol Preamble
correctionField
headers
+
Ingress timestamp
Ingress
+
+
Engress timestamp
Egress
Residence time bridge
The TC performs the transmission delay correction by adding the time it takes to transmit the
message to the Correction field of a 1588v2 message. This means that the TC deducts the
receiving timestamp of the 1588v2 message on its inbound interface and adds the sending
timestamp to the 1588v2 message on its outbound interface.
In this manner, the 1588v2 message exchanged between the master and slave nodes, when
passing through multiple TCs, carry message transmission delays of all TCs in the Correction
field. When the value of the Correction field is deducted, the value obtained is the link delay,
ensuring high accuracy time synchronization.
A TC that records the transmission delay from end to end as described above is the E2E TC.
Time synchronization in Delay mode can be applied only to E2E TCs. Figure 5-6 shows how
the BC, OC, and E2E TC are connected and how 1588v2 operates.
Figure 5-6 Networking diagram of the BC, OC, and E2E TC and the 1588v2 operation
BC
Master
t1
E2E
TC
OC
Slave
Sync
correction
t2
t3
correction
t4
DelayResp
Issue 03 (2013-08-15)

73

5 1588v2
PDelay Mode
When performing time synchronization in PDelay mode, the slave node deducts both the
message transmission delay and upstream link delay. This requires that adjacent devices perform
the delay measurement in PDelay mode to enable each device on the link to know its upstream
link delay. Figure 5-7 shows the delay measurement in PDelay mode.
Figure 5-7 Schematic diagram of the delay measurement in PDelay mode
Node 1
time
Node 2
time
t1
Pdelay_Req
t-ms
t2
t3
Pdelay_Resp
t-sm
t4
Pdelay_Resp_Follow_Up
NOTE
As shown in Figure 5-3, t-sm and t-ms represent the sending and receiving delays respectively and are
presumed to be identical. If they are different, they should be made identical through asymmetric delay
correction. For details of asymmetric delay correction, see the following part of this section.
Follow_Up messages are used in two-step mode. In this part, the one-step mode is described and Follow_UP
messages are not mentioned. For details of the two-step mode, see the following part of this section.
Node 1 periodically sends a PDelay_Req message carrying the sending timestamp t1 to node 2.
When the PDelay_Req message is received, node 2 time-stamps t2 to the PDelay_Req message.
Then, node 2 sends a PDelay_Resp message carrying the sending timestamp t3 to node 1. When
the PDelay_Resp message is received, node 1 time-stamps t4 to the PDelay_Resp message.
Node 1 obtains a set of timestamps, including t1, t2, t3, and t4. Other elements affecting the link
delay are ignored.
The message transmission delays in two directions on the link between node 1 and node 2 equal
(t4 - t1) - (t3 - t2).
If the message transmission delays in two directions on the link between node 1 to node 2 are
identical, the message transmission delay in one direction equals [(t4 - t1) - (t3 - t2)]/2.
Issue 03 (2013-08-15)

74

5 1588v2
The delay measurement in PDelay mode does not differentiate between the master and slave
nodes. All nodes send PDelay messages to their adjacent nodes to calculate adjacent link delay.
This calculation process repeats and the message transmission delay in one direction is updated
accordingly.
The delay measurement in PDelay mode does not trigger time synchronization. To implement
time synchronization, the master node needs to periodically send Sync messages to the slave
node and the slave node receives the t1 and t2 timestamps. The slave node then deducts the
message transmission delay on the link from the master node to the slave node. The obtained
t2-t1-CorrectionField is the time offset between the slave and master nodes. The slave node uses
the time offset to synchronize with the master node. Figure 5-8 shows how time synchronization
is implemented in PDelay mode in the scenario where the BC and OC are directly connected.
Figure 5-8 Networking diagram of time synchronization in PDelay mode on the directlyconnected BC and OC
BC
Master
t1
OC
Slave
PDelay Req
t2
t4
PDelay Resp
t3
PDelay Req
t1
t2
t3
t1
PDelay Resp
t4
Sync
t2
The BC and OC can be directly connected as shown in Figure 5-4.
Alternatively, the BC and OC can be connected through other device functioning as TCs to
ensure the accuracy of time synchronization. The TC only transparently transmits 1588v2
messages and corrects the message transmission delay (which requires that the TC identify these
1588v2 messages). Unlike delay correction on the E2ETC, delay correction on the P2PTC
involves the correction of both transmission delay and upstream link delay. Figure 5-9 shows
how transmission delay correction is performed on a P2PTC.
Issue 03 (2013-08-15)

75

5 1588v2
Figure 5-9 Transmission delay correction in PDelay mode

Sync or Follow_up message at egress
Sync message at ingress

Event message payload Network
protocol Preamble
correctionField
headers
PTP message payload

correctionField
Ingress timestamp
Network
protocol Preamble
headers
Engress timestamp
Link delay on ingress port

Ingress
Egress
Residence time bridge
Figure 5-10 shows how the BC, OC, and E2E TC are connected and how 1588v2 operates.
Figure 5-10 Schematic diagram of transmission delay correction in PDelay mode on a P2PTC
BC
Master
t1
PDelayReq
PDelayResp
t2
t3
t4
t1
t4
PDelayReq
t2
PDelayResp
t3
t1
PDelayReq
t4
PDelayResp
t1
PDelayReq
t4
t1
OC
Slave
P2P
TC
PDelayReq
t2
t3
t2
t3
correction
Sync
t2
One-Step/Two-Step
In one-step mode, both the Sync messages for time synchronization in Delay mode and
PDelay_Resp messages for time synchronization in PDelay mode are stamped with a sending
time.
Issue 03 (2013-08-15)

76

5 1588v2
In two-step mode, Sync messages for time synchronization in Delay mode and PDelay_Resp
messages for time synchronization in PDelay mode are not stamped with a sending time. The
sending time is carried in Follow_Up and PDelay_Resp_Follow_Up messages.
The NE40E adopts the one-step mode. To communicate with other devices, the NE40E is also
able to identify incoming messages that are time-stamped in two-step mode.
Asymmetric Correction
Theoretically, 1588v2 requires the message transmission delays in two directions on a link to
be symmetrical. Otherwise, the algorithms of 1588v2 time synchronization cannot be
implemented. In practice, however, the message transmission delays in two directions on a link
may be asymmetric due to the attributes of a link or a device. For example, if the delays between
receiving the message and time-stamping the message in two directions are different, 1588v2
provides a mechanism of asymmetric delay correction, as shown in Figure 5-11.
Figure 5-11 Asymmetric delay correction
Master clock
or
Responder
tms
tsm
Slave clock
or
Resuestor
Usually, t-ms is identical with t-sm. If they are different, the user can set a delay offset between
them as long as the delay offset is constant and obtainable. 1588v2 performs the time
synchronization calculation according to the asymmetric correction value. In this manner, a high
level of time synchronization accuracy can be achieved on an asymmetric-delay link.
Packet Encapsulation
1588v2 defines the following multiple packet encapsulation modes:
l
Layer 2 multicast encapsulation through a multicast MAC address

The EtherType field is 0x88F7, and the multicast MAC address is 01-80-C2-00-00-0E (in
PDelay messages) or 01-1B-19-00-00-00 (in non-PDelay messages).
1588v2 recommends that the Layer 2 multicast encapsulation mode be used. The NE40E
supports Layer 2 multicast encapsulation with VLAN tags. Figure 5-12 shows the Layer
2 multicast encapsulation without VLAN tags.
Issue 03 (2013-08-15)

77

5 1588v2
Figure 5-12 Layer 2 multicast encapsulation without VLAN tags
DA
6 Byte
SA
0x88f7
6 Byte
2 Byte
1588 packet
Figure 5-13 shows Layer 2 multicast encapsulation with VLAN tags.

Figure 5-13 Layer 2 multicast encapsulation with VLAN tags
DA
6 Byte
l
Vlan--12bit
0x8100 prority--3bit
0x88f7
SA
6 Byte
2 Byte
2 Byte
1588 packet
2 Byte
Layer 3 unicast encapsulation through unicast UDP

The destination UDP port number is 319 or 320, depending on the types of 1588v2
messages.
Currently, it is recommended that Huawei base stations adopt Layer 3 unicast
encapsulation. The IP clock server consists of multiple BTSs and uses unicast UDP packets
to exchange 1588v2 protocol packets. Figure 5-14 shows Layer 3 unicast encapsulation
without VLAN tags.
Figure 5-14 Layer 3 unicast encapsulation without VLAN tags
DA
SA
0x800 IP(header) UDP(header)
6Byte
6Byte
2Byte
20Byte
1588 packet
8Byte
Figure 5-15 shows Layer 3 unicast encapsulation with VLAN tags.

Figure 5-15 Layer 3 unicast encapsulation with VLAN tags
DA
SA
0x8100
6Byte 6Byte 2Byte
Vlan--12bit
prority--3bit
2Byte
IP(header) UDP(header) 1588 packet

20Byte
8Byte
Layer 3 multicast encapsulation through multicast UDP
Layer 3 unicast encapsulation through a unicast MAC address
IPv6 encapsulation
The NE40E supports Layer 2 multicast encapsulation, Layer 2 unicast encapsulation, Layer 3
multicast encapsulation, and Layer 3 unicast encapsulation, but does not currently support IPv6
encapsulation.
Issue 03 (2013-08-15)

78

5 1588v2
Unicast Negotiation Mode

According to 1588v2, in unicast negotiation mode, the client should send a service request to
the server. After accepting the request, the server sends a 1588v2 message to the client at the
required frequency for time synchronization. If the services requested by the client expire, the
server stops the services. The client, therefore, needs to continue the lease terms with the server
before they expire.
BITS Interface
1588v2 enables clock nodes to synchronize with each other, but cannot enable them to
synchronize with Greenwich Mean Time (GMT). If the clock nodes need to synchronize with
GMT, an external time source is required. That is, the GM needs to be connected to an external
time source to obtain the reference time in non-1588v2 mode.
Currently, the external time sources are from satellites, such as the GPS from the U.S.A, Galileo
from Europe, GLONASS from Russia, and Beidou from China. Figure 5-16 shows how the GM
and an external time source are connected.
Figure 5-16 Synchronization with an external time source
Grandmaster
1588v2
Router
Router
External
time port
BITS
The NE40E provides one type of external clock or time interfaces:

l
RJ45 port (using a 120 Ohm shielded cable)

The two RJ45 ports function as an external clock port and an external time port respectively,
providing the following clock or time signals:
2 MHz clock signal (Differential level with one line clock input and one line clock
output)
2 Mbit/s clock signal (Differential level with one line clock input and one line clock
output)
DC level shifter (DCLS) time signal (RS422 differential level with one line clock input
+ one line clock output)
1 pps + TOD time signal (RS422 differential level with one line time input)
1 pps + TOD time signal (RS422 differential level with one line time output)
Clock Synchronization
In addition to time synchronization, 1588v2 can be used for clock synchronization, that is,
frequency recovery can be achieved through 1588v2 messages.
Issue 03 (2013-08-15)

79

5 1588v2
1588v2 time synchronization in Delay or PDelay mode requires the device to periodically send
Sync messages to its peer.
The sent Sync message carries a sending timestamp. After receiving the Sync message, the peer
adds a receiving timestamp to it. When the link delay is stable, the two timestamps change at
the same pace. If the receiving timestamp changes are faster or slower, it indicates that the clock
of the receiving device runs faster or slower than the clock of the sending device. In this case,
the clock of the receiving device needs to be adjusted. When this occurs, the frequencies of the
two devices are synchronized.
The frequency restored through 1588v2 messages has a lower accuracy than the frequency
restored through synchronous Ethernet. Therefore, it is recommended to perform frequency
synchronization through synchronous Ethernet and time synchronization through 1588v2.
1588v2 restores the frequency in the following modes:
l
Hop-by-hop
In hop-by-hop mode, all devices on a link are required to support 1588v2. The frequency
recovery in this mode is highly accurate. In the case of a small number of hops, the frequency
recovery accuracy can meet the requirement of ITU-T G.813 (stratum 3 standard).
End-to-end (Delay and jitter may occur on the transit network.)

In end-to-end mode, the forwarding devices do not need to support 1588v2, and the delay
of the forwarding path is only required to meet a specified level, for example, less than 20
ms. The frequency recovery accuracy in this mode is low, and can meet only the
requirements of the G.8261 and base stations (50 pps) rather than that of the stratum 3 clock
standard.
To achieve high frequency recovery accuracy, 1588v2 requires Sync messages to be sent at a
rate of at least 100 packets/s.
The NE40E meets the following clock standards:
l
G.813 and G.823 for external clock synchronization
G.813 and G.823/G.824 for E1 and T1 clocks
G.8261 and G.8262 for synchronous Ethernet clocks
G.8261 and G.823/G.824 for frequency recovery through 1588v2 messages

At present, the NE40E supports frequency recovery through 1588v2 messages in hop-byhop mode, rather than in end-to-end or inter-packet delay variation (PDV) network mode.
The NE40E is not committed to be G.813 and G.8262 compliant.
5.4 Application Environment

Currently, 1588v2 is applicable to a link where all devices are 1588v2-capable, and a maximum
of 30 hops are supported.
Because a master clock has multiple slave clocks, it is recommended to use the BITS or IP clock
server as the master clock. It is not recommended to use any device as the master clock because
the CPU of the device may be overloaded.
Issue 03 (2013-08-15)

80

5 1588v2
1588v2 Clock Synchronization in E2E Mode

Figure 5-17 Networking diagram of 1588v2 clock synchronization in E2E mode
clock server
1588
FE
Node B with
1588
1588
GE
POS
GE
FE
Node B with
1588
As shown in Figure 5-17, clock servers and NodeBs exchange TOP-encapsulated 1588
messages over a QoS-enabled bearer network with the jitter being less than 20 ms.
Scenario description:
l
NodeBs only need frequency synchronization.
The bearer network does not support 1588v2 or frequency recovery in synchronous
Ethernet mode.
Solution description:
l
The bearer network is connected to a wireless IP clock server and adopts 1588v2 clock
synchronization and frequency recovery in E2E mode.
The clock server sends 1588v2 timing messages, which are transparently transmitted over
the bearer network to NodeBs. Upon receiving the timing messages, NodeBs perform
frequency recovery.
1588v2 timing messages need to be transparently transmitted by priority over the bearer
network; the E2E jitter on the bearer network must be less than 20 ms.
Advantage of the solution: Devices on the bearer network are not required to support
1588v2, and are therefore easily deployed.
Disadvantage of the solution: Only frequency synchronization rather than time

synchronization is performed. In practice, an E2E jitter of less than 20 ms is not ensured.
Issue 03 (2013-08-15)

81

5 1588v2
1588v2 Clock Synchronization in Hop-by-Hop Mode

Figure 5-18 Networking diagram of 1588v2 clock synchronization in hop-by-hop mode
BITS clock source/WAN link
Synchronous
Ethernet
1588
FE
Node B
with 1588
GE
WAN clock
1588
WAN clock
GE
GE
FE
Physical clock
signal transfer
Node B
without
1588
1588 clock
signal transfer
As shown in Figure 5-18, the clock source can send clock signals to NodeBs through the 1588v2
clock, WAN clock, synchronous Ethernet clock, or any combination of clocks.
l
NodeBs only need frequency synchronization.
GE links on the bearer network support the 1588v2 clock rather than the synchronous
Ethernet clock.
l
The Synchronous Digital Hierarchy (SDH) or synchronous Ethernet clock sends stratum 3
clock signals through physical links. On the GE links that do not support the synchronous
Ethernet clock, stratum 3 clock signals are transmitted through 1588v2.
Advantage of the solution: The solution is simple and flexible.
Disadvantage of the solution: Only frequency synchronization rather than time

synchronization is performed.
Issue 03 (2013-08-15)

82

5 1588v2
Bearer and Wireless Networks in the Same Clock Domain

Figure 5-19 Networking diagram of the bearer and wireless networks in the same clock domain
GPS+BITS
GPS+BITS
Node B
without 1588
FE
Node B
with 1588
E1
1588
1588
GE
BC
BC
POS
1588
GE
BC
BC
FE
1588 clock
signal transfer
Physical clock
signal transfer
Node B
with 1588
l
NodeBs need to synchronize time with each other.
The bearer and wireless networks are in the same clock domain.
l
The core node supports GPS or BITS clock interfaces.
All nodes on the bearer network function as BC nodes, which support the link delay
measurement mechanism to handle fast link switching.
Links or devices that do not support 1588v2 can be connected to devices with GPS or BITS
clock interfaces to perform time synchronization.
Advantage of the solution: The time of all nodes is synchronous on the entire network.
Disadvantage of the solution: All nodes on the entire network must support 1588v2.
Bearer and Wireless Networks in Different Clock Domains

Figure 5-20 Networking diagram of the bearer and wireless networks in different clock domains
clock server
1588
1588
1588
1588
1588
FE
GE
POS
GE
FE
Node B with TC+BC

1588
Issue 03 (2013-08-15)
BC
BC

TC+BC
Node B with
1588
83

5 1588v2
l
NodeBs need to synchronize time with one another.
The bearer and wireless networks are in different time domains.
l
The GPS is used as a time source and is connected to the wireless IP clock server.
BCs are deployed in the middle of the bearer network to synchronize the time of the
intermediate network.
TCs are deployed on both ends of the bearer network. TCs only correct the message
transmission delay and send the time to NodeBs, but do not synchronize the time with the
clock server.
Advantage of the solution: The implementation is simple because the bearer network does
not need to synchronize with the clock server.
Disadvantage of the solution: Devices on both ends of the bearer network need to support
1588v2 in TCandBC mode.

Terms
Terms
Description
Synchron
ization
On a modern communications network, in most cases, the proper functioning of

telecommunications services requires network clock synchronization, meaning
that the frequency offset or time difference between devices must be kept in an
acceptable range. Network clock synchronization includes time synchronization
and frequency synchronization.
l Time synchronization
Time synchronization, also called phase synchronization, refers to the
consistency of both frequencies and phases between signals. This means that
the phase offset between signals is always 0.
l Frequency synchronization
Frequency synchronization, also called clock synchronization, refers to a strict
relationship between signals based on a constant frequency offset or a constant
phase offset, in which signals are sent or received at the same average rate in
a valid instance. In this manner, all devices on the communications network
operate at the same rate. That is, the phase difference between signals remains
a fixed value.
IEEE
1588v2
PTP
Issue 03 (2013-08-15)
1588v2, defined by the Institute of Electrical and Electronics Engineers (IEEE),

is a standard for Precision Clock Synchronization Protocol for Networked
Measurement and Control Systems. The Precision Time Protocol (PTP) is used
for short.
84

5 1588v2
Terms
Description
Clock
domain
Logically, a physical network can be divided into multiple clock domains. Each
clock domain has a reference time, with which all devices in the domain are
synchronized. Different clock domains have their own reference time, which is
independent of each other.
Clock
node
Each node on a time synchronization network is a clock. The 1588v2 protocol

defines three types of clocks: OC, BC, and TC.
Clock
reference
source
Clock source selection is a method to select reference clocks based on the clock
selection algorithm.
One-step
mode
In one-step mode, Sync messages in Delay mode and PDelay_Resp messages in

PDelay mode are stamped with the time when messages are sent.
Two-step
mode
In two-step mode, Sync messages in Delay mode and PDelay_Resp messages in

PDelay mode only record the time when messages are sent and carry no
timestamps. The timestamps are carried in the messages, such as Follow_Up and
PDelay_Resp_Follow_Up messages.
Abbreviations
Issue 03 (2013-08-15)
Abbreviation
Full Spelling
1588v2
Precision Time Protocol
IP RAN
Internet Protocol Radio Access Network
GSM
Global System for Mobile communications
WCDMA
Wideband Code Division Multiple Access
TD-SCDMA
Time Division-Synchronous Code Division Multiple Access
WiMax FDD
Worldwide Interoperability for Microwave Access Frequency

Division Duplex
WiMax TDD
Worldwide Interoperability for Microwave Access Time Division

Duplex
NTP
Network Time Protocol
GPS
Global Position System
LTE
Long Term Evolution
BC
Boundary Clock
OC
Ordinary Clock
TC
Transparent Clock
BMC
Best Master Clock

85

Issue 03 (2013-08-15)
Abbreviation
Full Spelling
BITS
Building Integrated Time Supply System

5 1588v2
86

6 CES ACR Clock Synchronization
CES ACR Clock Synchronization
About This Chapter

6.1 Introduction
6.2 References
6.3 Principles
6.4 Applications
Issue 03 (2013-08-15)

87

6.1 Introduction
Definition
Circuit emulation service (CES) adaptive clock recovery (ACR) clock synchronization
implements adaptive clock frequency synchronization and asynchronous clock frequency
synchronization based on CESs. CES ACR clock synchronization uses special circuit emulation
headers to encapsulate time multiplexing service (TDM) packets that carry clock frequency
information and transmits these packets over a packet switched network (PSN).
Purpose
If a clock frequency is out of the allowed error range, problems such as bit errors and jitter occur.
As a result, network transmission performance deteriorates. Clock synchronization confines the
clock frequencies of all network elements (NEs) on a digital network to the allowed error range,
enhancing network transmission stability.
When the intermediate PSN does not support clock synchronization at the physical layer and
needs to transmit clock frequency information using TDM services of the CES ACR.
6.2 References
The following table lists the references of this chapter.
Document No.
Document Name
ITU-T G.8261
Timing and synchronization aspects in packet networks
6.3 Principles
CES
The CES technology originated from the asynchronous transfer mode (ATM) network. CES
uses emulated circuits to encapsulate circuit service data into ATM cells and transmits these
cells over the ATM network. Later, circuit emulation was used on the Metro Ethernet to
transparently transmit TDM and other circuit switched services.
CES uses special circuit emulation headers to encapsulate TDM service packets that carry clock
frequency information and transmits these packets over the PSN.
CES ACR
The CES technology generally uses the adaptive clock recovery algorithm to synchronize clock
frequencies. If an Ethernet transmits TDM services over emulated circuits, the Ethernet uses the
Issue 03 (2013-08-15)

88

adaptive clock recovery algorithm to extract clock synchronization information from data
packets.
Clock Recovery Domain

A clock recovery domain refers to a channel of clock signals that can be recovered on a client.
6.3.2 Basic Principles

As shown in Figure 6-1, when the intermediate PSN does not support clock synchronization at
the physical layer and needs to transmit clock frequency information using TDM services of the
CES ACR. The detailed process is described as follows:
1.
The clock source sends clock frequency information to the CE1
2.
The CE1 encapsulates clock frequency information into TDM service packets sends to
gateway IWF1
3.
Gateway IWF1 that connects to the master clock regularly sends service clock information
to gateway IWF2 that connects to the slave clock. The service clock information is coded
using sequence numbers or timestamp. The service clock information is encapsulated into
T1/E1 service packets for transmission.
4.
IWF2 extracts the clock sequence number or timestamp from T1/E1 emulation packets and
recovers clock information using the adaptive clock recovery algorithm. In this manner,
IWF2 synchronizes its local clock to the master clock and the local clock of IWF1.
Figure 6-1 Working principles of CES-based ACR
PW
T1/E1
T1/E1
PSN
TDM
BITS
TDM
IWF1
CE1
IWF2
CE2
6.4 Applications
CES ACR is used in scenarios in which the intermediate PSN does not support clock
synchronization at the physical layer and needs to transmit clock frequency information using
TDM services.
Figure 6-2 Applications of CES-based ACR
PW
T1/E1
T1/E1
PSN
TDM
BITS
Issue 03 (2013-08-15)
CE1
TDM
IWF1

IWF2
CE2
89

As shown in Figure 6-2, the clock source sends clock frequency information to a CE. The CE
encapsulates clock frequency information into TDM service packets and transmits these packets
over the intermediate PSN to the peer CE. CES ACR recovers clock frequency information at
the IWF connected to the peer CE. In practical application, multiple E1 or T1 interfaces can
belong to the same clock recovery domain. By default, the system selects a PW as the primary
PW and uses the primary PW to recover clock signals. If the primary PW fails, the system selects
the next available PW as the primary PW to recover clocks. In this manner, clock protection
among multiple PWs is implemented.

Abbreviations
Issue 03 (2013-08-15)
Abbreviation
Full Spelling
CES
Circuit Emulation Service
ACR
Adaptive Clock Recovery

90

7 Plug-and-Play
Plug-and-Play
About This Chapter

7.1 Introduction to Plug-and-Play
7.2 References
7.3 Principles
7.4 Applications
Issue 03 (2013-08-15)

91

7 Plug-and-Play
7.1 Introduction to Plug-and-Play

Definition
Plug-and-Play (PnP) is a reference to the ability of a network management system (NMS) to
automatically configure a device added to the network through the Dynamic Host Configuration
Protocol (DHCP). Through PnP, you can commission remote devices in a centralized manner.
Purpose
A great number of devices need to access the mobile bearer network; therefore, the CapEx of
project deployment, especially of on-site commissioning of devices on the mobile bearer
network is high and the profit of the carrier is greatly affected. In this situation, Huawei launches
a PnP solution for mobile bearer networking schemes to address this problem.
Benefits
This feature brings the following benefits to carriers:
PnP can greatly reduce time taken for on-site commissioning of devices and prevent device
commissioning engineers from working in atrocious outdoor environments. In this manner, PnP
can accelerate progress and improve quality of the project.
7.2 References
The following table lists the references.
Document No.
Document Name
RFC 2131
Dynamic Host Configuration Protocol
RFC 2132
DHCP Options and BOOTP Vendor Extensions
RFC 3046
DHCP Relay Agent Information Option
7.3 Principles
7.3.1 Principle of DHCP
The Dynamic Host Configuration Protocol (DHCP) provides a framework for transmitting
configuration information to hosts on a TCP/IP network. DHCP, based on the Bootstrap Protocol
(BOOTP), adds the capability of automatically allocating reusable network addresses and adds
additional configuration options to DHCP packets.
DHCP packets can be classified into eight types. A DHCP server and a DHCP client
communicate with each other by exchanging these DHCP packets.
Issue 03 (2013-08-15)

92

7 Plug-and-Play
DHCPDISCOVER: It is the first packet used to search for a DHCP server when a DHCP
client accesses the network for the first time.
DHCPOFFER: It is sent by a DHCP server to respond to a DHCPDISCOVER packet. A

DHCPOFFER packet carries configuration information.
DHCPREQUEST: The DHCP client sends a DHCPREQUEST packet to the DHCP server
in any of the following situations.
After being initialized, the DHCP client broadcasts a DHCPREQUEST packet to
respond to the DHCPOFFER packet sent from the DHCP server.
After being restarted, the DHCP client broadcasts a DHCPREQUEST packet to confirm
the correctness of the configurations, such as the previously allocated IP address.
After being bound to an IP address, the DHCP client sends a unicast DHCPREQUEST
packet to extend the lease of the IP address.
DHCPACK: It is sent by a DHCP server to acknowledge the DHCPREQUEST packet sent

from a DHCP client. After receiving a DHCPACK packet, the DHCP client obtains the
configuration information, including the IP address.
DHCPNAK: It is sent by a DHCP server to refuse the DHCPREQUEST message from a

DHCP client. For example, the IP address that is assigned by the DHCP server to the DHCP
client expires, or the DHCP client moves to another network.
DHCPDECLINE: It is sent by a DHCP client to notify the DHCP server that the assigned
IP address conflicts with the other IP addresses. Then, the DHCP client applies to the DHCP
server for another IP address.
DHCPRELEASE: It is sent by a DHCP client to ask the DHCP server to release the network
address and cancel the remaining lease.
DHCPINFORM: It is sent by a DHCP client to the DHCP server to ask for configuration
parameters after the DHCP client obtains an IP address.
7.3.2 Operation Principle of a DHCP Client

Figure 7-1 shows the operation principle of a DHCP client.
Figure 7-1 Operation principle of a DHCP client
DHCP Client
DHCP Server
1.DHCP Discover
2.DHCP Offer
3.DHCP Request
4.DHCP ACK
Issue 03 (2013-08-15)

93

1.
7 Plug-and-Play
The DHCP client sends a DHCPDISCOVER packet to the DHCP server and enters the
selecting state. Then, the DHCP client creates a timer for waiting DHCPOFFER packets
from the DHCP server.
l If the DHCP client receives a non-DHCPOFFER packet, it discards the packet.
l If the DHCP client receives no DHCPOFFER packet before the timer expires, the DHCP
client is initialized and sends another request for an IP address.
2.
After receiving a DHCPOFFER packet, the DHCP client deletes the timer and sends a
DHCP request. Then, the DHCP client creates a timer for waiting a DHCPACK packet.
l If the DHCP client receives a packet that is not a DHCPACK or DHCPNAK packet, it
discards the packet.
l If the DHCP client receives a DHCPNAK packet, it sends another request for an address.
l If the DHCP client has not received a DHCPACK or DHCPNAK packet before the
timer expires, it sends four DHCP requests within one minute. If no response is received,
the DHCP client is initialized and sends another request for an IP address.
3.
After being allocated an IP address, the DHCP client sends a gratuitous ARP packet to
check whether the allocated address is already in use. If the address is in use, the DHCP
client sends a DHCPDECLINE packet to the DHCP server and returns to the initial state.
7.3.3 Basic Principles of DHCP

A DHCP server is responsible for assigning IP addresses to clients. A DHCP client sends a
packet to the server to apply for configurations such as the IP address, subnet mask, and default
gateway. After receiving the request, the server replies with a packet that carries required
configuration information according to policies. Both DHCP Request packets and Response
packets are encapsulated through UDP. The DHCP client listens to packets through port 68; the
DHCP server listens to packets through port 67.
Figure 7-2 shows DHCP packet exchange.
Issue 03 (2013-08-15)

94

7 Plug-and-Play
Figure 7-2 DHCP packet exchange
DHCP
Client
DHCP
Relay
DHCP
Server
1. DHCP Discover (broadcast)

1.DHCP Discover (unicast)
2.DHCP Offer
2.DHCP Offer
3.DHCP Request (broadcast)
3. DHCP Request (unicast)
4.DHCP ACK
Obtain IP
address
Extend address
lease
1/2 of lease
4.DHCP ACK
5.DHCP Request (unicast)
5. DHCP Request (unicast)
6.DHCP ACK
6.DHCP ACK
3/4 of lease
7.DHCP Request (broadcast)

7.DHCP Request (unicast)
8.DHCP ACK
8.DHCP ACK
The DHCP client communicates with the DHCP server in any of three modes.
To obtain a valid dynamic IP address, the DHCP client communicates with the DHCP
server in any of the following modes in different phases:
1.
The DHCP client accesses the network for the first time.
When the DHCP client accesses the network for the first time, the DHCP client
undergoes the following stages to set up a connection with the DHCP server:
Discover stage: The DHCP client searches for the DHCP server. The DHCP client
broadcasts a DHCP Discover packet, and only DHCP servers reply the Discover
packet.
Offer stage: The DHCP servers offer IP addresses to the DHCP client. After
receiving the DHCP Discover packet from the client, DHCP servers select
available IP addresses from their IP address pools, and then send DHCP Offer
packets carrying the leased IP addresses and other settings to the DHCP client.
Select stage: The DHCP client selects an IP address. If multiple DHCP servers
send DHCP Offer packets to the client, the DHCP client accepts only the DHCP
Offer packet that arrives first, and then broadcasts a DHCP Request packet to all
the DHCP servers. The Request packet contains the IP address that the client
requires the selected DHCP server to offer.
Acknowledge stage: The DHCP server acknowledges IP address offering. After
receiving the DHCP Request packet from the DHCP client, the selected DHCP
Issue 03 (2013-08-15)

95

7 Plug-and-Play
server sends a DHCP ACK packet to the client. The DHCP ACK packet contains
the offered IP address and other settings. Then, the DHCP client binds its TCP/IP
protocol components to the network interface card (NIC).
IP addresses offered by the other DHCP servers are available for the other clients.
2.
The DHCP client accesses the network for the second time.
When the DHCP client accesses the network for the second time, the DHCP client
undergoes the following stages to set up a connection with the DHCP server:
If the DHCP client has correctly accessed the network, it just needs to broadcast a
DHCP Request packet that carries the previously-assigned IP address when it
accesses the network again. The DHCP client does not need to send a DHCP
Discover packet.
After receiving the DHCP Request packet, the DHCP server sends a DHCP ACK
packet, instructing the DHCP client to continue to use the original IP address if the
IP address is not assigned to another DHCP client.
If the IP address cannot be assigned to the DHCP client (for example, it has been
assigned to another client), the DHCP server responds with a DHCP NAK packet.
After receiving the DHCP NAK packet, the DHCP client sends a DHCP Discover
packet to apply for a new IP address.
3.
The DHCP client extends the IP address lease.

Generally, there is a validity period (also called a lease) for the IP address
dynamically assigned to the client. The DHCP server calls back the IP address after
the lease expires. If the DHCP client intends to continue to use this IP address, it
needs to extend the IP address lease.
In practice, the DHCP client sends a DHCP Request packet to the DHCP server
automatically to update the IP address lease when the DHCP client starts or there
is only half of the lease duration left. If the IP address is valid, the server replies
with a DHCP ACK packet to inform the client of the new IP address lease.
NOTE
During the master/slave switchover of the MPU/SRU, the lease status of DHCP users does not
change.
Figure 7-3 DHCP packet format
op(1)
htype(1) hlen(1) hops(1)

xid(4)
secs(2)
flags(2)
ciaddr(4)
yiaddr(4)
siaddr(4)
giaddr(4)
chaddr(16)
sname(64)
file(128)
options(variable)
The description of each of the fields in a DHCP packet is as follows:

Issue 03 (2013-08-15)

96

7 Plug-and-Play
op: indicates the message type. The value 1 indicates the Request packet and the
value 2 indicates the Reply packet.
htype: indicates the hardware address type. The value 1 indicates the hardware
address of the 10 Mbit/s Ethernet.
hlen: indicates the hardware address length. In an Ethernet, the value of this field
is 6.
hops: indicates the number of hops. On the client, the value of this field must be
set to 0. It can be set on a relay agent optionally.
xid: indicates the transaction ID. The value is a random number chosen by the
client and used by the client and the server to associate requests and responses. It
is chosen by the client and returned by the server. The value is a 32-digit integer.
secs: indicates the seconds elapsed since the client starts applying for an IP address
or extends the IP address lease. This field is filled by the client.
flags: indicates the flags. This field contains 16 bits and only the leftmost bit is
useful. If the bit is 0, it indicates unicast; if the bit is 1, it indicates broadcast.
ciaddr: indicates the client IP address. This field is filled in only when the client
is in the state of Bound, Renew, or Rebinding and can reply with an ARP Request.
yiaddr: indicates 'your' (client) IP address.
siaddr: indicates the IP address of the next server to be used in the next phase of
DHCP.
giaddr: indicates the IP address of the DHCP relay agent.
chaddr: indicates the client hardware address. The client must set its hardware
address. The Ethernet frame header in a UDP packet also contains this field. It is
difficult or even impossible to obtain the value of this field by viewing a UDP
packet. If this field is set in a UDP-bearing DHCP packet, the user process can
easily obtain the value of this field.
sname: indicates the optional server host name. The value of this field is a null
terminated string. This field is to be filled by the DHCP server.
file: indicates the boot file name. The value of this field is a null terminated string.
In a DHCP Discover packet, this field is a "generic" name or null whereas in a
DHCP Offer packet, this field is a fully qualified directory-path name.
options: indicates the optional parameters field, which is in the format of "code
+length+data."
l
The DHCP client reports an address conflict.

After receiving a DHCP ACK packet from the DHCP server, the DHCP client checks the
IP address allocated by the DHCP server through duplicate address detection (DAD). If the
DHCP client finds an address conflict or that the allocated address is unusable for a certain
reason, the DHCP client sends a DHCP DECLINE packet to the DHCP server informing
that the allocated IP address is unusable.
The DHCP client releases the allocated IP address.

If the DHCP client does not need to use the allocated IP address any longer, the DHCP
client sends a DHCP RELEASE packet to the DHCP server informing that it does not need
to use the allocated IP address any longer. In this case, the DHCP server releases the bound
lease.
l
Issue 03 (2013-08-15)
Static and dynamic allocation of IP addresses

97

7 Plug-and-Play
Policies for IP address allocation

Different hosts may require different IP address leases. For a server, a fixed IP address
is required for a long term; for some hosts, IP addresses that are dynamically assigned
are needed for a long term; for some PCs, IP addresses are temporarily assigned on
demand.
To meet the preceding requirements, the DHCP server provides the following IP address
allocation policies:
Manual allocation: An administrator assigns fixed IP addresses to a few specific
hosts, such as WWW servers.
Automatic allocation: The server assigns fixed IP addresses to some hosts who are
connected to the network for the first time. These IP addresses can be used by the
hosts for a long time.
Dynamic allocation: The server assigns IP addresses with leases to clients. The
clients need to reapply for IP addresses when the leases expire. This address
allocation policy is widely accepted by most clients.
Sequence of IP address allocation
A DHCP server selects IP addresses in the following sequence and allocates an available
address to the client:
IP address that is in the database of the DHCP server and is statically bound to the
MAC address of the client.
IP address assigned to the client before, that is, the IP address in the requested IP
Addr option of the DHCP Discover packet sent by the client.
IP address first found when the server searches for available IP addresses in the
DHCP address pool.
Method of preventing IP address reallocation
Before allocating an IP address to the DHCP client, the DHCP server needs to check
this IP address to avoid address conflicts.
You can run the ping command to detect an IP address to be allocated and check whether
a response is received in the specified period. If no response is received within the
specified period, the ping command is executed again until the number of the sent ping
packets reaches the maximum value. If there is still no response, it indicates that the IP
address is not in use within the network segment to which the IP address belongs. This
ensures that the IP address assigned to the client is unique.
Pseudo DHCP server detection
If a private DHCP server exists on a network, clients cannot obtain correct IP addresses
and therefore cannot go online because this private DHCP server interacts with the
DHCP clients during address application. Such a private DHCP server is called a pseudo
DHCP server. By running commands, you can detect pseudo DHCP servers.
IP address reservation
DHCP supports IP address reservation for clients. The IP addresses in or outside an
address pool can be reserved. If an address in the address pool is reserved, the address
is no longer assignable. Addresses are reserved for DNS servers.
User-defined options
The Options field in a DHCP packet is used to carry control information and parameters
that are not defined in certain protocols. If the DHCP server is configured with options,
Issue 03 (2013-08-15)

98

7 Plug-and-Play
when a DHCP client applies for an IP address, the client can obtain the configuration
information in the Options field of the DHCP REPLY packet from the server. The value
of a DHCP option ranges from 0 to 255. At present, the device supports explicit
configuration of the common options of the DHCP server: Option 1 (Subnet Mask),
Option 3 (router), Option 6 (DNS Server), Option 15 (Domain Name), Option 44
(NetBIOS name server), Option 46 (NetBIOS node type), Option 51 (Lease), Option
58 (Renewal Time), Option 59 (Rebinding Time), Option 121 (Classless Static Routes),
Option 120 (SIP Server), and Option121 (Routing Information Option). In addition, the
device supports user-defined options .
Option resolution
The DHCP server supports resolution of certain options carried in a packet sent from a
DHCP client for client authentication and address allocation policies. At present, the
options that the device can resolute include: Option 12 (Host Name), Option 50
(Requested IP Address), Option 53 (DHCP Message Type), Option 55 (Parameter
Request List), Option 60 (Vendor class identifier), Option 61 (Client-identifier), and
Option 82 (DHCP Relay Agent Information Option).
Table 7-1 describes the usages of DHCP options.
Table 7-1 Usages of DHCP options
Issue 03 (2013-08-15)
Option ID
Usage
Option 60
When a certain terminal, for example, a set top box

(STB), accesses the network, the BRAS cannot
assign an IP address to it because the BRAS does not
know the user name and cannot know which domain
the terminal belongs to. If the terminal sends a DHCP
Request message that contains Option 60, the BRAS
can assign an IP address to the terminal according to
the information in Option 60 after receiving the
DHCP Request packet.
Option 82
When receiving a DHCP packet from a client, an

external DHCP or BOOTP server does not know the
physical location of the client. In this case, the DHCP
or BOOTP server cannot assign a required IP address
to the client but can allocate an IP address to the client
from the address pool in sequence. As a DHCP relay
agent, the BRAS can fill Option 82 with the physical
location of the client when relaying a DHCP packet
from the client. In this manner, the BRAS instructs
the DHCP server to allocate an IP address to the
client according to the information filled in Option
82.
Option 121
The DHCP/BOOTP server sends DHCPOFFER

packets and DHCPACK packets that contain the
Option 121 field to a DHCP client. The routing
information in the Option 121 field can be used to
guide data forwarding for users that are attached to
the home gateway.

99

7 Plug-and-Play
IP address lease
The DHCP server can specify different leases for addresses in different address pools.
The addresses in an address pool must be of the same lease.
Generally, there is a valid period for the IP address dynamically allocated to the client.
The DHCP server calls back the IP address after the valid period expires. If the client
intends to continue using this IP address, it needs to extend the IP address lease.
When obtaining an IP address, the DHCP client enters the binding state. The client has
three timers to control lease update, rebinding, and lease expiration. When assigning an
IP address to the client, the DHCP server can set the timers. If the DHCP server does
not set the values for the timers, the client uses the default values. Table 7-2 lists the
default values of the timers.
Table 7-2 Default values of timers
Timer
Default Value
Lease renewal timer
50% of the overall lease
Rebinding timer
87.5% of the overall lease
Lease expiration timer
Overall lease
When the lease renewal timer expires, the DHCP client must renew its IP address lease.
The DHCP client automatically sends a DHCP Request packet to the DHCP server that
assigns the currently-used IP address to the DHCP client. If the IP address is valid, the
DHCP server replies with a DHCP ACK packet to inform the client of a new lease, and
then the client re-enters the binding state. If the DHCP client receives a DHCP NAK
packet from the server, it enters the initializing state.
After the DHCP client sends a DHCP Request packet for extending the lease, the client
remains in the updating state and waits for a response. If the client does not receive a
response from the server after the rebinding timer expires, the client considers that the
original DHCP server is unavailable and starts to broadcast a DHCP Request packet.
Any DHCP server on the network can reply to this request with a DHCP ACK or DHCP
NAK packet.
If receiving a DHCP ACK packet, the client returns to the binding state and re-sets the
lease renewal timer and binding timer; if all the received packets are DHCP NAK
packets, the client goes back to the initializing state. At this time, the client must stop
using this IP address immediately, return to the initializing state, and request a new IP
address.
If the client does not receive any response before the lease expiration timer expires, the
client must stop using the current IP address immediately and return to the initializing
state.
Hot backup
If the router has two MPUs or SRUs, the system backs up the DHCP data on both MPUs
or SRUs in a real-time manner. When a master/slave switchover occurs, the DHCP
server on the standby board still works normally.
Issue 03 (2013-08-15)

100

7 Plug-and-Play
DHCP relay agent

The early DHCP protocol applies to only the situation that the DHCP client and DHCP
server are on the same network segment. Therefore, it is necessary but uneconomical
to configure a DHCP server on each network segment. The DHCP relay function is
therefore introduced to address this problem. Through a DHCP relay agent, a DHCP
client can communicate with the DHCP server on another network segment and apply
for a valid IP address. In this manner, DHCP clients on multiple network segments can
share one DHCP server. This saves costs and facilitates centralized management. The
DHCP relay agent forwards a DHCP broadcast packet to the DHCP server that is in
another network segment and fills the giaddr field of the DHCP broadcast packet with
the IP address of the relay interface to identify the network segment to which the
allocated address belongs. Both the DHCP relay agent and the DHCP server listen to
packets through port 67.
7.3.4 Operation Process of PnP

An underlayer PE (UPE) must function as a DHCP client to support the PnP feature. That is, the
UPE must be able to obtain an IP address by exchanging DHCP packets with the DHCP server
as described in Figure 7-4. The Network Management System (NMS) delivers configuration
files and startup files to the UPE. Then, the UPE can use the PnP feature after restarting with
the new configuration files.
Figure 7-4 Operation process of PnP
9.UPE obtains IP address and starts
defaultmanagement
7. Reply with a DHCP ACK, which

carries allocated address
8. Reply with
DHCP ACK.
4. Reply with
DHCP Offer
6.Insert Option 82 and

forward DHCP Offer
3. Reply with
DHCP Offer
1. Send Discover
2. Insert Option 82 and

forward Discover
5. Send Request
UPE(DHCP
Client)
IP/MPLS
DHCPRelay
NMS(DHCP
Server)
10.The NMS sends configuration and start files to UPE and

deliver restart conmand.
11. The device is usable after
restart
Issue 03 (2013-08-15)

101

7 Plug-and-Play
The operation process of PnP is as follows:

1.
After being powered on, the UPE starts the PnP process automatically. First, the UPE sends
a DHCP Discover broadcast packet that carries the Vendor Class Identifier (VCI) in the
Option 60 field.
2.
The DHCP relay agent receives the DHCP Discover packet and appends the Option 82
field to the packet. Then, the DHCP relay agent unicasts the packet to the DHCP server,
which functions as the NMS.
3.
The DHCP server searches the network element planning forms for a fixed IP address
according to the Option 60 and Option 82 fields carried in the packet. The DHCP server
allocates a fixed IP address and responds to the DHCP relay agent with a DHCP Offer
packet.
4.
The DHCP relay agent receives the DHCP Offer packet and then sends it to the UPE.
5.
The UPE broadcasts a DHCP request.
6.
The DHCP relay agent receives the DHCP request and appends the Option 82 field to the
packet. Then, the DHCP relay agent unicasts the packet to the DHCP server, which
functions as the NMS.
7.
The DHCP server checks information in the received packet and acknowledges the address
allocation for the UPE. In addition, the DHCP server responds to the DHCP relay agent
with a DHCP ACK packet.
8.
The DHCP relay agent receives the DHCP ACK packet and sends it to the UPE.
9.
After receiving the DHCP ACK packet, the UPE sends gratuitous ARP packets and checks
whether the allocated address is already in use.
If the UPE finds that the allocated address is not in use, the UPE obtains information such
as the IP address (yiaddr), mask (option 1), and gateway (option 3) from the DHCP ACK
packet and generates a route. Meanwhile, the IP address X.X.X.X dynamic command is
automatically executed; Telnet, AAA administrative user, and SNMP are configured on
the UPE. Finally, the DHCP client function is disabled on the UPE, and the UPE cannot
send or handle DHCP packets any longer.
10. The NMS delivers configuration files, startup files, and a restart command to the UPE.
11. The UPE restarts and can use the PnP feature. That is, the PnP process is complete.
7.4 Applications
As shown in Figure 7-5, the UPE obtains a management IP address through DHCP and starts a
management channel through automatic configuration. The NMS delivers configuration files
and startup files through the management channel.
Issue 03 (2013-08-15)

102

7 Plug-and-Play
Figure 7-5 Network diagram of obtaining a management IP address and starting a management
channel
UPE
PE-AGG
NMS
IP/MPLS
DHCPClient
DHCPRelay
DHCPServer

Terms
Term
Definition
Plug-and-Play
Plug-and-Play (PnP) is a reference to the ability of an NMS to

automatically configure a device added to the network through
DHCP. Through PnP, you can commission remote devices in a
centralized manner.
Acronyms and Abbreviations
Issue 03 (2013-08-15)
Acronym & Abbreviation
Full Name
PNP
Plug-and-Play
DHCP
Dynamic Host Configuration Protocol

103

NE40E X1&NE40E X2 Feature Description Basic Configurations (V600R005C00 - 03)

Uploaded by

Document Information

Original Title

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

NE40E X1&NE40E X2 Feature Description Basic Configurations (V600R005C00 - 03)

Uploaded by

Copyright:

Available Formats

HUAWEI NE40E-X1/NE40E-X2 Universal Service

Feature Description - Basic

HUAWEI TECHNOLOGIES CO., LTD.

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

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Industrial Base

Huawei Proprietary and Confidential

HUAWEI NE40E-X1/NE40E-X2 Universal Service Router

About This Document

About This Document

HUAWEI NE40E-X1 &

Huawei Proprietary and Confidential

HUAWEI NE40E-X1/NE40E-X2 Universal Service Router

Network planning engineers

Data configuration engineers

System maintenance engineers

About This Document

DANGER indicates a hazard with a high level or medium

WARNING indicates a hazard with a low level of risk

CAUTION indicates a potentially hazardous situation

TIP indicates a tip that may help you solve a problem or

NOTE provides additional information to emphasize or

Changes in Issue 03 (2013-08-15)

Changes in Issue 02 (2012-11-15)

Changes in Issue 01 (2012-08-15)

Huawei Proprietary and Confidential

HUAWEI NE40E-X1/NE40E-X2 Universal Service Router

About This Document

Dynamic Module Load

1.4.12 Dynamic Module

Added dynamic module

Huawei Proprietary and Confidential

HUAWEI NE40E-X1/NE40E-X2 Universal Service Router

Huawei Proprietary and Confidential

HUAWEI NE40E-X1/NE40E-X2 Universal Service Router

6 CES ACR Clock Synchronization.............................................................................................87

Huawei Proprietary and Confidential

HUAWEI NE40E-X1/NE40E-X2 Universal Service Router

Huawei Proprietary and Confidential

HUAWEI NE40E-X1/NE40E-X2 Universal Service Router

About This Chapter

Huawei Proprietary and Confidential

HUAWEI NE40E-X1/NE40E-X2 Universal Service Router

1.1 Introduction to Basic Configuration

Login through the console port

Remote login through the AUX port

Login through Secure Shell (SSH), with a password, with Revest-Shamir-Adleman

SSH FTP (SFTP) client/server

Virtual file system

Daylight saving time

Huawei Proprietary and Confidential

HUAWEI NE40E-X1/NE40E-X2 Universal Service Router

Directory oriented FTP commands

File Transfer Protocol

How to Use Anonymous FTP

The TFTP Protocol (Revision 2)

Telnet Extended ASCII Option

Directory oriented FTP commands

Telnet Protocol Specification

Telnet Option Specification

Telnet Terminal Type Option

Telnet Terminal-Type Option