Router
V600R005C00
03
Date
2013-08-15
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.
Website:
http://www.huawei.com
Email:
support@huawei.com
Issue 03 (2013-08-15)
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
V600R005C00
Intended Audience
This document is intended for:
Issue 03 (2013-08-15)
ii
Commissioning engineers
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol
Description
DANGER
WARNING
CAUTION
TIP
NOTE
Change History
Changes between document issues are cumulative. The latest document issue contains all the
changes made in earlier issues.
iii
Issue 03 (2013-08-15)
Section
Section
Description
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
2.5 Terms, Acronyms, and Abbreviations..........................................................................................................................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
3.5 Terms, Acronyms, and Abbreviations..........................................................................................................................55
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
5.5 Terms and Abbreviations..............................................................................................................................................84
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
Issue 03 (2013-08-15)
1 Basic Configuration
Telnet server/client
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
The following describes the principles of every protocol feature according to the type, including
the following parts:
l
FTP
TFTP
Telnet
SSH
User management
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)
1 Basic Configuration
Document
No.
Document Name
Remarks
RFC 775
RFC 959
RFC 1635
RFC 1350
RFC 698
RFC 775
RFC 854
RFC 855
RFC 930
RFC 1091
RFC 2119
RFC 4250
RFC 4251
RFC 4252
RFC 4253
RFC 4254
RFC 4344
RFC 4345
1 Basic Configuration
Document
No.
Document Name
Remarks
draft-ietfsecshpublickeysubsystem-0
1
Feature Enhancement
V600R005C00SPC700
V600R005C00SPC900
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
1 Basic Configuration
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.
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
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
1 Basic Configuration
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
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
1 Basic Configuration
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)
1 Basic Configuration
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.
The server enables port 21 to wait for a connection request from the client.
2.
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.
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.
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
1 Basic Configuration
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.
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.
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)
1 Basic Configuration
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
1 Basic Configuration
Description
EOF
236
End of file
SUSP
237
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
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
Telnet connection
A Telnet connection is a TCP connection used to transmit data with Telnet control
information.
Issue 03 (2013-08-15)
11
1 Basic Configuration
Telnet server
Pseudo
terminal driver
TCP/IP
Telnet client
TCP
connection
Terminal
driver
TCP/IP
Kernel
Kernel
User at a
terminal
Login shell
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
Description
Response
WILL
Issue 03 (2013-08-15)
WONT
DO
DONT
12
1 Basic Configuration
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
1 Basic Configuration
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.
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
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
1 Basic Configuration
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
1 Basic Configuration
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
1 Basic Configuration
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.
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)
17
1 Basic Configuration
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.
WorkStation
Router
Ethernet 100BASE-TX
Server
LapTop
PC
Issue 03 (2013-08-15)
18
1 Basic Configuration
Remote LAN
WAN
Router
SSH Router
PC
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
1 Basic Configuration
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.
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
1 Basic Configuration
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.
1 Basic Configuration
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.
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
Issue 03 (2013-08-15)
22
1 Basic Configuration
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
35
36
37
38
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
1 Basic Configuration
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
Issue 03 (2013-08-15)
24
1 Basic Configuration
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
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.
Basic Concepts
l
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
Issue 03 (2013-08-15)
25
1 Basic Configuration
Create a directory.
Delete a directory.
NOTE
Managing Files
You can perform the following operations for files:
l
Copy 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.
Restore deleted files. Restoring files from the recycle bin. Restoring deleted files is a reverse
operation of deleting files.
Miscellaneous
l
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 Basic Configuration
count
In this mode, the lines to be output are counted and only the line numbers are displayed.
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.
27
1 Basic Configuration
system time is adjusted accordingly; when it is time to end DST, the system time automatically
returns to normal.
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.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
28
1 Basic Configuration
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 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
1 Basic Configuration
1
Version
4 byte
Reserved
Checksum
Length
TLV1 (n byte)
TLV2 (n byte)
...
TLVn (n byte)
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
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.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
30
1 Basic Configuration
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
1 Basic Configuration
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.
2.
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
1 Basic Configuration
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.
2.
3.
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
IP Network
Server
172.16.105.110/24
GE2/0/0
Router
172.16.105.111/24
Issue 03 (2013-08-15)
33
1 Basic Configuration
Server
172.16.104.110/24
console cable
Router
TFTP Client
10.111.16.160/24
Server
PC
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 Basic Configuration
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
Issue 03 (2013-08-15)
35
1 Basic Configuration
SFTP Client
legal user
SFTP Server
Network
SSH Client
setting port
VPN
SFTP Server
SFTP Client
attacker
SSH Client
legal user
Network
SSH Client
setting port
SSH Server
VPN
SSH Client
attacker
Issue 03 (2013-08-15)
36
1 Basic Configuration
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 Client
Issue 03 (2013-08-15)
SSH Server
RADIUS Server
37
1 Basic Configuration
ACL
SSH Client
SSH Server
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
Telnet
NVT
SSH
SFTP
38
1 Basic Configuration
Terms
Description
STelnet
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
ACL
AES
CON
FTP
FTPS
FTP Secure
IETF
MAC
NAP
NVT
RSA
SFTP
SSH
Secure Shell
SSL
TACACS
Telnet
TFTP
TTY
VPN
VRP
39
2 Fast Startup
Fast Startup
Issue 03 (2013-08-15)
40
2 Fast Startup
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
2.2 References
None.
2.3 Principles
Issue 03 (2013-08-15)
41
2 Fast Startup
Item
Entire system
180
MPU
120
NPUI
120
2.4 Applications
None.
Abbreviations
None.
Issue 03 (2013-08-15)
42
3 Clock Synchronization
Clock Synchronization
Issue 03 (2013-08-15)
43
3 Clock Synchronization
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
ITU-T O.172
ITU-T G.781
ITU-T G.783
ITU-T G.8264
ITU-T G.704
ANSI T.101
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
3 Clock Synchronization
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
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
3 Clock Synchronization
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).
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.
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.
46
3 Clock Synchronization
In frequency offset detection mode, results are used for reference clock source selection.
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.
Implementation
l
Issue 03 (2013-08-15)
47
3 Clock Synchronization
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
Coding
PRC
0100
SSUA
0100
SSUB
1000
SEC
1011
DNU
1111
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
3 Clock Synchronization
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.
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.
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
3 Clock Synchronization
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
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
Issue 03 (2013-08-15)
50
3 Clock Synchronization
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.
51
3 Clock Synchronization
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
3 Clock Synchronization
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.
Issue 03 (2013-08-15)
53
3 Clock Synchronization
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
3 Clock Synchronization
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
DNU
Do Not Use
PRC
QL
Quality Level
SEC
SF
Signal Fail
SSM
SSU
55
4 1588 ACR
1588 ACR
Issue 03 (2013-08-15)
56
4 1588 ACR
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
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
ITU-T G.813
ITU-T G.823
ITU-T G.824
ITU-T G.8261
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.
Issue 03 (2013-08-15)
One-way mode
58
4 1588 ACR
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.
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
Description
Synchronizati
on
Time
synchronizati
on
Frequency
synchronizati
on
IEEE 1588v2
PTP
Abbreviations
Abbreviation
Full Spelling
PTP
1588v2
Issue 03 (2013-08-15)
BITS
BMC
ACR
62
5 1588v2
1588v2
Issue 03 (2013-08-15)
63
5 1588v2
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
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
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.
5.2 References
The following lists the references of this document:
l
Issue 03 (2013-08-15)
66
5 1588v2
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.8265.1: Precision time protocol telecom profile for frequency synchronization
5.3 Principles
5.3.1 Basic Concepts
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
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
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
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.
OC
BC
TC
E2ETC
P2PTC
E2ETCOC
P2PTCOC
TCandBC
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
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.
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
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
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
Message at egress
Network
PTP message payload
protocol Preamble
correctionField
headers
+
Ingress timestamp
Ingress
+
+
Engress timestamp
Egress
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
Ingress timestamp
Network
protocol Preamble
headers
Engress timestamp
Egress
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
Issue 03 (2013-08-15)
77
5 1588v2
DA
6 Byte
SA
0x88f7
6 Byte
2 Byte
1588 packet
DA
6 Byte
l
Vlan--12bit
0x8100 prority--3bit
0x88f7
SA
6 Byte
2 Byte
2 Byte
1588 packet
2 Byte
DA
SA
6Byte
6Byte
2Byte
20Byte
1588 packet
8Byte
DA
SA
0x8100
Vlan--12bit
prority--3bit
2Byte
8Byte
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
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
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).
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
Issue 03 (2013-08-15)
80
5 1588v2
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
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.
Issue 03 (2013-08-15)
81
5 1588v2
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.
Scenario description:
l
GE links on the bearer network support the 1588v2 clock rather than the synchronous
Ethernet clock.
Solution description:
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.
Issue 03 (2013-08-15)
82
5 1588v2
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
Scenario description:
l
The bearer and wireless networks are in the same clock domain.
Solution description:
l
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.
clock server
1588
1588
1588
1588
1588
FE
GE
POS
GE
FE
Issue 03 (2013-08-15)
BC
BC
TC+BC
Node B with
1588
83
5 1588v2
Scenario description:
l
Solution description:
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.
Description
Synchron
ization
IEEE
1588v2
PTP
Issue 03 (2013-08-15)
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
Clock
reference
source
Clock source selection is a method to select reference clocks based on the clock
selection algorithm.
One-step
mode
Two-step
mode
Abbreviations
Issue 03 (2013-08-15)
Abbreviation
Full Spelling
1588v2
IP RAN
GSM
WCDMA
TD-SCDMA
WiMax FDD
WiMax TDD
NTP
GPS
LTE
BC
Boundary Clock
OC
Ordinary Clock
TC
Transparent Clock
BMC
85
Issue 03 (2013-08-15)
Abbreviation
Full Spelling
BITS
5 1588v2
86
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
6.3 Principles
6.3.1 Basic Concepts
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.
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.
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.
Issue 03 (2013-08-15)
Abbreviation
Full Spelling
CES
ACR
90
7 Plug-and-Play
Plug-and-Play
Issue 03 (2013-08-15)
91
7 Plug-and-Play
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
RFC 2132
RFC 3046
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.
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.
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.
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.
Issue 03 (2013-08-15)
94
7 Plug-and-Play
DHCP
Client
DHCP
Relay
DHCP
Server
2.DHCP Offer
2.DHCP Offer
3.DHCP Request (broadcast)
4.DHCP ACK
Obtain IP
address
Extend address
lease
1/2 of lease
4.DHCP ACK
6.DHCP ACK
6.DHCP ACK
3/4 of lease
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.
During the master/slave switchover of the MPU/SRU, the lease status of DHCP users does not
change.
op(1)
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
l
Issue 03 (2013-08-15)
97
7 Plug-and-Play
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
Option 82
Option 121
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
Rebinding 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
8. Reply with
DHCP ACK.
4. Reply with
DHCP Offer
1. Send Discover
5. Send Request
UPE(DHCP
Client)
IP/MPLS
DHCPRelay
NMS(DHCP
Server)
Issue 03 (2013-08-15)
101
7 Plug-and-Play
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.
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
Definition
Plug-and-Play
Issue 03 (2013-08-15)
Full Name
PNP
Plug-and-Play
DHCP
103