CX600 - Feature Description - User Access

(1)

HUAWEI CX600 Metro Services Platform

V600R002

Feature

Description

-

User

Access

Issue 01

(2)

(3)

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

Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.

All other trademarks and trade names mentioned in this document are the property of their respective holders.

Notice

The purchased products, services and features are stipulated by the contract made between Huawei and the customer. All or part of the products, services and features described in this document may not be within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information, and recommendations in this document are provided "AS IS" without warranties, guarantees or representations of any kind, either express or implied.

The information in this document is subject to change without notice. Every effort has been made in the preparation of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this document do not constitute the warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base Bantian, Longgang Shenzhen 518129

People's Republic of China Website: http://www.huawei.com

(4)

(5)

About This Document

Intended Audience

This document describes the User access feature in terms of its overview, principle, and applications.

This document together with other types of document helps intended readers get a deep understanding of the User access feature.

This document is intended for: Network planning engineers Commissioning engineers Data configuration engineers System maintenance engineers

Symbol Conventions

The symbols that may be found in this document are defined as follows.

Symbol Description

Indicates a hazard with a high level of risk, which if not avoided, will result in death or serious injury.

Indicates a hazard with a medium or low level of risk, which if not avoided, could result in minor or moderate injury.

Indicates a potentially hazardous situation, which if not avoided, could result in equipment damage, data loss, performance degradation, or unexpected results.

Indicates a tip that may help you solve a problem or save time.

Provides additional information to emphasize or supplement important points of the main text.

(6)

About This Document

HUAWEI CX600 Metro Services Platform Feature Description - User Access

Issue 01 (2010-06-25)

Change History

Updates between document issues are cumulative. Therefore, the latest document issue contains all updates made in previous issues.

None.

Changes in Issue 01 (2010-06-25)

(7)

About This Document ... iii

1 AAA and User Management ... 1-1

1.1 Introduction to AAA and User Management ... 1-1 1.2 References ... 1-3 1.3 Availability ... 1-4 1.4 Enhancement ... 1-4 1.5 Principles ... 1-4 1.5.1 AAA ... 1-4 1.5.2 RADIUS ... 1-7 1.5.3 HWTACACS ... 1-10 1.5.4 User management ... 1-11 1.6 Applications... 1-16 1.6.1 RADIUS Authentication and Accounting ... 1-16 1.6.2 HWTACACS Authentication, Accounting, and Authorization ... 1-16 1.7 Impact ... 1-17 1.7.1 On the System Performance ... 1-17 1.7.2 On Other Features ... 1-17 1.7.3 Defects ... 1-17 1.8 Terms and Abbreviations ... 1-17

2 Plug-and-Play ... 2-1

2.1 Introduction to Plug-and-Play ... 2-1 2.2 References ... 2-2 2.3 Availability ... 2-2 2.4 Principles ... 2-2 2.4.1 Principle of DHCP ... 2-2 2.4.2 Operation Principle of a DHCP Client ... 2-3 2.4.3 Operation Process of PnP ... 2-4 2.5 Applications... 2-6 2.6 Impact ... 2-6 2.6.1 Impact on the System Performance ... 2-6 2.6.2 Impact on Other Features ... 2-6 2.6.3 Defects ... 2-7

(8)

Contents

Issue 01 (2010-06-25) 2.7 Terms and Abbreviations ... 2-7

3 L2TP Access ... 3-1

3.1 Introduction ... 3-1 3.2 References ... 3-4 3.3 Availability ... 3-5 3.4 Enhancement ... 3-5 3.5 Principles ... 3-5 3.5.1 L2TP Protocol Structure ... 3-6 3.5.2 L2TP Header ... 3-6 3.6 Applications... 3-16 3.7 Impact ... 3-19 3.7.1 On the System Performance ... 3-19 3.7.2 On Other Features ... 3-19 3.7.3 Defects ... 3-19 3.8 Terms and Abbreviations ... 3-20

4 IPoEv4 ... 4-1

4.1 Introduction to IPoE ... 4-1 4.2 References ... 4-2 4.3 Availability ... 4-2 4.4 Feature Enhancement ... 4-2 4.5 Principles ... 4-2 4.5.1 Basic Principle of IPoEv4 ... 4-3 4.5.2 Basic Principle of DHCP ... 4-5 4.6 Applications... 4-11 4.7 Impact ... 4-18 4.7.1 Impact on the System Performance ... 4-18 4.7.2 Impact on Other Features ... 4-18 4.7.3 Defects ... 4-18 4.8 Terms and Abbreviations ... 4-19

5 IPoEv6 ... 5-1

5.1 Introduction to IPoEv6 ... 5-1 5.2 References ... 5-2 5.3 Availability ... 5-2 5.4 Enhancement ... 5-3 5.5 Principles ... 5-3 5.5.1 Principles of Stateless Address Autoconfiguration... 5-3 5.5.2 Principles of DHCPv6 Access ... 5-4 5.5.3 Principles of IPoEv6 Access ... 5-8 5.5.4 ND Proxy ... 5-9 5.6 Applications... 5-10 5.7 Impact ... 5-16

(9)

5.7.1 On the System Performance ... 5-16 5.7.2 On Other Features ... 5-16 5.7.3 Defects ... 5-16 5.8 Terms and Abbreviations ... 5-16

6 PPPoE Access ... 6-1

6.1 Introduction ... 6-1 6.2 References ... 6-3 6.3 Availability ... 6-3 6.4 Principles ... 6-4 6.4.1 Process of a PPPoE User Going Online ... 6-4 6.4.2 PPP State Machine ... 6-9 6.4.3 PPP Packet Format ... 6-12 6.5 Applications... 6-15 6.6 Impact ... 6-18 6.6.1 On the System Performance ... 6-19 6.6.2 On Other Features ... 6-19 6.6.3 Other Defects ... 6-19 6.7 Terms and Abbreviations ... 6-19

7 802.1x Access ... 7-1

7.1 Introduction to 802.1x Access ... 7-1 7.2 References ... 7-2 7.3 Availability ... 7-2 7.4 Feature Enhancement ... 7-2 7.5 Principle ... 7-3 7.5.1 Basic Principle of 802.1x Access ... 7-3 7.5.2 Authentication Initiation and User Logoff ... 7-4 7.5.3 EAP Packet Relaying and Termination ... 7-5 7.5.4 Basic Process of the IEEE 802.1x Authentication System ... 7-5 7.5.5 Basic Process of EAP-PEAP Authentication for Secure and Encrypted WLAN Access Through WPA ... 7-7 7.6 Applications... 7-8 7.7 Impact ... 7-10 7.7.1 Impact on the System Performance ... 7-10 7.7.2 Impact on Other Features ... 7-10 7.7.3 Defects ... 7-10 7.8 Terms and Abbreviations ... 7-11

8 WLAN ... 8-1

8.1 Introduction to WLAN ... 8-1 8.2 References ... 8-7 8.3 Availability ... 8-8 8.4 Principles ... 8-9

(10)

Contents

Issue 01 (2010-06-25) 8.4.1 AP Management ... 8-9 8.4.2 RF Management ... 8-16 8.4.3 Service Set Management (ESS Profile) ... 8-20 8.4.4 Configuration Auto-Provisioning Management ... 8-21 8.4.5 Centralized BSSID Management ... 8-21 8.4.6 Load Balancing ... 8-22 8.4.7 WLAN STA Roaming ... 8-22 8.4.8 WLAN Access Security ... 8-25 8.4.9 QoS ... 8-31 8.5 Applications... 8-33 8.6 Impact ... 8-36 8.6.1 On the System Performance ... 8-36 8.6.2 On Other Features ... 8-37 8.6.3 Defects ... 8-37 8.7 Terms and Abbreviations ... 8-37

(11)

Figures

Figure 1-1 Format of a RADIUS message ... 1-7 Figure 1-2 Process of exchanging RADIUS messages between the RADIUS server and client ... 1-8 Figure 1-3 Process of command-line authorization in HWTACACS ... 1-11 Figure 1-4 Network diagram of RADIUS authentication and accounting... 1-16 Figure 1-5 Networking diagram of HWTACACS authentication, accounting, and authorization ... 1-17 Figure 2-1 Operation principle of a DHCP client ... 2-4 Figure 2-2 Operation process of PnP ... 2-5 Figure 2-3 Network diagram of obtaining a management IP address and starting a management channel ... 2-6 Figure 3-1 VPDN model based on L2TP ... 3-2 Figure 3-2 L2TP protocol structure ... 3-6 Figure 3-3 Format of an L2TP message header ... 3-6 Figure 3-4 Format of an L2TP data message ... 3-8 Figure 3-5 Diagram of the three-way handshake during the establishment of a control connection ... 3-9 Figure 3-6 Diagram of the process of establishing a session connection ... 3-10 Figure 3-7 Diagram of tearing down an L2TP session connection ... 3-10 Figure 3-8 Diagram of tearing down an L2TP control connection ... 3-11 Figure 3-9 Networking diagram of an L2TP tunnel ... 3-12 Figure 3-10 Flowchart of establishing an L2TP tunnel call ... 3-13 Figure 3-11 Networking diagram of L2TP tunnel switching ... 3-15 Figure 3-12 Two typical L2TP tunnel modes ... 3-16 Figure 3-13 Users accessing the LAC through a router... 3-17 Figure 3-14 Users accessing the LAC through a router... 3-18 Figure 3-15 Application of IPv6 network access through L2TP on the carrier's network ... 3-19 Figure 4-1 Structure of the IPoX protocol stack ... 4-5 Figure 4-2 DHCP packet exchange ... 4-5 Figure 4-3 DHCP packet format ... 4-7

(12)

Figures

Issue 01 (2010-06-25)

Figure 4-4 Networking diagram of local address allocation for Layer 2 access users ... 4-12 Figure 4-5 Login process through a DHCP packet ... 4-12 Figure 4-6 Networking diagram of remote address allocation for a Layer 2 access user ... 4-14 Figure 4-7 Remote login of a DHCP user ... 4-15 Figure 4-8 Networking diagram of Layer 3 access users adopting Web authentication ... 4-15 Figure 4-9 Networking diagram of Layer 3 DHCP users ... 4-16 Figure 4-10 Networking diagram of Layer 2 leased line access ... 4-17 Figure 4-11 Networking diagram of Layer 3 leased line access ... 4-17 Figure 4-12 Networking diagram of Layer 2 VPN leased line access ... 4-18 Figure 5-1 Principle of ND proxy ... 5-10 Figure 5-2 Networking diagram of IPv6oE user access ... 5-11 Figure 5-3 Networking diagram for access of a Layer 2 IPv6 user running ND ... 5-11 Figure 5-4 Networking diagram for access of an IPv4/IPv6 dual-stack user running DHCPv4 and ND ... 5-12 Figure 5-5 Networking diagram for access of a Layer 2 IPv6 user running DHCPv6 ... 5-13 Figure 5-6 Networking diagram for access of an IPv4/IPv6 dual-stack User running DHCPv4 and DHCPv6 5-13 Figure 5-7 Networking diagram for access of a Layer 3 IPv6 User Running DHCPv6 ... 5-14 Figure 5-8 Networking diagram for access of Layer 2 IPv6 users through a routed HG ... 5-14 Figure 5-9 Networking diagram for access of Layer 2 IPv4/IPv6 dual-stack users through a routed HG ... 5-15 Figure 5-10 Schematic diagram of communication between users with the same prefix through the BRAS .. 5-16 Figure 6-1 PPP in the protocol stack ... 6-2 Figure 6-2 PPPoE negotiation process ... 6-4 Figure 6-3 LCP negotiation process ... 6-5 Figure 6-4 PAP authentication process ... 6-6 Figure 6-5 CHAP authentication process ... 6-7 Figure 6-6 NCP negotiation process ... 6-8 Figure 6-7 Access process of a PPP user ... 6-8 Figure 6-8 State transition ... 6-11 Figure 6-9 Format of a PPP packet ... 6-12 Figure 6-10 Typical networking model of PPPoE services ... 6-16 Figure 6-11 Typical networking model of PPPoEoV services ... 6-16 Figure 6-12 Typical networking model of PPPoEoQ services ... 6-17 Figure 6-13 Typical networking model of PPPoA services ... 6-17 Figure 6-14 Typical networking model of PPPoEoA services ... 6-18

(13)

Figure 6-15 Typical networking of PPPv6 user access ... 6-18 Figure 7-1 Architecture of the 802.1x authentication system ... 7-3 Figure 7-2 Protocol structure of the 802.1x authentication system ... 7-4 Figure 7-3 Basic process of the IEEE 802.1x authentication system (1) ... 7-6 Figure 7-4 Basic process of the IEEE 802.1x authentication system (2) ... 7-7 Figure 7-5 Basic process of IEEE 802.1x EAP-PEAP authentication ... 7-8 Figure 7-6 Typical networking diagram for 802.1x access ... 7-9 Figure 7-7 Networking diagram for 802.1XoEoV access ... 7-9 Figure 7-8 Networking diagram for 802.1XoEoQ access ... 7-9 Figure 7-9 Networking diagram of WLAN access ... 7-10 Figure 8-1 Centralized WLAN architecture ... 8-3 Figure 8-2 RF management process ... 8-4 Figure 8-3 Quick WLAN STA roaming ... 8-5 Figure 8-4 Flowchart of AC auto-discovery ... 8-10 Figure 8-5 Topology of the AC and the AP ... 8-10 Figure 8-6 Registration flowchart of the AP obtaining an AC IP address through the DHCP server ... 8-11 Figure 8-7 Registration flowchart of the AP obtaining an AC IP address through the DNS server ... 8-12 Figure 8-8 Channel forwarding mode ... 8-15 Figure 8-9 Direct forwarding mode ... 8-15 Figure 8-10 Principle of CAPWAP ... 8-16 Figure 8-11 Power decrease... 8-18 Figure 8-12 Power increase ... 8-19 Figure 8-13 4-way handshake during the AC's processing quick roaming ... 8-23 Figure 8-14 Fast roaming by a STA within a same AC ... 8-24 Figure 8-15 Process of OPEN-SYS authentication ... 8-25 Figure 8-16 Process of shared key authentication ... 8-26 Figure 8-17 Process of WAPI authentication and encryption ... 8-29 Figure 8-18 Process of 802.1x authentication based on EAP-TLS ... 8-31 Figure 8-19 WLAN access solution ... 8-34 Figure 8-20 Networking diagram of the scheme of channel access across the Layer 2 network ... 8-35 Figure 8-21 Networking diagram of the scheme of direct access across the Layer 2 network ... 8-36

(14)

(15)

Tables

Table 1-1 Comparisons between HWTACACS and RADIUS ... 1-10 Table 1-2 Default domains of the CX600 ... 1-12 Table 3-1 Description of fields in an L2TP message header ... 3-6 Table 4-1 Usages of DHCP options ... 4-10 Table 4-2 Default values of timers ... 4-10 Table 6-1 Common protocol codes ... 6-13 Table 6-2 Common code values... 6-14 Table 8-1 Description of parameters of service set management ... 8-20 Table 8-2 Carrier ID ... 8-21 Table 8-3 AC ID ... 8-22 Table 8-4 Parameters of the WMM profile ... 8-32 Table 8-5 Parameters of the traffic profile ... 8-33

(16)

(17)

1

AAA and User Management

About This Chapter

1.1 Introduction to AAA and User Management 1.2 References 1.3 Availability 1.4 Enhancement 1.5 Principles 1.6 Applications 1.7 Impact

1.8 Terms and Abbreviations

1.1 Introduction to AAA and User Management

Definition

AAA, short for Authentication, Authorization, and Accounting, provides the following types of security functions:

Authentication: determines the users who can access the network. Authorization: authorizes users to use specific services.

Accounting: records the utilization of network resources.

The CX600 implements AAA through the Remote Authentication Dial in User Service (RADIUS) protocol or the Huawei Terminal Access Controller Access Control System (HWTACACS) protocol.

RADIUS

RADIUS is one of the most commonly used protocols to implement AAA. As an application-layer protocol running between the CX600 and a RADIUS server, RADIUS defines the procedure for transmitting user information and accounting information between theCX600 and the RADIUS server and the format of packets exchanged between them.

(18)

1 AAA and User Management

Issue 01 (2010-06-25)

HWTACACS

AAA can also be implemented through HWTACACS. HWTACACS is the enhancement of TACACS that is an access control protocol defined in RFC 1492. Similar to RADIUS, HWTACACS adopts the client/server model to communicate with the HWTACACS server, thus implementing AAA for various users, including Point-to-Point Protocol (PPP) users, Virtual Private Dial Network (VPDN) users, and login users.

User management

A broadband remote access server (BRAS) is used to manage access users. Currently, the BRAS manages users in the following modes:

− Domain-based user management

All users belong to a same domain. By default, users are added to a default domain. The BRAS manages users by configuring service attributes for a domain. Thus, the users in the same domain have the same service attributes.

− User account-based user management

User accounts and related service attributes are configured on an AAA server such as the RADIUS server or the HWTACACS server, and are then delivered to users when the users get online or dynamically delivered to users after the users get online. In actual applications (except the applications of non-authentication and non-accounting) on the CX600, all user accounts must be configured on an AAA server, and all the domains to which the user accounts belong must be configured on the CX600. The CX600 supports the configuration and management of local user accounts.

Commonly, the service attributes configured in a domain have a lower priority than the service attributes delivered by an AAA server. Therefore, when service attributes are configured in a domain and are also delivered by an AAA server, the CX600 adopts the service attributes that are delivered by the AAA server. The service attributes configured in a domain take effect only when the AAA server does not support or deliver the service

attributes.

Purpose

The CX600 implements AAA through either RADIUS or HWTACACS.

The CX600 supports domain-based or user account-based user management and supports multiple authentication and accounting policies.

By authorizing and managing user attributes, the CX600 implements the enhanced the user management function, including user bandwidth control, access authority control, and QoS attribute control.

Benefits

This feature brings the following benefits to operators:

Access users are identified to guarantee legal service access.

Authorities of access users are controlled through domain-based or user account-based user management.

The reliability of access user accounting is ensured through the RADIUS or HWTACACS accounting protocol and the local accounting function in case of the remote accounting failure.

(19)

1.2 References

Document Description

RFC 2903 Generic AAA Architecture RFC 2904 AAA Authorization Framework

RFC 2905 AAA Authorization Application Examples RFC 2906 AAA Authorization Requirements

RFC 2989 Criteria for Evaluating AAA Protocols for Network Access RFC 3539 Authentication, Authorization and Accounting (AAA)

RFC 2809 Implementation of L2TP Compulsory Tunneling via RADIUS RFC 2865 Remote Authentication Dial In User Service (RADIUS) (June

2000)

RFC 2866 RADIUS Accounting (June 2000)

RFC 2867 RADIUS Accounting Modifications for Tunnel Protocol Support RFC 2868 RADIUS Attributes for Tunnel Protocol Support

RFC 2869 RADIUS Extensions (June 2000)

RFC 2882 Network Access Servers Requirements: Extended RADIUS Practices

RFC 3162 RADIUS and IPv6

RFC 3575 IANA Considerations for RADIUS (Remote Authentication Dial In User Service)

RFC 3579 RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)

RFC 3580 IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines

RFC 4014 Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option

RFC 0927 TACACS user identification Telnet option

RFC 1492 An Access Control Protocol, Sometimes Called TACACS (July 1993)

(20)

Issue 01 (2010-06-25)

1.3 Availability

Involved Network Element

None.

License Support

None.

Version Support

Product Version CX600 V600R002

Feature Dependency

None.

1.4 Enhancement

Version Feature Enhancement

V600R002 PPPoE access and L2TP access are added.

1.5 Principles

1.5.1 AAA 1.5.2 RADIUS 1.5.3 HWTACACS 1.5.4 User management

1.5.1 AAA

Authentication

The CX600 supports the following authentication modes. The three modes can be used in combination.

Non-authentication

In this mode, users are completely trusted without the check on their validity. This mode is rarely used.

(21)

Local authentication

In this mode, user information, including the user name, password, and attributes, is configured on the CX600. This mode features fast processing speed and low operation costs. The major limitation is that the information storage capacity is subject to the capacity of device hardware.

Remote authentication

In this mode, user information, including the user name, password, and attributes, is configured on an authentication server. The CX600 supports remote authentication through RADIUS or HWTACACS. As a client, the CX600 communicates with the RADIUS or HWTACACS server. The RADIUS protocol can be either a standard RADIUS protocol or an extended RADIUS protocol of Huawei, that is, RADIUS+V1.0 or RADIUS+V1.1.

First local authentication and later remote authentication

It is a local-authentication-preferred policy. That is, remote authentication is performed only after local authentication fails.

First remote authentication and later local authentication

It is a remote-authentication-preferred policy. That is, local authentication is performed only after the AAA server gives no response.

First remote authentication and later non-authentication

It is also a remote-authentication-preferred policy. That is, non-authentication is performed only after the AAA server gives no response.

Authorization

The CX600 supports user authorization during user login as well as dynamic authorization for online users. During user login, the CX600 supports various types of authorization schemes. Authorization during user login

The CX600 supports the following authorization modes during user login:

− Direct authorization

In this mode, users are completely trusted and directly authorized.

− Local authorization

In this mode, users are authorized based on the attributes of local user accounts configured on the CX600.

− HWTACACS authorization

In this mode, users are authorized through a HWTACACS server.

− If-authenticated authorization

In this mode, users pass the authorization after passing authentication (not in non-authentication mode).

− RADIUS authorization

RADIUS integrates authentication and authorization. Therefore, RADIUS authorization cannot be performed independently.

Authorization for online users

The CX600 supports dynamic authorization for online users.

In dynamic authorization, attributes such as the user group, committed access rate (CAR), and policy name, are re-configured on the AAA server. The AAA server then delivers the attributes to the AAA module through Change of Authorization (CoA) packets and the

(22)

Issue 01 (2010-06-25)

AAA module dynamically updates the users' authorization information. For description about CoA packets, refer to RFC 3576.

Accounting

Accounting mode

AAA supports the following accounting modes:

− Non-accounting

Free services are provided.

− Remote accounting

The CX600 supports remote accounting through an AAA server.

− Local accounting protection

The CX600 supports the local accounting protection function to avoid bill loss or error bills when a link fault occurs (for example, the AAA server is disconnected). When the AAA server fails to charge users, user bills are saved locally. Later, when the AAA server recovers, the CX600 uploads the locally saved bills to the accounting server through the Trivial File Transfer Protocol (TFTP).

There must be a local bill pool before you can implement the local accounting protection function on the CX600. The local accounting protection function does not take effect in the absence of a local bill pool. You can create or delete a local bill pool through commands. Note that after the local bill pool is deleted, the locally saved bills are also deleted correspondingly and the CX600 cannot automatically back up the bills to a bill server.

− Real-time accounting

During real-time accounting for online users, the CX600 periodically generates accounting packets and then sends them to a remote accounting server. Real-time accounting is also a bill protection measure. It furthest reduces error bills and ensures accuracy of accounting information in case of a link failure.

Working together with an AAA server, the CX600 also supports the time-based pre-paid service and traffic-based pre-paid service. It also supports charge rate switching and charge discounting functions. Then, users are accounted at different charge rates based on their access types.

Accounting failure policy

The CX600 supports the configuration of a remote accounting failure policy. Remote accounting failure policies include:

− Policy for start-accounting failures When start-accounting fails,

− If the policy is set to "offline", the user cannot go online.

− If the policy is set to "online", the user remains online but no real-time accounting packets can be exchanged between the user and the AAA server, even though the AAA server gives a response again. The user still needs to send an accounting packet to the AAA server for going offline. If the AAA server fails to charge the user, the user bill is saved locally.

− Policy for real-time accounting failures

When real-time accounting fails,

− If the policy is set to “offline”, the CX600 terminates user access and saves the offline bills locally.

(23)

− If the policy is set to "online", the user remains online and sends real-time accounting

packets to the AAA server. If the user needs to go offline, it sends an accounting packet to the AAA server. When the AAA server fails to charge the user, the user bill is saved locally.

− Policy for remote offline-accounting failures

When a user goes offline and the AAA server fails in accounting, the user bill is saved locally; if the local bill pool is full, the bill is lost.

Accounting packet copy

Accounting packet copy indicates that during accounting, accounting packets are sent to two AAA servers synchronously for separate accounting. This function is used when the original accounting information need be saved on multiple devices, for example, in the scenario of the multi-operator networking. In this case, the accounting packets are sent to two AAA servers and are used as original accounting information in subsequent bill accounting.

There are the following accounting packet copy modes:

− Physical accounting

For physical accounting, an accounting copy server is configured on the BAS interface for user access. After the user logs in, the CX600 searches for the

accounting copy server based on the user access interface and VLAN information and then copies the accounting packets to this accounting server.

− Two-level accounting

For two-level accounting, a main accounting server and an accounting copy server are configured for a domain. During accounting, the main accounting server copies the accounting packets to the accounting copy server.

1.5.2 RADIUS

Format of a RADIUS Message

Figure 1-1 shows the format of a RADIUS message. Figure 1-1 Format of a RADIUS message

Code Identifier Length

Authenticator Attribute 1 2 3 4 5 6 0-1- 2- 3- 4- 5- 6-7- 0-1- 2- 3- 4- 5- 6-7- 0-1- 2- 3- 4- 5- 6-7- 0-1- 2- 3- 4- 5- 6-7

The meaning of each field is described as follows:

Code: indicates the message type, such as the access request, access permission, and accounting request.

Identifier: is a string of numbers in ascending order for matching the request and response packets.

(24)

Issue 01 (2010-06-25)

Length: indicates the total length of all fields.

Authenticator: is used for checking the validity of a RADIUS message. Attribute: indicates the contents of a message, describing user attributes.

Process of Exchanging RADIUS Messages

The RADIUS server builds a unique database to store user names and passwords that are required for authentication. To obtain the right to access certain networks or to use certain network resources, a user needs to set up a connection with the CX600 through a device. In this case, the CX600 functions in authenticating the user and connecting the user and the device.

The CX600 is responsible for sending AAA information about the user to the RADIUS server. RADIUS prescribes how to transmit user information and accounting information between the CX600 and the RADIUS server. The RADIUS server receives connection requests from users, authenticates users, and then sends the required configuration information back to the CX600. The authentication information between the CX600 and the RADIUS server is transmitted with a key. This protects the user password from theft on an insecure network. Figure 1-2 shows the process of exchanging RADIUS messages between the RADIUS server and client. Figure 1-2 Process of exchanging RADIUS messages between the RADIUS server and client

1.User name

password 2.Request 3.Response

User CX600 RADIUS sever

1. A user initiates authentication and sends a user name and password to the CX600. 2. After the RADIUS client configured on the CX600 receives the user name and password,

it sends an authentication request to the RADIUS server.

3. If the request is valid, the RADIUS server completes the authentication and sends the required authorization information back to the RADIUS client.

Authentication information is encrypted before being transmitted between the RADIUS client and RADIUS server. This prevents theft of information on an insecure network.

The process of exchanging accounting messages is similar to that of exchanging authentication or authorization messages.

Features of RADIUS

RADIUS adopts the server/client model and has the following characteristics:

RADIUS features excellent real-time performance by using the User Datagram Protocol (UDP) as the transmission protocol.

RADIUS possesses high reliability owing to the retransmission mechanism and backup server mechanism.

RADIUS is easy to implement and is applicable to the multi-threaded server in the case of a large number of users.

(25)

Versions of RADIUS

The CX600 supports standard RADIUS, RADIUS+V1.0, and RADIUS+V1.1.

RADIUS+V1.1 and RADIUS+V1.0, derived from the standard RADIUS protocol, are private protocols defined by Huawei. With these protocols, the RADIUS server works more

effectively in flow control, charge rate switching, and control over the BRAS. The two protocols are both applicable to IPHotel and Portal services though they are different in expansion.

RADIUS+V1.0

In RADIUS+V1.0, a private attribute set is suffixed to the standard attribute set. That is, the private attributes are simply added to the standard attribute set. Such an extension may conflict with the subsequent extension of the standard RADIUS protocol. RADIUS+V1.1

In RADIUS+V1.1, all private attributes are considered a subset to be contained in the vendor-specific attribute defined in RFC 2865. This ensures the interworking and controllability between extended RADIUS+V1.1 of Huawei and the extended RADIUS protocols defined by other vendors, and avoids the conflict between extended

RADIUS+v1.1 of Huawei and the subsequent extension of the standard RADIUS protocol.

For Huawei private RADIUS attributes, refer to "Appendix A RADIUS Attributes" in the HUAWEICX600 Multiservice Control Gateway Configuration Guide – BRAS Service.

Implementation of RADIUS on the CX600

As a RADIUS client, the CX600 implements the following functions: Actively detects the status of the RADIUS server.

After receiving an AAA authentication or accounting message, the CX600 enables the server detection process if the server is Down. The CX600 then transforms the message into a packet and sends the packet to the current server to detect the server. If a response packet is received from the RADIUS server, the CX600 considers the server available. Caches the accounting-stop packets locally and retransmits them.

If the number of retransmission failures exceeds the set value, the accounting-stop packets are saved to the buffer queue. The system periodically scans the queue, extracts the packets, sends them to the specific server, and enables the waiting timer. If the transmission fails or no response packet is received from the server within the timeout period, the packets are put to the buffer queue again.

Automatically switches to another RADIUS server in the server group.

If the current server does not work or the number of retransmission events exceeds the set maximum number, the CX600 selects another server in the server group to transmit packets.

Performs load balancing between RADIUS servers.

Enabled with load balancing, the CX600 selects the RADIUS server in the Up state according to the costs of the RADIUS servers. Commonly, the higher the priority, the higher the possibility that the RADIUS server is selected.

Switches RADIUS attributes.

The CX600 supports the RADIUS attribute switching function. When the RADIUS attribute switching function is enabled and then configured, the CX600 encapsulates or parses the original attribute value in accordance with the post-switching attribute format

(26)

Issue 01 (2010-06-25)

during the transmission of RADIUS messages. In this manner, the CX600 can interwork with other devices.

Carries CAR in the class attribute

In the standard RADIUS protocol, the client is required to add the class attribute carried in the authentication message received from the RADIUS server to the accounting packet, and send the accounting packet to the accounting server without changing the class attribute. The CX600 extends the standard RADIUS protocol by adding CAR to the class attribute.

1.5.3 HWTACACS

Format of an HWTACACS message

The process of transmitting HWTACACS messages is similar to that of transmitting RADIUS messages.

Features of HWTACACS

Compared with RADIUS, HWTACACS is more reliable in transmission and encryption and thus is more suitable for security control. Table 1-1 shows comparisons between

HWTACACS and RADIUS.

Table 1-1 Comparisons between HWTACACS and RADIUS

HWTACACS RADIUS

Uses the Transmission Control Protocol (TCP) to provide reliable transmission.

Uses UDP.

Encrypts the main structure of a packet except the standard HWTACACS header.

Encrypts only the password field in the authentication packet.

Separates authorization from authentication.

Performs authentication together with authorization.

Is suitable for security control. Is suitable for accounting. Authorizes the commands executed by

administrative users.

Does not authorize the commands executed by administrative users.

In HWTACACS, authentication is separated from authorization. Therefore, you can use RADIUS for authentication and HWTACACS for authorization. In such a case, though RADIUS authorization is performed, only HWTACACS authorization takes effects.

Command-Line Authorization in HWTACACS

HWTACACS supports command-line authorization for the users with specific levels in a specified domain or a specified Secure Shell (SSH) user.

In command-line authorization mode, after a user logs in to the router through Telnet or SSH, every command input by the user needs to be authorized by the HWTACACS server. The command can be run only after command-line authorization is passed. Otherwise, the

(27)

HWTACACS server displays a message to inform the user that command-line authorization fails and the command cannot be run.

If the router does not receive any authorization response from the HWTACACS server within the timeout period set by the user, it considers that the command-line authorization times out, and thus the command cannot be run.

Figure 1-3 shows the process of command-line authorization in HWTACACS. Figure 1-3 Process of command-line authorization in HWTACACS

User CX600 TACACS

Server

1.command 2.author-cmd REQ

3.author-cmd ACK

1. The user enters a command on the CX600.

2. The CX600 sends a command-line authorization request to the TACACS server.

3. The TACACS server returns the authorization result to the CX600. If authorization succeeds, the user can run the command of the corresponding level; otherwise, the user cannot run the command.

1.5.4 User management

Overview

The BRAS is used to manage access users. Currently, the BRAS manages users in the following modes:

Domain-based user management

All users belong to a same domain. By default, users are added to the default domain. The BRAS manages users by configuring service attributes in a domain. Thus, the users in the same domain have the same service attributes.

User account-based user management

User accounts and related service attributes are configured on an AAA server such as the RADIUS server or the HWTACACS server, and are then delivered to users when the users get online, or dynamically delivered to users after the users get online.

In practical applications (except in non-authentication and non-accounting modes) on the CX600, all user accounts must be configured on an AAA server, and the domain to which the user accounts belong must be configured on the CX600. The CX600 supports the

configuration and management of local user accounts.

The service attributes configured for a domain have a lower priority than the service attributes delivered by an AAA server. Therefore, when service attributes are both configured for a domain and delivered by an AAA server, the CX600 adopts the service attributes that are delivered by the AAA server. The service attributes configured for a domain take effect only when the AAA server does not support or deliver the service attributes.

(28)

Issue 01 (2010-06-25)

Overview of a Domain

The CX600 supports a user account in the format of username@domain or

domain@username. Here, @ is a domain name delimiter. The positions of the domain name and the user name can be exchanged. If the user account that is input when a user accesses the CX600 does not contain a domain name, it indicates that the user belongs to the default domain of the system.

Default domain

A default domain is fixed in the system. The service attributes of the default domain can be modified rather than deleted.

The CX600 has three default domains: default0, default1, and default_admin, as shown in Table 1-2.

Table 1-2 Default domains of the CX600

Name Description Default

Attributes

default0 It is a domain to which a user belongs before

authentication. When a user access the CX600 and is not authenticated, the CX600 does not know the domain of the user, and thus by default considers that the user belongs to default0.

Non-authenticatio n

Non-accounting

default1 It is a domain to which a user belongs during

authentication. During authentication, if a user inputs a user account that does not contain a domain name, the CX600 by default considers that the user belongs to default1.

RADIUS authentication RADIUS accounting default_admin It is a domain to which an operation user belongs. In

the case that an operation user logs in to the CX600 through Telnet or SSH, if the operation user inputs a user account that does not contain a domain name during authentication, the CX600 by default considers that the operation user belongs to default_admin.

RADIUS authentication Non-accounting

Domain type

The CX600 supports the following types of domains:

− Default-domain pre-authentication

− Default-domain authentication

− Default-domain authentication force

− Default-domain authentication replace

− Authentication domain − Roam-domain

− Permit-domain

The following describes the functions of each type of domain:

(29)

This domain is used for only Web authentication users to obtain IP addresses. A user binds the user name to this domain and then obtains an IP address after passing Web authentication. Then, the user obtains corresponding rights according to the user group name in this domain. After passing the Web authentication in this domain, the users can access only the Web authentication server and the DNS. (The access rights are controlled through the UCL-group and ACLs.)

If the default-domain pre-authentication is not configured on a BAS interface, default0 is adopted as the default-domain pre-authentication.

− Default-domain authentication

If a user inputs a user account that does not contain a domain name during authentication, the user adopts the authentication scheme, accounting scheme, and RADIUS server that are configured in the default-domain authentication.

If the default-domain authentication is not configured on a BAS interface, default1 is adopted as the default-domain authentication.

− Default-domain authentication force

A user adopts the authentication scheme, accounting scheme, and RADIUS server that are configured in this domain, regardless of whether a domain name is contained in the input user account or what the domain name is. If a domain name is contained in the user account, the domain name remains unchanged during authentication; if no domain name is contained, the default-domain authentication force is added to the user account.

− Default-domain authentication replace

A user adopts the authentication scheme, accounting scheme, and RADIUS server that are configured in this domain, regardless of whether a domain name is contained in the input user account or what the domain name is. If a domain name is contained in the user account, the domain name is replaced with the default-domain

authentication replace during authentication; if no domain name is contained, the default-domain authentication replace is added to the user account.

− Authentication domain

It is a domain name that is contained in the user account input by a user. When a user inputs a normal user account (a domain name is contained and is configured on the CX600, and the BAS interface is not configured with the default-domain

authentication force or default-domain authentication replace), the user adopts the authentication scheme, accounting scheme, and RADIUS server that are configured in the input domain name.

− Roam-domain

A user must input a user account containing a domain name; otherwise, the user cannot adopt the roam-domain policy. If the domain name is not configured on the CX600, the user adopts the authentication scheme, accounting scheme, and RADIUS server that are configured in the roam-domain. The user account remains unchanged during authentication.

If the roam-domain is not configured on a BAS interface, default1 is adopted as the roam domain.

− Permit-domain

It is a domain that is allowed to access when users are getting online through a BAS interface.

Domain application

− Users getting online with a domain name

(30)

Issue 01 (2010-06-25)

− The BAS interface that accesses the user is not configured with the default-domain

authentication. If domain A is configured on the CX600, the user adopts the

authentication and accounting schemes that are configured in domain A, and the user account for authentication is user@A. If domain A is not configured on the CX600, and the roam-domain is disabled, the user authentication fails. If the roam-domain is enabled, the user adopts the authentication and accounting schemes that are

configured in the roam-domain.

− The BAS interface that accesses the user is configured with domain B as the default-domain authentication. If domain A is configured on the CX600, the user adopts the authentication and accounting schemes that are configured in domain A, and the user account for authentication is user@A. If domain A is not configured on the CX600, and the roam-domain is disabled, the user authentication fails. If the roam-domain is enabled, the user adopts the authentication and accounting schemes that are configured in the roam-domain.

− The BAS interface that accesses the user is configured with domain E as the roam-domain. If domain A is not configured on the CX600, the user adopts the authentication and accounting schemes that are configured in domain E. If domain A is configured on the CX600, the user adopts the authentication and accounting schemes that are configured in domain A, and the user account for authentication is user@A.

− The BAS interface that accesses the user is configured with domain F as the

default-domain authentication force. In this case, the user adopts the authentication and accounting schemes that are configured in domain F (regardless of whether domain A is configured on the CX600 or whether a roam-domain is configured), and the user account for authentication is still user@A.

− The BAS interface that accesses the user is configured with domain G as the

default-domain authentication replace. In this case, the user adopts the authentication and accounting schemes that are configured in domain G (regardless of whether domain A is configured on the CX600 or whether a roam-domain is configured), and the user account for authentication is changed into user@G.

− Users getting online without a domain name

Assume that a user inputs a user account, namely, user.

− If the BAS interface that accesses the user is not configured with the default-domain authentication, the user adopts the authentication and accounting schemes that are configured in default1, and the user account for authentication is user@default1.

− If the BAS interface that accesses the user is configured with domain B as the default-domain authentication, the user adopts the authentication and accounting schemes that are configured in domain B (domain B here is a default domain), and the user account for authentication is user@B.

− If the BAS interface that accesses the user is configured with domain H as the

default-domain authentication force, the user adopts the authentication and accounting schemes that are configured in domain H, and the user account for authentication is user@H.

− If the BAS interface that accesses the user is configured with domain J as the default-domain authentication replace, the user adopts the authentication and accounting schemes that are configured in domain J, and the user account for authentication is user@J.

No matter a user gets online with or without a domain name, after confirming the authentication domain of the user, the CX600 still has to determine whether the

authentication domain is allowed to access the BAS interface on which a permit-domain is configured.

(31)

The user account mentioned above is not the one that is sent to an AAA server. Instead, whether the user account sent to the AAA server contains a domain name depends on whether the device is configured to send a domain name to the AAA server.

Domain Management

A domain or an AAA server manages users by configuring service attributes for the users. Domain management includes access management and service management.

Access management

In a domain, you can configure the authorization, authentication, and accounting schemes and corresponding server that are used when a user accesses the BAS interface; configure the authentication mode used in user authentication; specify the IP address pool and the DNS server that are used to assign an IP address to a user; and control the user access by setting a limit on access number and setting the alarm threshold of IP addresses.

The following functions are highlighted:

− Time period control

In a specified time period, a domain automatically enters the blocked state. At this time, the users in the domain cannot get online, and the online users are forced to get offline. When the time period expires, the domain is activated and users in the domain can get online. Four time periods can be set in a domain, and all of them can take effect independent of each other.

− Mandatory PPP authentication

Generally, the authentication mode (PAP/CHAP/MSCHAP) for PPP users is determined through the negotiation between the PPP client and the virtual template (VT) interface. After an authentication mode is configured in a domain for PPP users, the PPP users are authenticated according to the configured authentication mode.

− IP address alarm

After the upper threshold (in percentage) of IP addresses is set, the CX600 sends a trap to the NMS when the IP address utilization exceeds the upper threshold. If the threshold of IP addresses is not set, the CX600 does not generate any alarm no matter how the IP addresses in the domain are used.

− Mandatory Web authentication

Mandatory Web authentication: If the user that requires Web authentication or fast authentication attempts to access an unauthorized address before authentication, the CX600 redirects the access request to the mandatory Web authentication server for the user to be authenticated.

Service management

After a user gets online, the user can be managed through a domain in terms of basic access services (such as access the Internet) or the right, bandwidth, and QoS of the value-added services.

The involved service attributes include: QoS profile, user priority, captive portal, multicast group, time period, traffic statistics, accounting packet copy, and idle-cut. The following functions are described:

− Captive portal

Captive portal means that when a user accesses the external network for the first time after passing the authentication, the CX600 forcibly redirects the access request to a certain server, which is usually the portal server of a carrier. In this manner, a service

(32)

Issue 01 (2010-06-25)

provided by the carrier is immediately accessed after the user is connected to the Internet.

− Idle-cut

Idle-cut means that when the traffic from a user is smaller than the lower threshold in a certain time period, the CX600 considers that the user is idle, and thus cut off the connection with the user. In the configuration of the idle-cut function, you need to specify two parameters, namely, the time period and the traffic.

− Traffic statistics collection

This function can be classified into two categories: function of collecting total traffic in a domain and function of collecting the upstream and downstream traffic of a user.

1.6 Applications

1.6.1 RADIUS Authentication and Accounting

1.6.2 HWTACACS Authentication, Accounting, and Authorization

1.6.1 RADIUS Authentication and Accounting

User 1, user 2, and user 3 access the Internet through the CX600. The users send

authentication packets to the RADIUS server for authentication and authorization. When the master server goes Down, the packets are switched to the backup server for authentication or accounting. After the authentication succeeds, the RADIUS server delivers corresponding rights to the users, and thus the users can access the Internet.

Figure 1-4 Network diagram of RADIUS authentication and accounting

user1@isp1 user2@isp2 user3@isp3 CX600 RADIUS (master) RADIUS (backup) Internet 129.7.66.67 129.7.66.66

1.6.2 HWTACACS Authentication, Accounting, and

Authorization

User 1, user 2, and user 3 access the Internet through the CX600. The users send

authentication packets to the HWTACACS server for authentication and authorization. When the master server goes Down, the packets are switched to the backup server for authentication or accounting. After the authentication succeeds, the HWTACACS server delivers

(33)

corresponding rights to the users, and then the users can access the Internet. The accounting bills can also be copied to the bill server the same time they are being sent to the

HWTACACS server.

Figure 1-5 Networking diagram of HWTACACS authentication, accounting, and authorization

user1@isp1 user2@isp2 user3@isp3 CX600 HWTACACS (master) HWTACACS (backup) Internet 130.7.66.67 130.7.66.66 Bill sever 10.10.10.1

1.7 Impact

1.7.1 On the System Performance 1.7.2 On Other Features

1.7.3 Defects

1.7.1 On the System Performance

None.

1.7.2 On Other Features

None.

1.7.3 Defects

None.

1.8 Terms and Abbreviations

Abbreviation Full Spelling

AAA Authentication Authorization Accounting

(34)

Issue 01 (2010-06-25)

Abbreviation Full Spelling

HWTACACS HUAWEI Terminal Access Controller Access Control System

(35)

2

Plug-and-Play

About This Chapter

2.1 Introduction to Plug-and-Play 2.2 References 2.3 Availability 2.4 Principles 2.5 Applications 2.6 Impact

2.1 Introduction to Plug-and-Play

Definition

Plug-and-Play (PnP) is a reference to the ability of a network management system (NMS) to automatically configure a device added to the network through the Dynamic Host

Configuration Protocol (DHCP). Through PnP, you can commission remote devices in a centralized manner.

Purpose

A great number of devices need to access the mobile bearer network; therefore, the CapEx of project deployment, especially of on-site commissioning of devices on the mobile bearer network is high and the profit of the carrier is greatly affected. In this situation, Huawei launches a PnP solution for mobile bearer networking schemes to address this problem.

Benefits

This feature bring the following benefits to operators:

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.

(36)

2 Plug-and-Play

Issue 01 (2010-06-25)

2.2 References

The following table lists the references of this document.

Document Description

RFC 2131 Dynamic Host Configuration Protocol

RFC 2132 DHCP Options and BOOTP Vendor Extensions

RFC 3046 DHCP Relay Agent Information Option

2.3 Availability

Involved Network Element

NMS that allocates IP addresses to UPEs

NPEs

UPEs

License Support

You can apply the PnP feature on the device only after obtaining a license.

Version Support

Product Version

CX600 V600R002

2.4 Principles

2.4.1 Principle of DHCP

2.4.2 Operation Principle of a DHCP Client 2.4.3 Operation Process of PnP

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

(37)

DHCPDISCOVER: It is the first packet used to search for a DHCP server when a DHCP client accesses the network for the first time.

DHCPOFFER: It is sent by a DHCP server to respond to a DHCPDISCOVER packet. A DHCPOFFER packet carries various configuration information.

DHCPREQUEST: The DHCP client sends a DHCPREQUEST packet to the DHCP server in any of the following situations.

− After being initialized, the DHCP client broadcasts a DHCPREQUEST packet to respond to the DHCPOFFER packet sent from the DHCP server.

− After being restarted, the DHCP client broadcasts a DHCPREQUEST packet to confirm the correctness of the configurations, such as the previously allocated IP address.

− After being bound to an IP address, the DHCP client sends a unicast

DHCPREQUEST packet to extend the lease of the IP address.

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

DHCPNAK: It is sent by a DHCP server to refuse the DHCPREQUEST message from a DHCP client. For example, the IP address that is assigned by the DHCP server to the DHCP client expires, or the DHCP client moves to another network.

DHCPDECLINE: It is sent by a DHCP client to notify the DHCP server that the assigned IP address conflicts with the other IP addresses. Then, the DHCP client applies to the DHCP server for another IP address.

DHCPRELEASE: It is sent by a DHCP client to ask the DHCP server to release the network address and cancel the remaining lease.

DHCPINFORM: It is sent by a DHCP client to the DHCP server to ask for configuration parameters after the DHCP client obtains an IP address.

2.4.2 Operation Principle of a DHCP Client

Figure 2-1 shows the operation principle of a DHCP client.

(38)

2 Plug-and-Play

Issue 01 (2010-06-25)

Figure 2-1 Operation principle of a DHCP client

DHCP Client DHCP Server

1.DHCP Discover

2.DHCP Offer 3.DHCP Request

4.DHCP ACK

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

− If the DHCP client receives a non-DHCPOFFER packet, it discards the packet. − 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 an 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.

− If the DHCP client receives a packet that is not a DHCPACK or DHCPNAK packet, it discards the packet.

− If the DHCP client receives a DHCPNAK packet, it sends another request for an

address.

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

2.4.3 Operation Process of PnP

A underlayer PE (UPE) must function as a DHCP client to support the PnP feature. That is, the UPE must be able to obtain an IP address by exchanging DHCP packets with the DHCP server as described in Figure 2-2. The Network Management System (NMS) delivers configuration files and startup files to the UPE. Then, the UPE can use the PnP feature after restarting with the new configuration files.

(39)

Figure 2-2 Operation process of PnP NMS (DHCP Server) DHCP Relay UPE(DHCP Client) 8. Reply with DHCP ACK. IP/MPLS 5. Send Request 4. Reply with DHCP Offer 1. Send Discover

7. Reply with a DHCP ACK, which carries allocated address

6.Insert Option 82 and forward DHCP Offer

3. Reply with DHCP Offer 2. Insert Option 82 and

forward Discover

10.The NMS sends configuration and start files to UPE and deliver restart conmand.

11. The device is usable after restart

9.UPE obtains IP address and starts default management

The operation process of PnP is as follows:

1. After being powered on, the UPE starts the PnP process automatically. First, the UPE sends a DHCP Discover broadcast packet that carries the Vendor Class Identifier (VCI) in the Option 60 field.

2. The DHCP relay agent receives the DHCP Discover packet and appends the Option 82 field to the packet. Then, the DHCP relay agent unicasts the packet to the DHCP server, which functions as the NMS.

3. The DHCP server searches the database for a fixed IP address according to the Option 60 and Option 82 fields carried in the packet. The DHCP server allocates a fixed IP address and responds to the DHCP relay agent with a DHCP Offer packet.

4. The DHCP relay agent receives the DHCP Offer packet and then sends it to the UPE. 5. The UPE broadcasts a DHCP request.

6. The DHCP relay agent receives the DHCP request and appends the Option 82 field to the packet. Then, the DHCP relay agent unicasts the packet to the DHCP server, which functions as the NMS.

7. The DHCP server checks information in the received packet and acknowledges the address allocation for the UPE. In addition, the DHCP server responds to the DHCP relay agent with a DHCP ACK packet.

8. The DHCP relay agent receives the DHCP ACK packet and sends it to the UPE.

9. After receiving the DHCP ACK packet, the UPE sends gratuitous ARP packets and checks whether the allocated address is already in use.

(40)

2 Plug-and-Play

Issue 01 (2010-06-25)

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, FTP, 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.

2.5 Applications

As shown in Figure 2-3, 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.

Figure 2-3 Network diagram of obtaining a management IP address and starting a management channel IP/MPLS DHCP Client DHCP Relay NMS DHCP Server UPE PE-AGG

2.6 Impact

2.6.1 Impact on the System Performance 2.6.2 Impact on Other Features

2.6.3 Defects

2.6.1 Impact on the System Performance

None.

2.6.2 Impact on Other Features

None.

(41)

2.6.3 Defects

None.

2.7 Terms and Abbreviations

Terms

Term Definition

Plug-and-Play Plug-and-Play (PnP) is a reference to the ability of an NMS to automatically configure a device added to the network through DHCP. Through PnP, you can commission remote devices in a centralized manner.

Acronyms

Acronym Full Spelling

PNP Plug-and-Play

(42)

(43)

3

L2TP Access

About This Chapter

3.1 Introduction 3.2 References 3.3 Availability 3.4 Enhancement 3.5 Principles 3.6 Applications 3.7 Impact

3.1 Introduction

Definition

Virtual Private Dial Network (VPDN) is a virtual private network implemented through the dial-in function of a public network such as an Integrated Services Digital Network (ISDN) and a Public Switched Telephone Network (PSTN) and access networks. This technology is often used to provide remote access for enterprises, small Internet Service Providers (ISPs), mobile staff.

Adopting a special encryption communication protocol, the VPDN sets up safe virtual private networks over a public network for enterprises. In this manner, oversea organizations of enterprises and staff traveling on business can access the headquarters across the public network through an encrypted virtual tunnel. Users on the public network, however, cannot access the resources inside the enterprise network through this virtual tunnel.

Among multiple protocols used by VPDN tunnels, the most popular protocol is the Layer 2 Tunneling Protocol (L2TP).

PPP defines an encapsulation mechanism for transmitting multi-protocol packets across Layer 2 point-to-point links. Therefore, it needs to be run on the connections between users and Network Access Servers (NASs).

(44)

3 L2TP Access

Issue 01 (2010-06-25)

L2TP supports the tunneling of PPP-encapsulated packets. It extends the PPP model by allowing the Layer 2 and PPP endpoints to reside on different devices interconnected through the packet switching technology.

With L2TP, a user can set up an end-to-end PPP session on a non-point-to-point network. L2TP combines advantages of the Layer 2 Forwarding (L2F) and Point-to-Point Tunneling protocol (PPTP), and therefore is standardized by the IETF.

L2TP involves the following concepts: Users

In an L2TP networking, users are devices (such as PCs) to access a private network. The access modes and locations of VPDN users are always changing. In this situation, VPDN users can set up connections with an L2TP Access Concentrator (LAC) through the PSTN or ISDN or directly accesses the Internet to communicate with the server of the headquarters.

A user is always the initiator of a PPP negotiation. Therefore, the user is both a Layer 2 PPP link end and a PPP session end.

LAC

An L2TP Access Concentrator (LAC) is a device on the switched network, with the capability of terminating PPP packets and performing L2TP functions. Usually, the LAC is an access device of the local ISP, such as the NAS, which provides access services for users through the PSTN or ISDN.

The LAC tunnels individual PPP packets to the NAS through L2TP tunnels and PPP sessions. An LAC can provide services not only for a specified VPN but also for multiple VPNs.

The LAC sits between the L2TP Network Server (LNS) and a remote system (remote subscribers and branches), as shown in Figure 3-1.

Figure 3-1 VPDN model based on L2TP

L2TP tunnel LAC _LNS Remote subscriber Internal server Remote branch NAS PSTN/ ISDN

The LAC exchanges packets between the LNS and the remote system. It sends packets from the remote system to the LNS after the L2TP encapsulation process, and sends packets from the LNS to the remote system after the decapsulation process.

The LAC and the remote system can be connected through local links or PPP links. Usually, PPP links are used between VPDN users and the LAC. The LAC is both an end to responds to users' requests and a PPP link end.