ERX-700/1400

Edge Router

Product Overview Guide

Release 3.2.x
Published 9/01

Part Number: 162-00304-00

Unisphere Networks Inc.
10 Technology Park Drive, Westford, Massachusetts 01886-3146
Copyright © 2001, Unisphere Networks, Inc. All rights reserved. No part of this documentation may
be reproduced in any form or by any means or used to make any derivative work (such as
translation, transformation, or adaptation) without written permission from Unisphere Networks.
Unisphere Networks reserves the right to revise this documentation and to make changes in content
from time to time without notification of such revision or change.
Unisphere Networks provides this documentation without warranty, term, or condition of any kind,
either implied or expressed, including, but not limited to, the implied warranties, terms, or conditions
of merchantability, satisfactory quality, and fitness for a particular purpose. Unisphere Networks may
make improvements or changes in the product(s) and/or the program(s) described in this
documentation at any time.
Unisphere Networks, the Unisphere Networks logo, ERX, ERX-700, ERX-1400, and NMC-RX are
trademarks of Unisphere Networks, Inc. All other trademarks and registered trademarks are the
property of their respective owners.

SOFTWARE LICENSE AGREEMENT1

UNISPHERE Networks, INC. IS WILLING TO LICENSE THE ENCLOSED SOFTWARE AND
ACCOMPANYING USER DOCUMENTATION (COLLECTIVELY, THE "PROGRAM") TO YOU ONLY
UPON THE CONDITION THAT YOU ACCEPT ALL OF THE TERMS AND CONDITIONS OF THIS
LICENSE AGREEMENT. PLEASE READ THESE TERMS AND CONDITIONS CAREFULLY
BEFORE COPYING OR USING THE ACCOMPANYING SOFTWARE OR INSTALLING THE
HARDWARE UNIT WITH PRE-ENABLED SOFTWARE OR USING THE ACCOMPANYING USER
DOCUMENTATION.
BY USING THE ACCOMPANYING SOFTWARE OR INSTALLING THE HARDWARE UNIT WITH
PRE-ENABLED SOFTWARE, YOU AGREE TO BE BOUND BY THE TERMS AND CONDITIONS
OF THIS LICENSE AGREEMENT. IF YOU DO NOT AGREE TO BE BOUND BY THE TERMS OF
THIS LICENSE AGREEMENT, UNISPHERE IS UNWILLING TO LICENSE THE PROGRAM TO
YOU, IN WHICH EVENT YOU SHOULD PROMPTLY WITHIN TEN (10) DAYS FROM SHIPMENT
RETURN THE UNUSED SOFTWARE, USER DOCUMENTATION, AND RELATED EQUIPMENT
AND HARDWARE TO THE PLACE OF PURCHASE AND YOU WILL RECEIVE A FULL REFUND
OF YOUR LICENSE FEE. THIS LICENSE AGREEMENT REPRESENTS THE ENTIRE
AGREEMENT CONCERNING THE PROGRAM BETWEEN YOU AND UNISPHERE, AND IT
SUPERSEDES ANY PRIOR PROPOSAL, REPRESENTATION OR UNDERSTANDING BETWEEN
THE PARTIES.
1. License Grant. Unisphere Networks, Inc. (“Unisphere”) and its suppliers and licensors hereby
grant to you and you hereby accept a nonexclusive, personal and nontransferable license to use the
computer software and/or hardware unit with pre-enabled software, including all patches, error
corrections, updates, and revisions thereto in machine-readable, object code form only (the
“Software”), and the accompanying User Documentation on the Unisphere product owned by you
and only as authorized in this License Agreement. You may make one (1) archival copy of the
Software for backup purposes provided you affix to such copy all copyright, confidentiality, and
proprietary notices that appear on the original. Except as authorized under this paragraph, no copies
of the Program or any portions thereof may be made, in whole or in part, by you or any person under
your authority or control.
The Software and User Documentation are protected under copyright laws. The title to Software and
User Documentation shall remain solely with Unisphere and its suppliers.
Except as authorized above, you shall not: copy, in whole or in part, the Software or the related User
Documentation; modify, reverse assemble, reverse compile, or otherwise translate, dissemble, or
obtain source code for the Software or User Documentation, in whole or in part, or permit a third party
to do so; rent, lease, distribute, sell, or create derivative works of the Software; pledge, lease, rent,
sublicense or share its rights under this License Agreement; or, without Unisphere's prior written
consent, assign or transfer its rights hereunder.

1 If you and Unisphere Networks, Inc., have executed another license agreement for the Program
which is now in effect, then such agreement (“Negotiated Agreement”) shall supersede this Software
License Agreement and shall exclusively govern the use and license terms of the Program.
2. Unisphere's Rights. You agree that the Software, including the User Documentation, embodies
Unisphere's and its suppliers' and licensors' confidential and proprietary intellectual property
protected under U.S. copyright law and you will use your best efforts to maintain their confidentiality.
You further acknowledge and agree that Unisphere or its suppliers and licensors own all right, title,
and interest in and to the Software, including all intellectual property rights therein. You shall take no
action inconsistent with Unisphere's or its suppliers' ownership of such Software. You shall not
sublicense, assign, or otherwise disclose to any third party the Software or any information about the
operation, design, performance, or implementation of the Software and User Documentation without
prior written consent of Unisphere. You agree to implement reasonable security measures to protect
such confidential and proprietary information and copyrighted material. This License Agreement
does not convey to you an interest in or to the Program, but only the limited right of use revocable in
accordance with the terms of this License Agreement.
3. License Fees. The license fees paid by you are paid in consideration of the license granted
under this License Agreement.
4. Term. This license is effective upon opening of the package(s) or use of the hardware containing
the Software, and shall continue until terminated. You may terminate this License at any time by
returning the Software, including any User Documentation, and all copies or portions thereof to
Unisphere. This License will terminate immediately without notice from Unisphere if you breach any
term or provision of this License. Upon such termination by Unisphere, you must return the Software,
including any User Documentation, and all copies or portions thereof to Unisphere. Termination of
this License Agreement shall not prejudice Unisphere's rights to damages or other available remedy.
5. Limited Software Warranty: Unisphere warrants, for your benefit alone, that for a period of
ninety (90) days from the date of shipment from Unisphere that the Software substantially conforms
to its published specifications.
The limited warranty extends only to you as the original licensee. Your exclusive remedy and the
entire liability of Unisphere and its suppliers under this limited warranty will be, at Unisphere's option,
repair or replacement of the Software, or refund of the amounts paid by you under this License
Agreement. You agree that this is your sole and exclusive remedy for breach by Unisphere, its
suppliers or its licensors of any warranties made under this License Agreement.
In no event does Unisphere warrant that the Software is error free or that you will be able to operate
the Software without problems or interruptions. Unisphere does not warrant: 1) that the functions
contained in the software will meet your requirements; 2) that the Software will operate in the
hardware or software combination that you may select; 3) that the operation of the Software will be
uninterrupted or error free; or 4) that all defects in the operation of the Software will be corrected.
This warranty does not apply if the product: 1) has been altered, except by Unisphere; 2) has not
been installed, operated, repaired, or maintained in accordance with instruction supplied by
Unisphere; or 3) has been subjected to or damaged by improper environment, abuse, misuse,
accident, or negligence.
EXCEPT FOR THE WARRANTIES SET FORTH ABOVE, THE SOFTWARE IS LICENSED “AS IS,”
AND UNISPHERE DISCLAIMS ANY AND ALL OTHER REPRESENTATIONS, CONDITIONS, AND
WARRANTIES, WHETHER EXPRESS, IMPLIED, OR STATUTORY, INCLUDING, WITHOUT
LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE OR ANY WARRANTIES FOR NONINFRINGEMENT OR ARISING FROM
A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. ANY AND ALL SUCH WARRANTIES
ARE HEREBY EXCLUDED TO THE EXTENT ALLOWED BY APPLICABLE LAW. UNISPHERE'S
SUPPLIERS AND LICENSORS DO NOT MAKE OR PASS ON TO YOU OR ANY THIRD PARTY
ANY EXPRESS, IMPLIED, OR STATUTORY WARRANTY OR REPRESENTATION, INCLUDING,
BUT NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE OR ANY WARRANTIES FOR NONINFRINGEMENT.
6. Proprietary Rights Indemnification. Unisphere shall at its expense defend you against and,
subject to the limitations set forth elsewhere herein, pay all costs and damages made in settlement or
awarded against you resulting from a claim that the Program as supplied by Unisphere infringes a
United States copyright or a United States patent, or misappropriates a United States trade secret,
provided that you: (a) provide prompt written notice of any such claim, (b) allow Unisphere to direct
the defense and settlement of the claim, and (c) provide Unisphere with the authority, information,
and assistance that Unisphere reasonably deems necessary for the defense and settlement of the
claim. You shall not consent to any judgment or decree or do any other act in compromise of any
such claim without first obtaining Unisphere's written consent. In any action based on such a claim,
Unisphere may, at its sole option, either: (1) obtain for you the right to continue using the Program,
(2) replace or modify the Program to avoid the claim, or (3) if neither (1) nor (2) can reasonably be
effected by Unisphere, terminate the license granted hereunder and give you a pro rata refund of the
license fee paid for such Program, calculated on the basis of straight-line depreciation over a
five-year useful life. Notwithstanding the preceding sentence, Unisphere will have no liability for any
infringement or misappropriation claim of any kind if such claim is based on: (i) the use of other than
the current unaltered release of the Program and Unisphere has provided or offers to provide such
release to you for its then current license fee, or (ii) use or combination of the Program with programs
or data not supplied or approved by Unisphere if such use or combination caused the claim.
7. Year 2000 Warranty. The following sets forth Unisphere's warranty relating to issues surrounding
the year 2000, and the processing of data by the Software for dates between the 20th and 21st
centuries. Unless otherwise specified in writing, the Software licensed to you by Unisphere will be
Year 2000 compliant, meaning it will fully satisfy the British Standards Institution's definition of Year
2000 conformity, as set forth in BSI's document PD2000-1:1998; namely, that neither performance
nor functionality is affected by dates prior to, during, and after the year 2000 and in particular that:
(a) No value for current date will cause any interruption in operation;
(b) Date-based functionality must behave consistently for dates prior to, during, and after year
2000;
(c) In all interfaces and data storage, the century in any date must be specified either explicitly or by
unambiguous algorithms or inferencing rules; and
(d) Year 2000 must be recognized as a leap year.
The warranty set forth above does not cover the Software which is modified by anyone other than
Unisphere or which is integrated into software or products other than the Software. Moreover,
Unisphere is not responsible for whether or not other software or any equipment is Year 2000
compliant or for the consequences of other software's or equipment's lack of such Year 2000
compliance.
In the event that any Software covered by this warranty is Year 2000 noncompliant in any respect,
and provided that you: (i) have notified Unisphere in writing promptly after the occurrence of the
noncompliance; (ii) the noncompliance can be reproduced; and (iii) the noncompliance occurs in the
most recent version of the Software delivered to you, Unisphere's obligation and your exclusive
remedy for any breach of this warranty will be the following: Unisphere shall, at no cost to you,
promptly correct the Year 2000 noncompliance or provide Year 2000 compliant Software to you, as
Unisphere elects in its sole discretion. However, if neither of these alternatives is available on terms
that are reasonable in Unisphere's judgment, Unisphere will remove the noncompliant Software and
refund to you the net book value of such Software after deducting depreciation calculated on a
straight-line basis over a 2-year term beginning on its installation date. EXCEPT FOR THE REMEDY
STATED ABOVE, UNISPHERE WILL HAVE NO OBLIGATION OR LIABILITY FOR LOSSES OR
DAMAGES, INCLUDING BUT NOT LIMITED TO INDIRECT, INCIDENTAL, OR CONSEQUENTIAL
DAMAGES ARISING OUT OF OR IN CONNECTION WITH YEAR 2000 NONCOMPLIANCE, EVEN
IF UNISPHERE HAS KNOWLEDGE OF THE POSSIBILITY OF SUCH LOSSES OR DAMAGES.
EXCEPT FOR THE WARRANTY SET FORTH ABOVE, UNISPHERE MAKES NO
REPRESENTATIONS OR WARRANTIES IN CONNECTION WITH THE YEAR 2000 COMPLIANCE
OR NONCOMPLIANCE, AND UNISPHERE EXPRESSLY DISCLAIMS ANY AND ALL SUCH
WARRANTIES INCLUDING, BUT NOT LIMITED TO, ANY IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
8. Limitation of Liability. IN NO EVENT WILL UNISPHERE OR ITS SUPPLIERS OR LICENSORS
BE LIABLE FOR ANY COST FOR SUBSTITUTE PROCUREMENT; SPECIAL, INDIRECT,
INCIDENTAL, PUNITIVE, EXEMPLARY, OR CONSEQUENTIAL DAMAGES; OR ANY DAMAGES
RESULTING FROM INACCURATE OR LOST DATA OR LOSS OF USE OR PROFITS ARISING
OUT OF OR IN CONNECTION WITH THE PERFORMANCE OF THE SOFTWARE, EVEN IF
UNISPHERE HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Unisphere's
cumulative liability to you or any other party for any loss or damages resulting from any claims,
demands, or actions arising out of or relating to this License Agreement shall not exceed the total
fees paid to Unisphere for the Software.
9. Export Control. Software, including technical data, is subject to U.S. export control laws,
including the U.S. Export Administration Act and its associated regulations, and may be subject to
export or import regulations in other countries. You agree to comply strictly with all such regulations
and acknowledge that you have the responsibility to obtain licenses to export, re-export, or import
Software.
10. Government Licensees: If any Software or associated documentation is acquired by or on
behalf of a unit or agency of the United States government, the government agrees that such
Software or documentation is a “commercial item” as that term is defined in 48 C.F.R. 2.101,
consisting of “commercial computer software” or “commercial computer software documentation” as
such terms are used in 48 C.F.R. 12.212 of the Federal Acquisition Regulations and its successors
and 48 C.F.R. 227.7202-1 through 227.7202-4 of the DoD FAR Supplement and its successors. The
use, duplication, or disclosure by the United States government of technical, data, computer software
and documentation is subject to the restrictions set forth in FAR section 12.212(a), FAR section
52.227-14(g)(2), FAR section 52.227-19, DFARS section 252.227-7015(b), DFARS section
227.7202-1(a), and DFARS section 227.7202-3(a), as applicable. All United States government end
users acquire the Software with only the rights set forth in this License Agreement.
11. General: This License shall be governed by and construed in accordance with the laws of the
Commonwealth of Massachusetts, United States of America, as if performed wholly within the state
and without giving effect to the principles of conflict of law. Any dispute arising out of this Agreement
shall be referred to an arbitration proceeding in Boston, Massachusetts, in accordance with the
commercial arbitration rules of the American Arbitration Association (the “AAA”). If the parties cannot
agree upon an arbitrator, arbitration shall be conducted by a neutral arbitrator selected by the AAA
who is knowledgeable in electronics equipment manufacturing and software licensing. The parties
shall share the procedural costs of arbitration equally, and each party shall pay its own attorneys'
fees and other costs and expenses associated with the arbitration, unless the arbitrator decides
otherwise. The arbitrator's award shall be in writing and shall include a statement of reasons, but the
arbitrator shall not be permitted to award punitive or indirect damages. The arbitrator's decision and
award shall be final and binding and may be entered in any court having jurisdiction. The terms of
this section shall not prevent any party from seeking injunctive relief in any court of competent
jurisdiction in order to protect its proprietary and confidential information. If any term or provision
hereof is found to be void or unenforceable by a court of competent jurisdiction, the remaining
provisions of this License Agreement shall remain in full force and effect. This License Agreement
constitutes the entire agreement between the parties with respect to the use of the Software and
User Documentation and supersedes any and all prior oral or written agreements, discussions,
negotiations, commitments, or understandings. No amendment, modification, or waiver of any
provision of this License Agreement will be valid unless in writing and signed by the authorized
representative of the party against which such amendment, modification, or waiver is sought to be
enforced. The waiver by either party of any default or breach of this License Agreement shall not
constitute a waiver of any other or subsequent default or breach. This License Agreement shall be
binding upon the parties and their respective successors and permitted assigns.
Should you have any questions about this agreement, please contact
Unisphere Networks, Inc.
10 Technology Park Drive
Westford, MA 01886-3146
Attn: Contracts Administrator
Contents

About This Guide

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Using the Online Documentation CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Online Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Comments About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Chapter 1 ERX System Overview

Product Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
ERX System Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
ERX System Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
ERX System Product Strengths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Unparalleled Port Density . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
Sustained Wire-Speed Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
Exceptional Reliability and Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
Hardware Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9
Software Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9
Support for IP Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9
Comprehensive Management Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10
Applications Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
Private Line Aggregation Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
xDSL Aggregation Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
Cable Subscriber Management Application . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
VLAN Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
Fixed Wireless Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17
Standards Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-18
viii
Contents

Chapter 2 Hardware Overview

Hardware Design Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
ERX System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
System Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Unisphere’s ASIC Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
ASIC Chip Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
RISC + ASIC Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
Hardware Assist Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
Redundancy Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
1:1 Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
1:N Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
Port Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
ERX System Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
Power System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
Fans/Air Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
System Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
SRP Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
Switching Fabric Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
System Start-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12
Line Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12
TSMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18
Ranges for Line Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19
Future Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21

Chapter 3 Software Overview

Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Software Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Software Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
ERX Software Traffic Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5
Packet Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6
IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
IP Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
RTR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
IP/PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
PPP Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12
PPP Statistics Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
Multilink PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14
IP/FR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14
Frame Relay Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15
Configurable LMI Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17
Multilink Frame Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18
IP/ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18
ATM Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19
ATM Protocol Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20
 ix
ERX Edge Routers

IP/Cisco HDLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21

Cisco HDLC Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21
Bridged IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-22
DS3/DS1/E3/E1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-22
Line Module Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23
Configurable HDLC Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-24
SONET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-24
SONET Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-25
SONET Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-25
Switched Multimegabit Data Service (SMDS) . . . . . . . . . . . . . . . . . . . . . . . . . 3-26
SMDS Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-26
SMDS Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-28
Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-28
Routing Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-29
The ERX Routing Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-29
Route Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-31
Virtual Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-32
BGP-4 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-33
BGP Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-33
IS-IS Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-34
IS-IS Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-34
OSPF Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-36
OSPF Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-36
RIP Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-37
RIP Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-37
MPLS Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-37
MPLS Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-38
MPLS Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-38
BGP/MPLS VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-38
IP Multicasting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-41
IGMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-42
PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-42
DVMRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-43
BGP Multicasting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44
IP QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44
Bandwidth Over Subscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44
Converged Network Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-45
The ERX System Implementation of QoS . . . . . . . . . . . . . . . . . . . . . . . . . 3-46
Traffic Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-48
Scheduler and QoS Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-48
QoS Support for MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-49
Congestion and Backpressure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-50
QoS Feature Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-50
Benefits Provided By the ERX System . . . . . . . . . . . . . . . . . . . . . . . . . 3-51
Application Scenarios With the ERX System . . . . . . . . . . . . . . . . . . . . . . . 3-51
Real-time Audio and Video . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-51
Guaranteed Bandwidth Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-52
Media Gateway Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-53
x
Contents

Policy Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-54

Policy Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-55
Classifier Control Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-55
Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-55
Rate-Limit Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-56
Dynamic Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-57
Autodetection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-58
RADIUS Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-58
Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-58
B-RAS Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-59
B-RAS Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-59
B-RAS Protocol Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-60
B-RAS Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-61
Zero-Touch Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-62
RADIUS Server Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-62
Basic Client-to-Server Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-62
Non-PPP Equal Access Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-64
DHCP Local Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-64
SSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-65
HTTP Local Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-65
The Connection Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-65
L2TP Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-67
L2F Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-68
VLAN Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-69
Interface Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-70

Chapter 4 Element and Network Management

Network Management Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
Managing the ERX System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
SNMP Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
RFCs Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
SNMP Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5
SNMP Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
ATM MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
BGP-4 MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
Ethernet MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
Frame Relay MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
Interface MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
IP MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
OSPF MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
PPP MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
RIP MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
SNMP MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
SNMP v3 MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
SONET MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
UDP MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
Unisphere Enterprise MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
 xi
ERX Edge Routers

Command Line Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9

Script Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10
External CLI Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10
Scripting Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10
Collecting Bulk Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
Security Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
NMC-RX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14
NMC-RX Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14
NMC-RX Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14
Relational Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15
Java Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15
Polling Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16
ConfigSync Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16
Streamlined Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16
NMC-RX Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17
Intuitive Workshop Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17
Streamlined Provisioning via Templates . . . . . . . . . . . . . . . . . . . . . . . . 4-19
Statistics Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20
Customer-Driven Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20
OSS Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-21
UMC Application Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-22
Service Selection Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-22
Intelligent Service Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23
Dynamic, On-Demand Service Activation . . . . . . . . . . . . . . . . . . . . . . 4-24
Web-Based Customizable Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24
Integration with OSS and Billing Applications . . . . . . . . . . . . . . . . . . . 4-24
UMC Meta Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-25
Extended Service and Subscriber Management . . . . . . . . . . . . . . . . . . . . . . 4-25
Integration Packs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26
Topology Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26
Fault Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26
Performance Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-27
Additional Partners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-27

Chapter 5 Statistics, Accounting, and Diagnostics

Statistics and Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1
Monitoring and Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Module Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Event Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
Diagnostic Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
Protocol Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
Loopback Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
Test Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
Dump Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
Show Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
xii
Contents

Product Upgrades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7

System Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
Configuration Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8

Chapter 6 Service and Support

Factory Warranty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
Professional Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
Preconfiguration Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
Educational Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
Technical Assistance Center (TAC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
Hardware Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
Contacting Unisphere Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
Telephone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
E-mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
Web Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3

Chapter 7 Applications Overview

Private Line Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
XDSL Session Termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4
Virtual Private Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-7
Cable Subscriber Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9
MPLS for Traffic Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12
MPLS for VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-14
SLA Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-16
Non-IP Protocol Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-16
VoIP Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-17
Wholesaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-18
End-to-End QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-20
VLAN Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-22
Fixed Wireless Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-23
Index
About This Guide

Introduction
This guide is an overview of the ERX system that describes product
features and contains helpful illustrations, presenting you with a broad
view of the system.
This document describes both current and future product functionality in
order to give you a complete overview of the product, its architecture
potential, and its development direction. All functions covered in the
manual are expected to be delivered during 2001.
However, Unisphere reserves the right to change, modify, or delete any
of the future functionality described in this guide.

Documentation
The document set contains the following books and online resources:
• Quick Start Guide – Provides the basic procedures to get the system
up and running quickly.
• Installation & User Guide – Provides the necessary procedures for
getting your system operational, including information on installing,
cabling, powering up, configuring your system for management
access, and general troubleshooting.
• System Basics Configuration Guide – Describes planning and
configuring your network, managing the system, passwords, and
security, and configuring the system clock and virtual routers.
• Physical and Link Layers Configuration Guide – Describes configuring
physical and link layer interfaces.
xiv
About This Guide

• Routing Protocols Configuration Guide, Vol. 1 – Provides information

about configuring routing policy, policy management, and routing
protocols such as IP, IP Multicast, and IS-IS.
• Routing Protocols Configuration Guide, Vol. 2 – Describes BGP
Routing, MPLS, and related VPNs.
• ERX Broadband Access Configuration Guide – Provides information
about configuring remote access.
• Command Reference Guide – Contains important information about
all system commands implemented in the system software. Use to
look up command descriptions, command syntax, a command’s
related mode, or a description of a command’s parameters. It is
intended to be used in conjunction with the Configuration Guides.
• Product Overview Guide – Gives a thorough overview of the system
from a software and hardware perspective. It provides illustrations
and configuration examples that present the “big picture.”
• Release Notes – Contains information about features, changes,
known problems, and limitations. Provides final information that
did not make it into the documentation.
• Online Doc CD – Provides an online version of this guide and the
documents listed above. The online documents contain numerous
links between guides, giving easy access to a vast amount of
technical information.

Using the Online Documentation CD

To use the Online Documentation CD, follow these instructions:

1 Place the Online Documentation CD in your CD-ROM drive.
2 Follow the instructions located on the inside cover of your CD jewel
case to install Acrobat Reader.
3 From the Documentation folder on the CD, open the CDtips.pdf file for
information on using Adobe Acrobat Reader.
4 From the Documentation folder on the CD, open the Welcome.pdf file for
access to the documentation set.
 Online Information xv
ERX Edge Routers

Online Information
More information about Unisphere and its ERX family of products is
available on our corporate Web site at www.unispherenetworks.com.
For our ERX system customers, a password-protected Web site is
available. Please contact Unisphere Customer Service for access
information.

Comments About the Documentation

Unisphere Networks encourages you to provide feedback, comments,
and suggestions so that we can improve the documentation to better
meet your needs. Please e-mail your comments to:
• techpubsComments@unispherenetworks.com
Along with your comments, be sure to indicate:
• Document name
• Document Part Number
• Page number
xvi
About This Guide
ERX System Overview

This chapter provides a general overview of the ERX system.

Topic Page
Product Description 1-1
ERX System Models 1-2
ERX System Components 1-4
ERX System Product Strengths 1-6
Applications Overview 1-11
Standards Support 1-18

Product Description
The Unisphere ERX system is a new-generation edge router built to
address service provider challenges at the edge of the Internet. The
system is the ideal platform for service providers who need to meet
large-scale demands for IP access.
The system offers:
• Unparalleled port density to conserve scarce point-of-presence
(POP) space and power
• Sustained wire-speed routing under the most demanding traffic
patterns
• Exceptional reliability and availability to meet the requirements for
strict service level agreements (SLAs)
• Support for multiple IP service classes to provide the foundation for
virtual private networks (VPNs) and premium services deployment
1-2 CHAPTER 1
ERX System Overview

ERX System Models

The ERX system is available in two models: a high-capacity 14-slot
model and a midrange 7-slot model. The 14-slot ERX-1400 can
accommodate large service providers. See Figure 1-1 and Figure 1-2.

line module
redundant SRP module

SRP module

line module

SRP
SRP SRP
SRP

Figure 1-1 ERX-1400 Front View

 ERX System Models 1-3
ERX Edge Routers

OC3 CT3 CT3 CT3 CT3 CT3 CT3 CT3 OC3 CT3 CT3 CT3
I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O

SRP I/O Module

I/O module

SINGLE SINGLE
MODE MODE

Figure 1-2 ERX-1400 Back View

The 7-slot ERX-700 is for service providers who require less capacity
but still need a robust, high-density system. See Figure 1-3 and
Figure 1-4.

line module
OC3
CT3
CT3
CT3

line module
CT3

redundant SRP Module

SRP

SRP Module
SRP

Figure 1-3 ERX-700 Front View

1-4 CHAPTER 1
ERX System Overview

I/O module

OC3
SINGLE

I/O
MODE

CT3
I/O
CT3
I/O
CT3
I/O
I/O module

CT3
I/O
SRP I/O Module

Figure 1-4 ERX-700 Back View

ERX System Components

The ERX system consists of several components, including:
• A fan-cooled 7-slot or 14-slot chassis with a midplane architecture
• A distributed power system that adds power as modules are added to
the chassis
• A high-performance switch route processor (SRP) module with a 5,
10, or 40 Gbps switching fabric
• Line modules and input/output modules that support the system’s
distributed architecture
• System software that supports:
> Full routing capabilities for BGP-4, IS-IS, OSPF, and RIP
> Advanced routing support for MPLS
> QoS policy control and enforcement for IP and ATM
> IP traffic handling for multiple encapsulation types
> IP session termination
> Broadband Remote Access Server (B-RAS) features
> IP VPN creation
> IP wholesale support
• Network management systems’ options for configuring,
provisioning, managing, diagnosing, and accounting
• Complete documentation available in hard copy or CD-ROM and
integrated online Help
 ERX System Components 1-5
ERX Edge Routers

The ERX-700 and ERX-1400 are edge routing switches, optimized

for the termination of high-speed physical and logical IP connections.
The ERX platform enables service providers to deliver new
higher-speed, service-differentiated Internet connections to their
subscribers with increased profitability. Routing switches are a next
generation of products that take advantage of advances in
high-performance switching technology to deliver wire-speed routing
with quality of service (QoS) functionality.
Examples of the line modules that receive traffic into and forward traffic
out of the system chassis are shown in Figure 1-5.

xDSL
IP/PPP/ATM OC12/STM4
ATM
Service Provider Internet
Edge Network

xDSL ERX System

IP/Eth/PPP/ATM OC12/STM4
Telco POS
VPN
T1/E1/FT1/FE1 Network
IP/Frame (SONET/SDH)

Fast Ethernet and

OC3/STM1
Gigabit Ethernet
ATM
T3/FT3/E3 ISP
IP/PPP

OC3/STM1
VLAN/Ethernet POS
CLEC

Figure 1-5 The ERX System Supports a Variety of Ingress and Egress Traffic Types

The system is capable of handling all edge aggregation functions in its

single high-performance platform. These functions include:
• Receiving ingress traffic and stripping the encapsulation method to
retrieve native IP packets
• Examining IP packets at wire speed in order to apply QoS, VPN,
and routing policies
• Gathering detailed statistics and accounting information on each
packet
1-6 CHAPTER 1
ERX System Overview

• Routing IP packets into the network, through BGP-4, IS-IS OSPF,

RIP, or static routes
A variety of ERX line modules and the protocols they support are
identified in Table 1-1. Any line module can be used for ingress or
egress without restrictions.

Table 1-1 ERX Interface Types with Transport Protocol

Physical Interface Transport Protocol

Channelized T3 (T1, FT1, DS0)
Channelized T1 (T1, FT1)
Channelized E1 (E1, FE1)
Channelized OC3/STM1
Channelized OC12/STM4
Fast Ethernet (10/100 Base-T)
Gigabit Ethernet (1000 Base-LX/SX) PPPoE/VLAN
HSSI
OC3c/STM1
OC12c/STM4
OC48
Unchannelized T3/E3
X.21/V.35
IP/PPP, IP/Frame Relay, Cisco HDLC
IP/PPP, IP/FR, Cisco HDLC
IP/Ethernet, IP/PPPoE/Ethernet, IP/VLAN,
IP/PPP, IP/Frame Relay, IP/HDLC
IP/ATM, IP/POS, IP/PPP/Ethernet/ATM,
IP/PPP/ATM
IP/POS
IP/PPP, IP/Frame Relay, IP/ATM,
IP/PPP/ATM, IP/PPP/Ethernet/ATM
IP/PPP, IP/Frame Relay, IP/HDLC

ERX System Product Strengths

The most powerful product strengths of the ERX edge routing switch
include the following:
• Superior physical and logical density
• Wire-speed performance
• Scalability
• Carrier-class product design
• IP services, such as QoS, VPNs, security, flexible bandwidth, and
routing
• Comprehensive network management
Each of these is briefly described in the following sections.
 ERX System Product Strengths 1-7
ERX Edge Routers

Unparalleled The system offers a ten to one hundred times density improvement
Port Density over current-generation solutions, with the industry’s highest port
density in an Internet edge device. A single ERX-1400 22.75-inch
shelf supports more than 24,000 fractional T1 terminations and up to
100,000 IP interfaces, while drawing less than 25 Amps of power. Up
to three shelves may be stacked in a standard 7-foot rack, ensuring
optimal use of scarce POP space.

Sustained Internet traffic studies have shown that nearly half the packets traversing
Wire-Speed the backbone are less than 44 bytes in length. These smaller packets,
Routing generated by Web-intensive applications, necessitate more packet per
second (pps) performance to deliver wire-speed routing. Using an
average packet size of 40 bytes, an OC3/STM1 (155 Mbps) line
module running ATM must route more than 300,000 pps to keep the
trunk full, while OC-12 (622 Mbps) running ATM requires nearly 1.4
million pps of routing performance.
The ERX system implements a next-generation architecture relying on
a combination of IP-optimized ASICs and standard RISC processors to
deliver maximum wire-speed performance on all interfaces. This
wire-speed performance is maintained even with all features in use,
including statistics gathering, accounting, QoS policy enforcement, and
routing.

Scalability The system has a highly scalable design. As more line modules are
added to a chassis, more packet-processing power is added on.
The ERX-700 and ERX-1400 systems support:
• Copper T1/E1 interfaces for T1/E1 and FT1/FE1 and support for
up to 288 T1s and 6912 FT1s/FE1s per chassis
• Copper T3/E3 interfaces for unchannelized T3/E3 and support for
up to 144 T3/E3s and CT3 support for up to 24,000 FT1s per
chassis
• Channelized optical OC3/STM1 and OC12/STM4 interfaces for
up to 12 OC12/STM4s, 48 OC3/STM1s, 144T3s/E3s,
4000T1s/E1s, 24,000 DS0s
• 48 OC3/STM-1 ATM ports per chassis
• 48 OC3/STM-1 POS ports per chassis
• 12 OC12/STM1 ATM ports per chassis
• 12 OC12/STM1 POS ports per chassis
1-8 CHAPTER 1
ERX System Overview

• 12 Gigabit Ethernet ports per chassis

• 96 Fast Ethernet ports per chassis
• Up to 6 ERX-700 chassis per 7-foot rack; up to 3 ERX-1400
chassis per 7-foot rack
• 100,000 independent IP interfaces, allowing service providers to
deploy the system for IP session termination applications, such as
aggregating the output from DSLAMs for broadband RAS (B-RAS)
applications
• 100,000 PPP sessions per chassis
• 12,000 Frame Relay virtual circuits per chassis
• 128,000 ATM virtual circuits per chassis
• Up to 1,500,000 route table entries
• Up to 1,000 virtual routers within a single ERX system to allow
service providers to configure multiple separate, secure routers
within a single chassis
• 400 BGP-4 peers and more than 1,500,000 routes for interaction
with external networks, such as peer and wholesale networks
• 100 IS-IS adjacencies and 10,000 IS-IS routes for use by large
service providers as the interior routing protocol to share route table
information between routers in the same service provider network
• 100 OSPF adjacencies and 10,000 OSPF routes for use by large
service providers as the interior routing protocol to share route table
information between routers in the same service provider network
• Up to 64,000 individual queues to support six QoS service levels:
Platinum, Gold, Silver, Bronze, Best Effort, and a Network Control
level for management. service providers can set the relative ERX
buffer and bandwidth levels to define a series of service classes.
• 32 policy management rules per IP interface for traffic classification
with support for up to 96,000 rules per system

Exceptional The level of reliability required on IP networks is fast approaching the

Reliability and level that is currently available on the global voice network. In
Availability recognition of this trend, the ERX system is designed for continuous
availability and consistent high performance to achieve the service
levels required from carriers as more mission critical applications are
added to IP networks.
 ERX System Product Strengths 1-9
ERX Edge Routers

Hardware Design
The ERX system supports full-logic and line module redundancy,
hot-swap components, an innovative distributed DC power system,
front-to-back airflow strategy, and is certified for Telcordia
Technologies NEBS Level 3 standards. These features decrease the time
and complexity of maintenance functions, while allowing service
providers to confidently deliver network reliability guarantees as part of
overall SLAs.

Software Design
Reliability is as much a function of software architecture as it is
hardware. With this in mind, Unisphere engineers have implemented a
high-performance modular, object-oriented software design. Each
program module has access to dedicated system resources, including
memory, packet buffers, and processor cycles. This approach improves
stability and reliability by ensuring that the behavior of one module
does not adversely affect others. When compared with the monolithic
operating systems of first-generation routers, this approach provides
more predictable behavior and reduces the possibility of overall system
failure.
The combination of carrier-grade hardware and innovative software
design helps decrease the time and complexity of maintenance
functions, lowering overall operations costs, and increasing subscriber
satisfaction.

Support for IP With the transformation of the Internet into a commercial

Services infrastructure, the ability to provide differentiated services to users with
widely varying requirements is becoming as important as meeting
bandwidth demands. Service providers must be able to deliver a
number of IP service profiles tailored to their subscribers such as:
• VPNs
• Differentiated traffic handling
• Secure routing
• Varied bandwidth policies
To deliver these policy-based services, the system identifies critical data
flows and defines profiles at wire speed for thousands of simultaneous
subscriber flows.
1-10 CHAPTER 1
ERX System Overview

The ERX system has inherent strength for IP QoS delivery that can
prevent a low-priority application from monopolizing bandwidth, or
prevent aggressive users from consuming network bandwidth and
degrading the performance of other users. This capability differentiates
premium and standard classes of Internet traffic, allowing service
providers to work toward increasing reliability for their business
subscribers, and away from the traditional “best effort” IP delivery
system.
The ERX system’s policy-based QoS allows service providers to
increase revenues and strengthen brand recognition by offering tiered
bandwidth, varied service levels, and pricing options. For example, one
service offering may include a premium-priced Gold service, midpriced
Silver service, and low-priced Bronze service. In addition, the system
gives service providers the platform redundancy they need to offer
SLAs with guaranteed performance.
The ERX system also gives service providers the capability to offer
VPN services for wholesaling applications and corporate outsourcing.
The system’s VPN capabilities can also be layered with the system’s
QoS services to support specialized VPN services with delivery
guarantees.

Comprehensive Some service providers estimate that they use more than 75 percent of
Management their operating budget for on-going network operations. Unisphere
Tools recognizes two key facts:
1 Network management is often the most important long-term product
consideration
2 Service providers need to integrate new products into existing
operational support systems (OSSs) and operational procedures that are
already in place.
Unisphere’s ERX system offers a wide range of network management
options, which include:
• Support for industry-standard command line interface
• An automated scripting language
• Full SNMP SET and GET support
• Leading-edge JAVA-based external management applications
• Integration into existing OSS
• Leading-edge support for policy management, with a standard
COPs-based management interface
 Applications Overview 1-11
ERX Edge Routers

Unisphere’s management tools allow service providers to manage the

network at the service and subscriber levels in addition to the element
level, allowing for faster initial service creation and more proactive
subscriber-based responsiveness.

Applications Overview
The ERX system can be used for a number of edge aggregation
applications: Private line aggregation, xDSL session termination, and cable
subscriber management are described in this section. More detailed
application examples are provided in Chapter 7, Applications Overview.

Private Line Service providers that want to offer high-speed Internet connections to
Aggregation their subscribers can achieve dramatic space, power, and management
Application savings with the ERX system products. See Figure 1-6. One system can
support more than 24,000 FT1 terminations, with minimal power draw
and maximum rack space to optimize scarce and expensive POP space.

Business Users

Edge Core

FT1/fE1 ERX System

ADM
T1/E1 GE
ADM Internet
SONET DACS OC3/STM1
nxT1 Ring POS/ATM Backbone
ADM T3/E3/E1 OC12/STM4
T3/E3
ATM/FR/PPP POS/ATM

Telco Service
Network Provider
Tier 2/3 Network
ISP
Network

Figure 1-6 Private Line Aggregation with the ERX System

In this application, the subscriber links can be:

• Fractional T1/E1
• T1/E1
• nxT1 or nxE1
1-12 CHAPTER 1
ERX System Overview

• T3/E3, nxT3, or nxE3

• OC3/STM1 or nxOC3/STM1
• VLANs/Ethernet (10/100 Base-T or 1000 Base-LX/SX)
The protocols supported include IP/PPP, IP/Frame Relay, IP/HDLC,
and IP/ATM from the subscriber premises. The local Telco network
may multiplex the links into a channelized copper or optical line to be
terminated by the ERX system. The system can also receive direct E1,
E3, FE, GE, OC/STM1, OC12/STM4T1, or T3 connections for
termination.
The ERX system handles all edge aggregation functions, including:
• Stripping off the encapsulation method
• Examining the IP packet and applying routing, bandwidth, security,
VPN, and QoS policies as defined by the service provider
• Routing the packet onto a POS or ATM link into the core of the
service provider network with OC3/STM1 or OC12/STM4 or via
a Gigabit or 100 Base-T Ethernet connection

xDSL The next-generation architecture of the ERX system makes it the ideal
Aggregation solution for aggregating Digital Subscriber Line Access Multiplexers
Application (DSLAMs) onto the Internet backbone. Deployed by carriers in the
central office or by service providers at the POP, the ERX system
aggregates data traffic from multiple DSLAMs from any vendor-specific
DSL implementation. The ERX system is ideal for service providers
who are faced with the challenge of a mass-market xDSL deployment.
Any type of DSLAM can be supported, including those that terminate
any of the following DSL types.
• Asymmetric digital subscriber line (ADSL)
• Rate-adaptive digital subscriber line (RADSL)
• Symmetric digital subscriber line (SDSL)
• ISDN digital subscriber line (IDSL)
• Very-high-bit-rate digital subscriber line (VDSL)
The DSLAM terminates the copper, and the ERX system provides the
logical termination for the IP session, as well as the interface to
authentication and accounting systems with Password Authentication
Protocol (PAP), Challenge Handshake Authentication Protocol
(CHAP), and Remote Authentication Dial-In User Service
 Applications Overview 1-13
ERX Edge Routers

(RADIUS). A large number of xDSL protocols are supported,

including:
• IP/PPP/ATM
• IP/PPP/Ethernet/ATM
• IP/PPP/FR
• IP/PPP/Ethernet/Frame Relay
This allows service providers to install a central site router that can
terminate signals from a wide variety of customer premise equipment
(CPE) xDSL devices.
The ERX system lets service providers offer xDSL services by
following a cost-effective dial Remote Access Server (RAS) model. All
dial OSS protocols and systems are kept in place and used by the ERX
system to implement oversubscription policies for precious bandwidth
and IP resources.

Consumer &
Business CLEC
Users (xDSL)

IP/PPP/ATM ERX System

ATM/FR ISP
OC3/STM1
DS3 FR/ATM
OC3/STM1 ATM OC12/STM4
IP/PPP/FR POS/ATM
GE

DSLAM
IP/PPPoE/ATM
VPN
DHCP RADIUS

IP/PPPoE/FR Access Service

Network Network Internet
Provider Provider

Figure 1-7 XDSL Aggregation with the ERX System

The ERX system can be deployed by carriers, such as incumbent local

exchange carriers (ILECs) and competitive local exchange carriers
(CLECs), offering wholesale DSL connection services to their service
provider and corporate or consumer subscribers. See Figure 1-7.
Additionally, service providers can use the system to concentrate
Internet subscribers from a set of carriers.
1-14 CHAPTER 1
ERX System Overview

Although most vendors view DSL as a consumer service, Unisphere

recognizes that the corporate user of DSL service has different needs.
The system’s unique IP QoS capabilities give service providers the
ability to provide differentiated services to DSL subscribers. For
telecommuters using DSL services, a premium service may be
preferable to a one-size-fits-all consumer-oriented service. In addition,
all service classes benefit from the wire-speed forwarding performance,
especially under heavy traffic load.
Unlike most broadband remote access server products, the ERX system
is a fully featured first-generation routing switch, and does not require
an additional routing device to connect subscribers to one network.

Cable Multiservice operators (MSOs) offering high-speed, broadband

Subscriber Internet access services as well as new, advanced IP services to their
Management subscribers will benefit from the next-generation architecture of the
Application ERX system. The ERX system can aggregate traffic from cable modem
termination systems (CMTSs) for access to the Internet backbone
when deployed by MSOs in regional or “super” headend locations.
The system simultaneously aggregates data traffic from existing and
future cable networks by supporting both data-over-cable service
interface specifications (DOCSIS) and non-DOCSIS networks.
The CMTS is located at local hubs to terminate radio frequency (RF)
signals from cable modems (CMs) at residential and business locations.
The CMTS bridges (or routes) traffic to the system at the headend for
IP session termination. The links from the CMTS to the ERX system
can be:
• ATM
• Ethernet
• Gigabit Ethernet
• Packet over SONET
The ERX system supports a variety of encapsulation technologies to
interoperate with existing cable networks and support future equal
access initiatives. The system supports the following encapsulation
mechanisms:
• ATM 1483
• ATM 1577
• PPPoE
• L2TP
 Applications Overview 1-15
ERX Edge Routers

Consumer & Business CLEC

Users (Cable Modem)

ATM
IP/Ethernet Ethernet ERX700/1400
POS
10/100 Enet OC3/STM1 ISP
Gigabit Enet OC12/STM4
OC3 ATM
IP/ATM OC3 POS POS/ATM
Gig Eth

CMTS
IP/PPPoE
VPN
DHCP SSC
RADIUS

IP/L2TP Cable Hub Super

Headend
Internet
Cable Service Provider
HFC Network

Figure 1-8 Cable Subscriber Management Application with the ERX System

The scalability and wire-speed performance of the ERX system allows

cable operators to leverage lower-cost, layer 2 CMTS products and
preserve legacy investments. Integrated layer 3-enabled CMTS
solutions require MSOs to displace current L2 CMTS products with
more expensive equipment. Located at the regional or “super” headend
sites, the ERX system supports multiple existing service areas from a
single platform to offer advanced IP services while minimizing cost. In
addition, this model centralizes more complex network tasks to
improve the operational efficiency of the MSO when new networks
and new services are introduced.
The ERX system allows cable operators to offer differentiated services
to their subscribers to increase revenues. The unique IP QoS
capabilities of the system support tiered services to deliver multiple
service offerings to meet a variety of consumer application and
economic requirements. In addition to core static services, the system
supports on-demand services and dynamic QoS to offer pay-per-use
data services, which are analogous to the pay-per-view cable TV
services available today. While increasing revenue, these services will
also help to improve customer retention and hold off competitive
pressures from xDSL and wireless services.
Advanced QoS services of the ERX system will differentiate
latency-sensitive Voice over IP (VoIP) traffic from best effort data to
1-16 CHAPTER 1
ERX System Overview

deliver toll-quality telephony over a packet infrastructure. MSOs

competing as CLECs which use the ERX system are positioned to
offer a complete PacketCable solution.
Because the ERX system is access agnostic, the same system can be
used to deliver a consistent subscriber management and advanced IP
services platform. This platform supports a complete broadband
solution integrating xDSL, cable, and wireless into a single network.

VLAN The Unisphere ERX system offers a significant advantage to service

Implementation providers who use its powerful virtual LAN (VLAN, IEEE 802.1q)
capabilities. VLANs offer service providers the ability to logically
segregate subscribers and their traffic on a shared interface, such as
Gigabit Ethernet or Fast Ethernet.
VLANs are used in the access network as well as in the core network.
The most common scenario in the access network is “fiber to the curb”
(FTTC). In this scenario, Ethernet runs all the way from the edge
router (B-RAS) to the subscriber. Typically, an Ethernet switch,
installed in the basement of a multitenant unit (MTU), tags the
Ethernet frames of each customer before passing them onto the edge
router. On the downlink, the Ethernet switch directs the tagged
Ethernet frames to the port that corresponds with the VLAN ID.
Ethernet frames and broadcast packets remain in the same VLAN and
cannot be seen by other VLANs.
On the Ethernet uplink facing the core network, VLANs are
commonly used to logically segregate the traffic destined for services or
service providers. VLANs are typically deployed in a hosted service
environment. The access service provider can maintain a single and
shared infrastructure for a variety of wholesale customers and
applications without compromising SLAs.
Figure 1-9 shows the ERX system in a VLAN application.
 Applications Overview 1-17
ERX Edge Routers

Access

Gigabit Ethernet
IP Edge
IP Core ASP A
ERX
VLAN 1 VLAN 5
ASP B
IP/ETH VLAN 6
PPPoE
VLAN 7
Ethernet VLAN 2 ISP B
Switch
(VLAN tagged)

Policies
RADIUS
(COPS, LDAP)
DHCP

Figure 1-9 VLAN Application with the ERX System

Fixed Wireless Fixed wireless applications refer to the operation of wireless devices in
Applications homes and offices, and in particular in equipment connected to the
Internet via specialized modems. Common examples of wireless
equipment in use today include cordless phones (not to be confused
with cell phones), satellite television, and wireless LANs.
The ERX product family is the first fixed-wireless local loop (WLL)
subscriber access platform to deliver the performance, density, and
scalability for comprehensive IP service delivery in large-scale fixed-
wireless deployments. The ERX platform combines subscriber-access
functions with Tier-1-class routing and innovative IP QoS to enable
service providers to offer and deliver new, competitive IP services to
their fixed-wireless subscribers.
Deployed by carriers in the central office or by service providers at a
POP, the ERX transparently aggregates data traffic from multiple base
stations (BSs) to vendor-specific fixed-wireless implementations.
Point-to-Multipoint and WLL BS implementations based on
Multi-channel Multipoint Distribution System (MMDS), Local
Multipoint Distribution System (LMDS), and wireless LAN (WLAN)
can all be terminated using industry standard remote-access protocols
such as PPP and RADIUS. Direct connection from BSs or ATM,
Frame Relay or Ethernet aggregation switches (over SDH rings) are
supported with E3/T3, OC-3/STM-1, OC-12/STM-4 and Fast
Ethernet/Gigabit Ethernet (FE/GE) links. The output (egress) of the
ERX platform is typically a high-speed link, such as OC-3/STM-1,
OC-12/STM-4 and GE, to feed a core backbone.
1-18 CHAPTER 1
ERX System Overview

In contrast to other products, the ERX is a complete subscriber-access

platform, providing both subscriber-access services as well as service
profiles and IP network routing. The ERX terminates the connection,
manages the subscriber, applies IP services, and routes or forwards the
traffic to the core. The ERX system handles all critical fixed-wireless,
IP edge functions as well as new and advanced features, including:
• PPP session termination and authentication via PAP or CHAP
• IP address assignment via DHCP, RADIUS, or local IP address
pools
• Accounting data support via RADIUS to gather detailed billing
information and bulk statistics via FTP
• Association of the subscriber with the service profile information
via RADIUS server, domain name or sophisticated packet
classification
• Routing of session packets into the network via ATM, Frame Relay,
IP- or PPP-based tunnels, or POS to the destination defined in the
service profile

Standards Support
The ERX system software set supports a large number of IETF and
IEEE standards, including the key directives for IP, BGP-4, IS-IS,
OSPF, RIP, SNMP, PPP, ATM, Frame Relay, VLAN, multicasting
(PIM, MBGP, DVMRP, IGMP) and SONET/SDH. In addition, the
system supports emerging IP QoS standards for DiffServ and
Multiprotocol Label Switching (MPLS).
Note: The individual RFCs are detailed in the specific software sections in Chapter
3.

The ERX-700 and ERX-1400 are certified NEBS and ETSI Telecom
switching gear. The system is designed to comply with the
international standards listed in Table 1-2.
 Standards Support 1-19
ERX Edge Routers

Table 1-2 International Standards Compliance List for ERX System

Certification Type Standard

Safety IEC 950 (Asia), AS3260 (Australia and New Zealand),
CE Mark (Europe), EN 60825-1 (Europe), EN 60950
(Europe), UL 1950 and CUL 950 (US and Canada)
EMC EN 55024 (Europe), GR-63 and 1089 (US and Canada
Telcordia)
EMI AS3548 (Australia and New Zealand), EN 55022 (Europe),
CISPR 22 (Europe), VCCI (Japan),
FCC Part 15 A/B (US and Canada)
Telecom Telecom Directive (Europe), JATE (Japan),
NEBS GR-63 and 1089 Level 3 (US and Canada),
FCC Part 68 (US and Canada), IC CS-03 (Canada),
1-20 CHAPTER 1
ERX System Overview
Hardware Overview

This chapter provides a general system hardware overview and describes

all hardware components.

Topic Page
Hardware Design Overview 2-1
ERX System Chassis 2-7
Power System 2-8
Fans/Air Flow 2-8
System Modules 2-9

Hardware Design Overview

The ERX system uses a modular carrier-class design with a passive
midplane, active front-insert line modules, and high-reliability
rear-insert input/output (I/O) modules. Both the ERX-700 and the
ERX-1400 use the same line modules and I/O modules.
Consequently, service providers can limit their inventories of spare
modules, and easily upgrade from the ERX-700 to the ERX-1400 as
the subscriber base at a point of presence (POP) or central office (CO)
increases. Both systems support full redundancy and line module
hot-swapping to optimize network uptime. Figure 2-1 shows the
ERX-1400 system architecture. The ERX-700 architecture is similar;
however, the modules fit horizontally in the chassis, rather than
vertically.
2-2 CHAPTER 2
Hardware Overview

I/O modules SRP I/O module I/O modules

connection via
passive midplane

CT3
CT3 CT3 CT3 CT3 CT3 CT3 SRP SRP OC3 CT3 CT3 CT3 CT3 OC3

line modules line modules

switch route processor (SRP)
with optional redundant SRP

Figure 2-1 An Overview of the ERX-1400 System Architecture

ERX System Unisphere’s ERX system architecture is composed of three main

Architecture elements:
• A shared switch fabric that operates at 5, 10, or 40 Gbps
• Hardware-assisted forwarding engines distributed to each line
module
• A high-performance route processor for routing table maintenance
and system configuration
The system uses a highly distributed multiprocessor architecture that
distributes processing function to each port in the system to speed up
decision making and scale system growth. Consequently, the ERX
system supports next-generation routing features that provide
differentiated services, wire-speed packet filtering, buffer management,
and scheduling.
 Hardware Design Overview 2-3
ERX Edge Routers

Data Flow Figure 2-2 shows the data flow through the hardware of the system.
Line modules handle packet processing and forwarding. A switch fabric
performs high-speed internal packet switching. A route processor
gathers the routing table information and sends route tables and updates
to the line modules.

I/O SRP I/O I/O

1

2 1 Packet enters via ingress port.

2 Packet passes via connector to line module.
6 3 Line module manages routing and QoS
Midplane policies.
4 Packet is routed to egress line module via
fabric.
5 Egress line module schedules packet onto
uplink with QoS policy.
4 5
3 6 Packet passes via connector to
I/O module.
7 Packet leaves via egress port.

CT3 SRP CT3

Line SRP Line

Figure 2-2 Data Flow through the ERX System Hardware

System Design The ERX system’s innovative design provides a fast path for IP traffic
by taking the route processor out of the forwarding path and
maintaining an entire routing table on each port. The route processor
on the switch route processor (SRP) module uses a private multicast
channel through the switch fabric to update route tables on forwarding
engines and issues updates only when changes occur. For every packet,
the system uses its powerful hardware to perform a full table search at
wire speed. This design allows the system to avoid the nondeterministic
performance of cache-based searches and the associated uncertainty in
packet latency.
The ERX system design also supports wire-speed quality of service
(QoS) handling; consequently, the system can examine, classify, and
queue packets at wire speed. A scheduling function then regulates the
packet flows onto the egress link based on the QoS policy assigned to
2-4 CHAPTER 2
Hardware Overview

each flow. All QoS policies for all flows are centrally configured and
then downloaded for execution to each line module. Because all QoS
handling is distributed to the line modules, processing speed is
maintained even when you add extra line modules. Regardless of the
number of QoS policies or the volume of traffic, the system offers
consistently high performance.

Unisphere’s The ERX system makes use of application specific integrated circuits
ASIC (ASICs) in order to speed IP packet processing. Unisphere’s custom
Technology ASICs help meet the forwarding demands of the Internet edge.
Older-generation routers cannot cope with the processor demands of
QoS functions, such as classification, queuing, and scheduling while
routing packets at wire speed. The ERX system overcomes these
limitations with its hardware-assisted architecture.
The system’s use of ASICs provides significant benefits to the service
provider. ASICs help to
• Reduce product size
• Reduce product cost, especially packet per second cost
• Increase packet-processing speeds dramatically by applying targeted
power to hard-wired tasks

ASIC Chip Sets

The ERX system uses two separate ASICs: an ingress forwarding ASIC
and an egress forwarding ASIC. These chip sets are deployed as a pair
on each ERX line module. The generic network interface design
allows the same chips to be used on all line modules.
Each chip has approximately 1,000,000 gates. A number of FPGAs
(Field Programmable Gate Arrays) are also used on each line module to
add incremental processing assistance. The line modules also use a
number of reduced instruction set computing (RISC) processors to
maintain software flexibility. This hardware-intensive distributed
architecture distributes packet processing to the line modules to achieve
maximum wire-speed throughput on all line interfaces while
maintaining a highly scalable and flexible architecture.
 Hardware Design Overview 2-5
ERX Edge Routers

RISC + ASIC Architecture

The ERX system uses a RISC + ASIC architecture that provides both
high-performance packet management and the flexibility to support
changes in standards and specialized customer enhancements. The
ASIC technology supports wire-speed forwarding of packets on all
system interfaces by hard-wiring standard routing functions. The RISC
technology provides flexibility, since it can be easily upgraded to handle
software enhancements. The combination of the technologies is a
powerful and key architectural necessity for high-performance edge
routing switches, overcoming the disadvantages of all-ASIC (no
flexibility) or all-RISC (too slow) approaches.

Hardware As a next-generation edge product, the ERX system uses hardware

Assist Features assistance to maintain wire-speed processing at high bandwidth rates,
while supporting the processing-intensive IP service functions that have
become a service provider necessity.
The system implements hardware assistance for the following functions:
• Basic router functions – frame cracking, address lookup
• Classification – mapping the IP header to the classification filters
• Rate measurement – packet monitoring and shaping via token
buckets
• Buffer management – allocation of frames to buffers and clearing of
buffers after packet transport. The system manages buffers from a
dynamic pool in contrast to older routers that rely on fixed buffer
assignments. This architecture allows faster processing and more
flexible distribution of buffer resources per line module.
• Queue management – pointer management
• Scheduling management – scheduling the packets on the output
links in relation to their QoS service plans
• Statistics support – incrementing counters in response to packet
information
To speed packet processing and reduce packet latency, these functions
run in parallel in the system.
2-6 CHAPTER 2
Hardware Overview

Redundancy Both the ERX-700 and the ERX-1400 systems have a passive
Features midplane design. Line modules that contain active components plug
into the front of the chassis. I/O modules that contain the I/O ports
have mostly passive components and plug into the rear of the chassis.
This design provides redundancy by allowing multiple line modules to
share cables. If a line module goes down, the redundant line module
uses the same cables, requiring no manual intervention or cable
swapping from an on-site technician.

1:1 Redundancy
The SRP module uses a 1:1 redundancy scheme. When two SRPs are
installed in the ERX system, one acts as a primary and the second as a
standby. Both SRP modules share a single SRP I/O module located on
the rear of the chassis. If the primary SRP fails, the secondary SRP
assumes control.

1:N Redundancy
Most line modules support a 1:N redundancy scheme. In this process,
an extra line module in a group of identical modules provides
redundancy for all those modules. This level of redundancy is critically
important because thousands of subscribers connect via single
channelized interfaces, and because it is increasingly common for
facilities to operate in lights-out mode with no personnel on site to
swap cables.
To use this feature, you must install
• A spare line module in the lowest slot of the redundancy group
• A redundancy midplane that covers the slots in the redundancy
group
• A redundancy I/O module in the lowest slot of the redundancy
group
The special midplane can cover from two to six slots. It provides
additional connectivity that enables the spare line module to assume
control of the I/O module associated with any failed line module in the
redundancy group. The spare I/O module provides connectivity from
the spare line module to the redundancy midplane.
The process by which the ERX system switches to the spare line
module is called switchover. When switchover occurs, the system breaks
the connection between the primary I/O module and the primary line
module. Next, the system connects the primary I/O module to the
 ERX System Chassis 2-7
ERX Edge Routers

spare line module via the redundancy midplane and redundancy I/O
module. Protocol processing then takes place on the spare line module.

Port Redundancy
The channelized OC12/STM-4 module optionally supports 1+1
SONET APS redundancy. This feature meets the NEBS
GR-253-CORE specification.
With this type of redundancy, there are two fiber ports on the I/O
module. Both ports receive the same SONET packets. The ERX
system examines the SONET packets to determine whether or not
there is a problem with the optical connection to either port. Based on
this information, the system chooses which port is active and which
port is redundant. If there is a problem with the connection to the
active port, the system switches data transfer to the redundant port.
The GE I/O module uses a similar scheme with its two ports; one
active Gigabit Ethernet connection is supported at a time. In the event
of a cut or loss of the fiber cable connected to the primary port, the
redundant port becomes active.

ERX System Chassis

Both ERX models use the same SRP modules, line modules, and I/O
modules. This design enables service providers to maintain their
investment in modules if they upgrade from the ERX-700 to the
ERX-1400. In addition, if they own both ERX models, customers can
minimize inventories of spare modules.
The midplane is built with passive components and merely handles the
clock, control, and management traffic for the module-to-module
communication, and the passing of subscriber data between modules.
Table 2-1 shows ERX system chassis features.

Table 2-1 ERX System Chassis Features

Chassis Specifications ERX-700 ERX-1400

Total number of slots 7 14
Slots reserved for SRP 2 2
module
Slots available for line 5 12
module–I/O module pairs
2-8 CHAPTER 2
Hardware Overview

Table 2-1 ERX System Chassis Features (continued)

Chassis Specifications ERX-700 ERX-1400

Dimensions 10.5 (H) x 19 (W) x 16 (D) 22.75 (H) x 19 (W) x 16 (D)
inches inches
(26.67 x 48.26 x 40.64 cm) (57.78 x 48.26 x 40.64 cm)
Weight • Chassis only: • Chassis only:
22 lb (9.9 kg) 42 lb (18.9 kg)
• Chassis fully • Chassis fully
configured: 46 lb (20.7 configured: 88 lb (39.6
kg) kg)

Power System
Both the ERX-700 and ERX-1400 are designed for DC power input.
Unisphere’s unique distributed power architecture distributes redundant
–48VDC feeds through the system to each line module, SRP module,
and fan assembly. Conversion of the required secondary voltages takes
place at the line module. This system design allows the addition of
faster and more powerful line modules, without the power restrictions
of a centralized architecture. If a power component fails, the design
ensures that other components will not be affected.
The ERX system offers extremely low power consumption (less than
25 Amps at –48VDC) and a correspondingly low heat dissipation (less
than 1,250 W for a fully populated system). The system’s efficient
electrical design minimizes the overall power needs in a POP, and
satisfies stringent co-location power restrictions.
If AC power is desired, a DC to AC power converter is available as part
of the system.

Fans/Air Flow
The system uses a single fan tray assembly with six fans mounted on the
tray in the ERX-1400 and four fans in the ERX-700. This assembly
provides power- and status-sensing capability. The fan tray consists of
two redundant converters that power the fans. If one converter fails, the
other takes over. In addition, the system software reports an alarm if any
of the fans overrotate or underrotate or if one of the converters fails.
Airflow in the chassis varies according to the model. The ERX-1400
uses an innovative front-to-back and bottom-to-top air flow design to
keep the unit cool even when it is mounted in a rack with multiple
 System Modules 2-9
ERX Edge Routers

other devices. In the ERX-1400, the fans are located at the top of the
chassis. The ERX-700 has a conventional air flow, from right-to-left;
fans are located on the left side of the chassis.

System Modules
You can use several different line modules and I/O modules in both the
ERX-700 and ERX-1400 systems. A few architectural characteristics
are common to certain types of modules:
• The presence of an EEPROM on each module to identify the
module and its manufacturing date.
• The location of nonvolatile storage on each line and SRP module to
store its own boot image and run-time code.
• A hardware-based lookup, forwarding component, and dedicated
RISC processor on each line module. This distributed processing
power guarantees wire-speed classification and forwarding of
40-byte packets, even when the system is fully loaded.

SRP Modules An ERX system must contain at least one SRP module and its
associated SRP I/O module. See Figure 2-3. You must insert the SRP
module into the slots reserved for this purpose. In the 14-slot chassis,
the two center slots are reserved for SRP modules; in the 7-slot chassis,
the two bottom slots are reserved. You can install another SRP module
in the second slot to provide redundancy. See Redundancy Features
earlier in this chapter.
2-10 CHAPTER 2
Hardware Overview

midplane
connectors
fabric board

ejector

functional
status LEDs

redundancy
status LEDs

PCMCIA
Flash card
system processor
ejector

Figure 2-3 SRP and SRP I/O Modules

The SRP and SRP I/O functions include:

• Configuration and operation of the 5-, 10-, or 40-Gbps switch
fabric and management of the unit interprocessor communication
and system control bus master
• Initial system boot, system initialization, and monitoring of fans,
power supply, and temperature sensors
• Storage of system software image and system configuration in Type
II PCMCIA NVS card and download of executable and images to
the line modules
• Clocking functions, including real-time clock with battery backup,
and clock distribution to line modules
• Redundancy control for switch fabric/route server, timing
subsystem, and line modules through keepalive messages
• Maintenance of the master route table and link state information via
a dedicated RISC processor, and distribution of the route tables to
the line modules
• Diagnostic user interface, system alarm contacts
• Watchdog timer for internal management
 System Modules 2-11
ERX Edge Routers

• System console ports for management access

• Command line interface support
As shown in Figure 2-3, the SRP module comprises two boards:
• Fabric board – 5-, 10-, or 40-Gbps switch fabric
• Processor board – dedicated processor boots the system, manages
diagnostics, and supports route protocol processing
The SRP module specifications are provided in Table 2-2.

Table 2-2 SRP Module and SRP I/O Module Specifications

Feature Specification
Management ports • One RJ45 10/100 Base-T Ethernet management port
• One DB9 RS232 connector for system management
Alarm ports • One terminal block for external alarm contacts
Clock ports • Two 3-pin wire-wrap posts for US external clock
sources
• Two BNC connectors for E1 clock sources
• Two connectors support primary and secondary clock
sources
Line module front panel • Indicates board, power, fan, link, and redundancy
status
• PCMCIA slot access
Processor support • PowerPC 750 with 1 MB level 2 cache
Switch fabric • 5-, 10-, or 40-Gbps switch fabric
Memory support • Four banks of SDRAM; max of 128 MB each
• Upgradable PCMCIA Type II NVS; 220 MB card
provided, 440 MB card available

Switching Fabric Functions

The ERX system uses a high-performance, 5, 10, or 40 Gbps,
packet-aware switching fabric to connect all internal data paths. The
fabric handles per flow queuing for large numbers of packet flows.
The fabric’s functions include buffer management, queuing,
scheduling, and packet discard. The fabric manages the internal
connections between ingress and egress ports and can support
point-to-point and multicast connections.
Fabric features include:
• 5-, 10- or 40-Gbps performance – supports wire-speed throughput
for fully loaded configurations
2-12 CHAPTER 2
Hardware Overview

• Per flow queuing – each queue can be assigned QoS parameters and
is independently managed and scheduled, so that if congestion
conditions occur on one queue, it does not affect other queues. This
allows for fairness in QoS policy management and control.
• Dedicated CPU – provides management and control to ensure fast
response times to management requests
• Early packet discard (EPD) support – reduces retransmissions by
ensuring that only complete packets are sent
The fabric also distributes operational software images and route table
updates to the line modules.

System Start-Up
When the system is powered on, the SRP executes boot code from
NVS. The SRP module downloads a software image from NVS into
SDRAM, then executes code from SDRAM. Once it is initialized, the
SRP module downloads an executable image to each line module in
the chassis.
When each line module is active, the SRP module communicates with
the line modules through a dedicated, in-band, 150-Mbps Utopia bus
connection through the switch fabric.

Line Modules A range of line modules is available for the ERX system. See Table 2-3.
You can use any line module for access or uplink. Commonly, access line
modules receive traffic from low-speed circuits, and the system routes
the traffic onto higher-speed uplink line modules and then to the core
of the Internet. TSMs, which enable the ERX system to support
tunnels, are also available.

Table 2-3 Line Modules for ERX Systems

Name Description
E1/CT1 Modules
CE1-FULL 20-port channelized E1 for Frame, PPP, HDLC
CT1-FULL 24-port channelized T1 for Frame, PPP, HDLC
E3/T3 Modules
E3-3A 3-port unchannelized E3 for ATM
E3-3F 3-port unchannelized E3 for Frame, PPP, HDLC
E3-12-FO 12-port unchannelized E3 for Frame, PPP, HDLC
T3-3A 3-port unchannelized T3 for ATM
 System Modules 2-13
ERX Edge Routers

Table 2-3 Line Modules for ERX Systems (continued)

Name Description
T3-3F 3-port unchannelized T3 for Frame Relay, PPP, HDLC
T3-12-FO 12-port unchannelized T3 for Frame Relay, PPP, HDLC
CT3-3 3-port channelized T3 for Frame Relay, PPP, HDLC
CT3/T3-FO 12-port channelized T3 for Frame Relay, PPP, HDLC
OC3/STM-1 Modules
OC3/STM1 ATM 4-port unchannelized, concatenated OC3/STM-1 for ATM
OC3/STM1 POS 4-port unchannelized, concatenated OC3/STM-1 for POS
cOC3/STM1-T3/E3 4-port OC3/STM-1 channelized to T3/E3 for Frame Relay, PPP, HDLC
cOC3/STM1-FO 4-port OC3/STM-1 channelized to DS0 for Frame Relay, PPP, HDLC
OC12/STM-4 Modules
OC12/STM4 ATM 1-port unchannelized, concatenated OC12/STM-1 for ATM
OC12/STM4 POS 1-port unchannelized, concatenated OC12/STM-1 for Frame Relay
cOC12/STM4-FRAME 1-port OC12/STM-4 channelized to HDLC
cOC12/STM4-T3/E3 1-port OC12/STM-4 channelized to T3/E3 for Frame Relay, PPP, HDLC
cOC12/STM4-FO 1-port OC12/STM-4 channelized to DS0 for Frame Relay, PPP, HDLC
Ethernet Modules
10/100 FE-2 2-port Fast Ethernet
FE-8 8-port Fast Ethernet
GE 1-port Gigabit Ethernet
HSSI Module
HSSI-3 3-port high-speed serial Interface
Tunnel Service Line Modules
(TSMs)
TUNNEL-SERVICE Supports static and dynamic tunnels for protocols such as DVMRP, GRE, and
LNS termination for L2TP
IPSec TSM Tunnel service module that encrypts packets encoded with IPSec
X.21/V.35 Module
ERX-X21-V35-MOD 16-port X.21/V.35 interface
2-14 CHAPTER 2
Hardware Overview

The following tables provide specifications for each line module.

Table 2-4 Specifications for Channelized E1 and T1 Modules

Feature CE1-FULL CT1-FULL

Number of ports 20 24
Connector type RJ-48C (100 Ohm) or BNC RJ-48C (100 Ohm)
(75 ohm) via a Balun panel
Capability E1, DS0 T1, J1
HDLC Framing DS0
HDLC Framing
Performance Line rate forwarding with Line rate forwarding with
40-byte packets 40-byte packets
E1s/T1s per board 20 24
56/64K channels per board 620 576
FE1s/FT1s per board 620 576
56/64K channels per port 31 24
FE1s/FT1s per port 31 24
Redundancy support 1:N redundancy 1:N redundancy

Table 2-5 Specifications for Unchannelized E3 Modules

Feature E3-3A E3-3F E3-12-FO

Number of ports 3 3 12
Connector type BNC, 75 ohm BNC, 75 ohm BNC, 75 ohm
Capability ATM: AAL5 E3 E3
HDLC Framing HDLC Framing
Performance Line rate forwarding Line rate forwarding Line rate forwarding
with 40-byte packets with 40-byte packets with 40-byte packets
Redundancy 1:N redundancy 1:N redundancy 1:N redundancy
support

Table 2-6 Specifications for Unchannelized T3 Modules

Feature T3-3A T3-3F T3-12-FO

Number of ports 3 3 12
Connector type BNC, 75 ohm BNC, 75 ohm BNC, 75 ohm
Capability ATM: AAL5 DS3, subrate DS3 DS3, subrate DS3
HDLC Framing HDLC Framing
Performance Line rate forwarding Line rate forwarding Line rate forwarding
with 40-byte packets with 40-byte packets with 40-byte packets
 System Modules 2-15
ERX Edge Routers

Table 2-6 Specifications for Unchannelized T3 Modules (continued)

Feature T3-3A T3-3F T3-12-FO

Redundancy 1:N redundancy 1:N redundancy 1:N redundancy
support

Table 2-7 Specifications for Channelized T3 Modules

Feature CT3-3 CT3/T3 FO

Number of ports 3 12
Connector type BNC, 75 ohm SMB
Capability DS3, DS1, DS0 DS3, DS1, DS0
HDLC framing HDLC framing
Performance Line rate forwarding with Line rate forwarding with
40-byte packets 40-byte packets
T3s per board 3 12
T1s per board 84 336
DS0s per board 384 2,000
Redundancy support 1:N redundancy 1:N redundancy

Table 2-8 Specifications for Unchannelized OC3/STM-1 Modules

Feature OC3/STM1 ATM OC3/STM1 POS

Number of ports 4 4
Connector type Multi-mode or single-mode Multi-mode or single-mode
fiber transceiver fiber transceiver
Modes and ranges • Multimode • Multimode
• Single mode, • Single mode,
intermediate reach intermediate reach
• Single mode, long reach • Single mode, long reach
Capability OC3c/STM-1 OC3/STM-1
ATM/AAL5 HDLC Framing
Performance Wire-speed throughput at Wire-speed throughput at
40-byte packet size 40-byte packet size
Redundancy support 1:N redundancy 1:N redundancy

Table 2-9 Specifications for Channelized OC3/STM-1 Modules

Feature cOC3/STM4 T3E3 cOC3/STM4-FO

Number of ports 4 4
Connector type Multimode or single-mode Multimode or single-mode
fiber transceiver fiber transceiver
2-16 CHAPTER 2
Hardware Overview

Table 2-9 Specifications for Channelized OC3/STM-1 Modules (continued)

Feature cOC3/STM4 T3E3 cOC3/STM4-FO

Modes and ranges • Multimode • Multimode
• Single mode, • Single mode,
intermediate reach intermediate reach
• Single mode, long reach
Capability OC3/STM-1, T3, E3 OC3/STM-1, T3, T1, E1,
DS0
Performance Wire-speed throughput at Wire-speed throughput at
40-byte packet size 40-byte packet size
T3s per board 12 12
E3s per board 12 0
T1s per board 0 336
E1s per board 0 252
DS0s per board 0 2000
Fractional DSU/CSU Yes No
Redundancy support 1:N redundancy 1:N redundancy

Table 2-10 Specification for Unchannelized OC12/STM4 Modules

Feature OC12/STM4 ATM OC12/STM4 POS

Number of ports 1 active, 1 redundant 1 active, 1 redundant
Connector type Multimode or single-mode Multimode or single-mode
fiber transceiver fiber transceiver
Modes and ranges • Multimode • Multimode
• Single mode, • Single mode,
intermediate reach intermediate reach
• Single mode, long reach • Single mode, long reach
Capability OC12c/STM-4 OC12c/STM-4
ATM:AAL5 HDLC framing
Performance Wire-speed throughput at Wire-speed throughput at
40-byte packet size 40-byte packet size
Redundancy support 1:N redundancy 1:N redundancy
 System Modules 2-17
ERX Edge Routers

Table 2-11 Specifications for Channelized OC12/STM4 Modules

Feature cOC12/STM4-FRAME cOC12/STM4-T3/E3 cOC12/STM4-FO

Number of ports 1 active, 1 redundant 1 active, 1 redundant 1 active, 1 redundant
Connector type Multimode or single-mode Multimode or single-mode fiber Multimode or single-mode
fiber transceiver transceiver fiber transceiver
Capability OC12c/STM-4 OC12/STM-4 OC12/STM-4
HDLC framing T3, E3 T3
HDLC framing T1, E1
DS0
HDLC framing
Modes and ranges • Multimode • Multimode • Multimode
• Single mode, • Single mode, intermediate • Single mode, intermediate
intermediate reach reach reach
• Single mode, long reach • Single mode, long reach • Single mode, long reach
Performance Wire-speed throughput at Wire-speed throughput at Wire-speed throughput at
40-byte packet size 40-byte packet size 40-byte packet size
T3s per board 0 12 12
E3s per board 0 12 0
T1s per board 0 0 336
E1s per board 0 0 252
DS0s per board 0 0 2,000
OC3s per board 4 0 0
Fractional No Yes No
DSU/CSU
Redundancy 1:N redundancy 1:N redundancy 1:N redundancy
support 1+1 SONET APS redundancy 1+1 SONET APS redundancy

Table 2-12 Specifications for Ethernet Modules

Feature 10/100 FE-2 FE-8 GE

Number of ports 2 8 1 active, 1 redundant
Connector type RJ-45 RJ-45 SC full duplex (singlemode)
Capability Ethernet (IEEE 802.3) Ethernet (IEEE 802.3) Ethernet (IEEE 802.3z)
10/100Base-T 10/100Base-T 1000 Base-LX
1000 Base-SX
Performance Wire-speed throughput at Wire-speed throughput at Wire-speed throughput at
64-byte packet size 64-byte packet size 64 byte packet size

Note: 64 bytes is the minimum size for an Ethernet packet.

Redundancy support N/A N/A Redundant port
2-18 CHAPTER 2
Hardware Overview

Table 2-13 Specification for HSSI Module

Feature HSSI-3
Number of ports 3
Connector type Standard HSSI connector: 2 row, 50 pin,
receptacle header with rails and latch blocks
Capability Up to 44.736 MHz data rate
DCE or DTE operation
HDLC
Performance Wire-speed throughput at 40-byte packet size

Table 2-14 Specification for X.21/V.35 Module

Feature ERX-X21-V35-MOD
Number of ports 16
Connector type 200-pin proprietary socket on I/O module
DB15 X.21 or DB34 V.35 at remote end
Capability Up to 10 Mbps data rate per port
Up to 50 Mbps data rate across all ports
DCE and DTE operation
HDLC
Frame Relay
PPP
Performance Wire-speed throughput at 40-byte packet size
Redundancy 1:N Support

TSMs
Unlike other line modules, TSMs do not pair with an I/O module that
contains ingress and egress ports. When the system receives a packet
that requires processing on a tunnel server module, the system forwards
the packet via the switch fabric to the tunnel server module. The
tunnel server module processes the packet and returns it to the switch
fabric. Finally, the processed packet leaves the system via an egress
module.
Two TSMs are available: the tunnel service module and the IPSec TSM
module. The tunnel service module supports IP tunnels, such as
DVMRP and GRE tunnels, and LNS termination for L2TP. The IPSec
TSM module decrypts packets encoded with the IPSec protocol.
 System Modules 2-19
ERX Edge Routers

Table 2-15 TSMs

Feature Tunnel Server IPSec TSM

Performance Wire-speed throughput at Wire-speed throughput at
40-byte packet size 40-byte packet size
(half-duplex) (half-duplex)
Redundancy Multiple cards provide Multiple cards provide
redundancy redundancy

Ranges for Line Modules

The range of a line module depends on the type of module and the
mode of the I/O module. Table 2-16 shows the range for the modules.

Table 2-16 Modes/Ranges for OCx/STMx and cOCx/STMx I/O Modules

Module Mode Range

CE1-FULL N/A • The transmitted signal complies
with ITU-T G.703 for cable
lengths up to 450 m (492 yards).
CT1-FULL N/A • The line interface unit supports
multiple line build outs.
• The signal strength is software
controlled.
• The transmitted signal complies
with ANSI T1.102 for cable
lengths up to 201 m (660 feet).
CT3-3 N/A • The line interface unit supports
two line build outs:
› 0–68.5 m (0–225 feet)
› 69 –137 m (226–450 feet)
• The signal strength is software
controlled.
• The transmitted signal complies
with ANSI T1.102 for cable
lengths up to 201 m (660 feet).
• E3-3A N/A • The transmitted signal complies
• E3-3F with ITU-T G.703 for cable
lengths from 0–137 m (0–450
feet).
2-20 CHAPTER 2
Hardware Overview

Table 2-16 Modes/Ranges for OCx/STMx and cOCx/STMx I/O Modules (continued)

Module Mode Range

• T3-3A N/A • The line interface unit supports
• T3-3F two line build outs:
› 0–68.5 m (0–225 feet)
› 69–137 m (226–450 feet)
• The signal strength is software
controlled.
• The transmitted signal complies
with ANSI T1.102 for cable
lengths up to 201 m (660 feet).
• FE-2 N/A • For 10 Mbps operation, use CAT
• FE-8 3, 4, or 5 UTP cable.
• For 100 Mbps operation, use only
CAT 5 UTP cable.
• The transmitted signal complies
with IEEE 802.3/802.3u for cable
lengths up to 100 m (328 feet).
GE N/A • Tx Power
› min: -9.5 dBm
› max: -4 dBm
• Center Wavelength: 850 nm
• Rx input power
› min: -17 dBm
› max: -3 dBm
• Rated for 275 m (300 yards) over
62.5 micron core cable
• Rated for 550 m (601 yards) over
50 micron core cable
• cOC3/STM1 Multimode • Tx power:
• cOC12/STM4 › min: -19 dBm
• cOC12/STM4 › max: -14 dBm
• OC12/STM • Center wavelength: 1310 nm
• Rx input power:
› min: -30 dBm
› max: -14 dBm
• Rated for 2 km (1.2 miles) over
62.5 micron core cable with an
optical loss of 0–9 dB or
50 micron core cable with an
optical loss of 7 dB
 System Modules 2-21
ERX Edge Routers

Table 2-16 Modes/Ranges for OCx/STMx and cOCx/STMx I/O Modules (continued)

Module Mode Range

• cOC3/STM1 Single Mode • Tx power:
• cOC12/STM4 Intermediate Reach › min: -15 dBm
• cOC12/STM4 › max: -8 dBm
• OC12/STM • Center wavelength: 1310 nm
• Rx input power:
› min: -31 dBm
› max: -8 dBm
• Rated for 15 km (9.3 miles) of
9 micron core cable
• cOC3/STM1 Single Mode • Tx Power:
• cOC12/STM4 Long Reach › min: -5.0 dBm
• cOC12/STM4 › max: 0 dBm
• OC12/STM • Center wavelength: 1310 nm
• Rx Input Power:
› min: -34 dBm
› max: -7 dBm
• Fiber type: 9 micron core
• Rated for 50 km (31.1 miles) of
9 micron core cable

Future Modules
Unisphere will continue to develop new modules for the ERX system
to increase density and functionality. Additional modules will be
developed in response to customer demand as network bandwidth
needs increase or as interface requirements change.
2-22 CHAPTER 2
Hardware Overview
Software Overview

This chapter describes all the software components of the ERX system.
It includes a general overview of the software architecture and
information on software traffic flow, access protocols, routing protocols,
and the QoS mechanisms.

Topic Page
Architecture Overview 3-2
Software Summary 3-3
ERX Software Traffic Flow 3-5
IP 3-9
DS3/DS1/E3/E1 3-22
SONET 3-24
Switched Multimegabit Data Service (SMDS) 3-26
Routing 3-28
IP QoS 3-44
Policy Management 3-54
Dynamic Interfaces 3-57
B-RAS Support 3-59
Non-PPP Equal Access Support 3-64
L2TP Support 3-67
L2F Support 3-68
VLAN Support 3-69
3-2 CHAPTER 3
Software Overview

Architecture Overview
As network transport becomes more and more critical to daily business
operations, service providers need to deploy products that can
guarantee maximum uptime. In the ERX system, both the hardware
and the software are designed to be extremely robust. The system
combines a redundant carrier-class hardware design with a software
architecture that is modular, object oriented, and component based.
This software modularity increases overall system reliability, eases
software upgrades, and reduces development time to speed new feature
release by making each software component highly autonomous.
Each major software subsystem within the system (such as BGP-4, IP,
SNMP, Frame Relay, SONET) is independent and has a set of
dedicated resources, such as memory, buffers, and processing cycles.
This allows each subsystem to minimize unwanted interactions with
other subsystems and thus to minimize negative overall system impact.
Since each subsystem has dedicated system resources, no one subsystem
can consume an unfair share of memory, buffers, or processing cycles.
In addition, software subsystems can be independently loaded, shut
down, and restarted. All actions are dynamic; the loading of one
module does not affect the performance or operation of another.
The modularity of the system architecture is in direct contrast to older,
monolithic, code-based designs. The modular approach improves
stability and reliability by ensuring that the behavior of one program
module does not adversely affect others. The system modularity
provides several advantages:
• Seamless recovery – Individual software subsystems can be restarted
without affecting the rest of the system’s operation.
• Increased system uptime – Each software module interacts with the
other software modules through a defined set of interfaces,
protecting subsystem interactions.
• Predictable software behavior – System resources are protected so
that even if a software subsystem has a problem, overall system
operation will be minimally affected.
• Nondisruptive software upgrades – Individual modules can be
upgraded without affecting overall system operation.
The ERX system also implements a distributed software architecture,
where each line module is capable of making routing, QoS, and
forwarding decisions. This distribution of software functions makes the
 Software Summary 3-3
ERX Edge Routers

system highly scalable. As more line modules are added to the system,
more packet processing capability is added.
The SRP module is responsible for downloading software images to
each of the line modules on system boot. In addition, the SRP is also
responsible for sending down routing table updates (see Routing, later in
this chapter). The distributed software processing allows for maximum
system performance even when the chassis is fully loaded.

Software Summary
IP has emerged as the dominant traffic type for wide area transport.
With this in mind, the ERX system has an IP-optimized software set
designed to meet the demanding needs of the service provider edge.
The ERX software set combines robust, IP routing protocol support
with next-generation IP features such as QoS, virtual private networks
(VPNs), multiple virtual routers, and detailed accounting. This software
set is backed by the wire-speed performance of the ERX hardware.
The comprehensive software set allows service providers to deploy the
system to fulfill immediate subscriber demand for high-speed Internet
access, while also enabling them to develop new, high-value IP service
plans.

Software The system supports the following software features, each of which is
Features described in more detail in the following sections:
• Robust IP protocol
• Routing protocols: BGP-4, IS-IS, OSPF, RIPv2
• PPP (including Packet over SONET), Multilink PPP, Frame Relay,
Multilink Frame Relay, and ATM
• SONET, DS3, DS1, Fractional DS1, E3, E1, Fractional E1
• MPLS (including RSVP and CR-LDP)
• Multicasting protocols: DVMRP, IGMP, MBGP, PIM
• VPNs
• Virtual routers
• IP QoS
• Policy management
• Dynamic interfaces
• Broadband RAS features: PPP, PAP, CHAP, RADIUS, DHCP
3-4 CHAPTER 3
Software Overview

• Comprehensive network management (covered in Chapter 4)

• Complete statistics gathering per interface (covered in Chapter 5)
• Strong diagnostics (covered in Chapter 5)

Routing Protocols BGP4 OSPF IS-IS RIP MPLS

Layer 4: Transport Protocol

TCP UDP

Layer 3: Network Layer

IP

Layer 2: Data Link Layer Frame

PPP PPPoE ATM L2TP
Relay

Layer 1: Physical Layer DSx/Ex Ethernet SONET

FDS1/FE1 100 BASE-T OC-3/STM-1
DS1/E1 Gigabit Ethernet OC12-STM-4
DS3/E3

Figure 3-1 ERX System Software Overview

Figure 3-1 shows the breadth of the ERX system software support.
Software functions are layered on top of physical (copper or optical)
interfaces. Multiple access protocols (PPP, FR, ATM) are supported to
allow service providers to offer a number of access methods and line
speeds to their subscribers. The system is optimized to handle IP
connections no matter what the access protocol.
The system also supports a number of protocols that are specific to the
B-RAS application. These are shown in Figure 3-31, and include:
• IP/PPP/ATM
• IP/PPP/Ethernet/ATM
• IP/PPP/FR
• IP/PPP/Ethernet/FR
For routing, all major IP-based routing protocols are supported. They
give the service provider flexibility in deploying routing protocols. This
allows service providers to use protocols such as IS-IS or OSPF for
 ERX Software Traffic Flow 3-5
ERX Edge Routers

internal network connections and BGP-4 for external connections.

The ERX system supports both interior routing protocols (such as RIP,
OSPF, IS-IS) as well as exterior ones (such as BGP-4). Both types of
routing protocols are required for large-scale service provider network
deployment.
The ERX system also supports the complete suite of multicast routing
protocols. IP multicasting improves network efficiency by allowing a
host to transmit a datagram to a targeted group of receivers.
In addition to all the protocols listed above, the system supports a
leading-edge set of next-generation IP features to allow service
providers to implement new IP services. These features include support
for IP QoS, IP VPN services, detailed accounting, virtual routing, and
IP service plan creation and enforcement.

ERX Software Traffic Flow

This section describes the software events that occur as traffic is
processed by the system.
At a high level, packets are received by an ERX line module interface.
Any number of interfaces can be receiving packets simultaneously. The
packets are then processed by each line module. Various QoS or routing
policies can be applied to make the packet conform to the subscriber’s
service plan. The packets are then routed out of an ERX interface.
Packet policies can be created and enforced for packets initiated by the
subscriber as well as packets destined for the subscriber. This feature is
important because it ensures that traffic entering into the network, as
well as traffic returning from the network, is in compliance with the
subscriber’s service plan. It also allows for different policies for CPE
outgoing traffic versus CPE incoming traffic.
The ability to set up different policies per traffic direction also prevents
misuse of system resources. For example, if traffic from the network is
blasting to a specific subscriber destination in excess of its service plan,
ERX system resources could be improperly consumed. The system has
the intelligence to ensure that the traffic remains balanced for both
ingress and egress in accordance with the subscriber’s service plan.
3-6 CHAPTER 3
Software Overview

Figure 3-2 illustrates the flow of traffic in the system.

1 4 5

SRP
CT3 OC3

Ingress Line Module SRP Module Egress Line Module

1 Packets are received by a line module.
2 Packets are classified based on ingress
interface, MPLS label, or any field in
the packet, and a lookup is performed.
Classification could include Gold, Silver,
and Bronze traffic queues.
3 Actions are performed on the packet
as a result of classification.
4 Packet is forwarded to the egress destination via IP
forwarding function. Packets could be forwarded into a
specific traffic queue (such as Gold, Silver, or Bronze).
5 Line module handles packet scheduling, Layer 2
encapsulation, and transmission of the packet on the
egress network. Weighted-based scheduling could provide
relative priority between queues (such as Gold, Silver,
or Bronze).

Figure 3-2 Packet Processing in the ERX system

Packet The following steps describe how the ERX system processes packets:
Processing
1 Packets are received by a line module.
Any line module in the ERX chassis can act as the access line module.
For a list of available line modules, see Chapter 2, Hardware Overview. As
the packet is received on the line module, the layer 2 header is removed
from the IP packet.
2 The packet is classified and a lookup is performed. The result of the
classification and lookup is an internal egress destination address.
 ERX Software Traffic Flow 3-7
ERX Edge Routers

The packet can be classified in a number of ways:

• Layer 2 – classifies the packet based on the ingress interface. This
allows the service provider to define subscriber-specific policies,
such as map all traffic from port X or virtual circuit Y to the “Gold”
service.
• Layer 2+ – classifies the packet based on the MPLS label. This
allows the service provider to use MPLS labels to assign traffic paths.
• Layer 3 – classifies the packet based on any field in the packet,
including source IP address, destination IP address, DiffServ (DS)
field, and application type and port number. This gives the service
provider more fine-grained control over service definition. For
example, “map all traffic that is VoIP for low latency handling,” or
“map all traffic received from this subscriber source address to a
best-effort service.”
Once the packet is classified, the lookup function finds the internal
egress destination address for the packet and tags the packet with the
internal route address. The packet is placed in a service queue based on
its classification.
3 A number of actions can be performed on the packet as a result of its
classification, including:
• Permit or deny forwarding based on the subscriber’s service profile.
For example, if a subscriber is restricted from targeting a specific
destination address, drop all packets.
• Target the internal route path to assign the packet to a certain level
of treatment. For example, forward the packet into a specific service
queue (such as Gold, Silver, or Bronze).
• Give a service queue a scheduling weight or a fixed amount of
bandwidth.
• Police the packets to a specified level. Up to two thresholds can be
set. This allows packets to be set as committed (green), conforming
(yellow), or excess (red).
• Mark the packet with a label to indicate treatment by the rest of the
network. Marks could include MPLS labels, DS byte, or Discard
Eligible (DE) bits. For example, either identify all VoIP traffic as
high priority by appending an MPLS label that designates a priority
handling, or, if a subscriber’s traffic is bursting out of his or her
traffic profile, mark the packet as DE so that these packets can be
dropped if congestion occurs.
3-8 CHAPTER 3
Software Overview

• Apply a suite of VPN services. Depending on the service provider

demand, these services could include ATM PVC mapping, routing
policy assignment, virtual router creation and VPN inclusion. For
example, map traffic from an incoming subscriber to an ATM PVC
that serves the VPN destination.
• Any combination of the above actions can be used together. For
example, a subscriber could be given Gold service with a
guaranteed bandwidth of 384 Kbps.
Figure 3-3 shows how traffic might be segmented into three traffic
queues based on classification, and it shows the resulting actions.

Packet egress
Classify
Packet ingress
Encapsulate
Apply action
Schedule
Gold •Gold
Forward Silver •Silver
•Bronze
Bronze

Ingress SRP Egress

line module line
module module

Figure 3-3 Segmenting and Processing Traffic

4 The packet is forwarded internally to the egress destination via the IP

forwarding function.
The switch fabric located on the SRP module handles the packet
forwarding to the internal egress port destination.
5 The line module handles packet scheduling, layer 2 encapsulation, and
transmission of the packet onto the egress network.
Any line module in the ERX chassis can route packets to the egress
network. For a list of available line modules, see Chapter 2, Hardware
Overview. The line module handles packet scheduling. The packet
scheduler draws from the packet queues that are targeted at that
interface.
 IP 3-9
ERX Edge Routers

The queues can be emptied according to one of the following criteria:

weight-based priority, rate-based priority, or strict priority. These
criteria can be used independently or combined together and are
configured by the service provider to match the QoS policies.
Weight-based scheduling provides relative priority between queues and
is commonly used for Gold/Silver/Bronze type services. Rate-based
scheduling provides a fixed rate guarantee that might be useful for some
applications. Strict policy-based scheduling provides guarantees for
low-latency applications, like VoIP.
If there is congestion, the packets that have been marked out of profile
can be dropped by the line module.
Once the packet is scheduled, the router on the line module removes
the internal routing tag, encapsulates the packet with a layer 2 header
(ATM, POS, FR, PPP), and transmits the packet to the network. All
traffic flows are handled at wire speed. For more detailed information
on classification, actions, and scheduling, see IP QoS later in this
chapter.

IP
Internet access is now a business necessity for most companies, and IP is
the protocol of the Internet. With this in mind, Unisphere developed a
highly robust software set that is optimized to process IP packets at wire
speed.

IP Features The following IP features are supported:

• Internet Protocol – RFC 791
• Internet Control Message Protocol (ICMP) – RFC 792, including
ICMP error messages (Destination Unreachable, Redirect, Time
Exceeded, and Parameter Problem), as well as ICMP query
messages (Echo, Timestamp, Address Mask, Router Discovery
Protocol) on all connected networks supporting either IP multicast
or IP broadcast addressing
• Internet Group Management Protocol (IGMP) – RFC 1112
• User Datagram Protocol (UDP) – RFC 768
• Transmission Control Protocol (TCP) – RFC 793
• Classless Inter-Domain Routing (CIDR) – 32-bit address (network
and host ID) with support for prefix length indicating the number
of bits in the network prefix
3-10 CHAPTER 3
Software Overview

• Maximum transmission unit (MTU)

• Requirements for IP Version 4 Routers – RFC 1812
• Requirements for Internet hosts—communication layers – RFC
1122
• Broadcasting Internet datagrams – RFC 919
• Broadcasting Internet datagrams in the presence of subnets – RFC
922
• Internet standard subnetting procedure – RFC 950
• Telnet protocol specification – RFC 854
• Reachability commands – traceroute and ping
• Support for simultaneous multiple logical IP stacks on the same
ERX system. Each IP stack operates independently with its own
data structures and is assigned to a set of IP interfaces in the chassis.
This feature enables full support for multiple logically separate
virtual routers.
• Flexible IP address assignment to support any portion of a physical
interface (for example, a channel or circuit), exactly one physical
interface, or multilink PPP interfaces
• IP fragmentation
• Loose source routing to specify the IP route
• Strict source routing to specify the IP route for each hop
• Record route to track the route taken
• Internet timestamp
• Broadcast addressing, both limited broadcast and directed broadcast
• Bridged IP
• Cisco HDLC
• Response Time Reporter (RTR)
• Support for 32,000 discrete, simultaneous IP interfaces per system to
support thousands of logical connections
• Capability of all line modules to detect and report changes in the
state (up or down) of any IP interfaces resulting from changes to the
state of the underlying physical interface.
• Shared IP interfaces over the same layer 2 logical interface enable
more than one IP interface to share the same logical resources
The ERX system implements an IP stack architecture that supports
dynamic configuration to ease network changes with minimal service
disruption. All IP stack configuration information is stored in
 IP 3-11
ERX Edge Routers

nonvolatile storage, and all changes to the stack’s configuration are

dynamic, without requiring the system to be restarted.
An interface table stores information about each interface associated
with an IP stack, including index, IP address, prefix length (subnet
mask), association with lower-layer interfaces, maximum transmission
unit (MTU), state (up or down), and interface state timer. This
interface-dense support allows service providers to deploy the system
for IP session termination applications, such as aggregating the output
from DSLAMs for Broadband RAS (B-RAS) applications.

Profiles You can configure an IP interface dynamically by creating a profile.

This capability allows you to manage a large number of IP interfaces
efficiently by creating a profile with a specific set of characteristics. In
addition, you can create a profile to assign an IP interface to a virtual
router.
A profile can contain one or more of the following characteristics:
• Access routes
• IP address
• Directed broadcast forwarding
• Maximum transmission unit
• Transmission of ICMP redirect messages
• Unnumbered IP address
• Virtual router

RTR The Response Time Reporter (RTR) feature allows you to monitor
your network. It allows you to monitor your network’s performance
and its resources. It does this by measuring response times and the
availability of your network devices.

IP/PPP The ERX system supports IP/PPP on any module that are channelized
to fractional or full T1/E1 or T3/E3, including modules that
channelize down to T1/E1 or T3/E3 (for example, CT3,
cOCx/STMx modules) and IP/PPP/SONET on any module that
supports SONET/STM interfaces (for example, the OCx/STMx
modules). This allows service providers to accept traffic from
3-12 CHAPTER 3
Software Overview

subscribers who have CPE equipment, such as routers with PPP

interfaces, and to output traffic in PPP format to other network
devices.

Business Users

ERX System

IP/PPP

Uplink to core
IP/PPP/SONET
IP/PPP

Service Provider Network

Figure 3-4 The ERX System Supports IP/PPP Connections from the CPE

Figure 3-4 shows that the ERX system supports the incoming IP/PPP
traffic from the CPE. This traffic can then be routed to the uplink(s)
attached to the system or to other CPEs that are attached to the system.

PPP Features
The following PPP features are supported:
• Point-to-Point Protocol (PPP) – RFC 1661
• PPP in HDLC-like Framing – RFC 1662
• PPP over SONET/SDH – RFC 1619
• PPP Internet Protocol Control Protocol (IPCP) – RFC 1332 and
OSI Network Layer Control Protocols (OSINLCP)
• Bit-synchronous HDLC support on the E1/T3/E3 modules;
byte-synchronous support on the OC3/STM1/OC12/STM4
modules
• Link Control Protocol (LCP) support – maximum receive unit
(MRU) (RFC 1661), magic number (RFC 1661): Detection of
looped-back links recommended for SONET
• Reporting of link events (up or down) to the IP layer
 IP 3-13
ERX Edge Routers

PPP Statistics Tracking

The PPP layer is capable of tracking a number of statistics:
• Total number of frames discarded on input that are not LCP, IPCP,
IP, OSINLCP, or OSI frames
• The number of frames received with an incorrect address/control
field
• The number of frames transmitted that exceeded the MTU
• The number of frames received with a checksum error
• The number of frames and bytes successfully received and
transmitted
• Statistics collected via the Generic Interface MIB, including
> Octets received and transmitted
> Receive errors, discards, and unknown protocols
> Transmit errors and discards
> Received and transmitted unicast packets
• Statistics collected via the PPP MIB, including
> Bad addresses, controls, frame check sequence (FCS), and
packets too long
As shown in Figure 3-5, PPP can exist directly on top of the HDLC
layer or on top of a layer 2 ATM interface. In either case, IP rides on
top of PPP, providing support for IP/PPP/ATM and IP/PPP/HDLC.
Both SONET and DSx/Ex interfaces are supported at the physical
layer.

IP

PPP

ATM HDLC

SONET DSx/Ex

Figure 3-5 Structure of PPP Protocol

3-14 CHAPTER 3
Software Overview

Multilink PPP The ERX system supports MLPPP on any modules that are
channelized to fractional or full T1/E1. MLPPP aggregates multiple
physical links into a single logical bundle. More specifically, MLPPP
bundles multiple link-layer channels into a single network-layer
channel. Peers negotiate MLPPP during the initial phase of Link
Control Protocol (LCP) option negotiation. Each system indicates that
it is multilink capable by sending the multilink option as part of its
initial LCP configuration request.
The systems joined by the multilink each assign the same unique name
to the bundle. A bundle can consist of multiple physical links of the
same type—such as multiple asynchronous lines—or can consist of
physical links of different types—such as leased synchronous lines and
dial-up asynchronous lines.
The system treats MLPPP like another PPP Network Control Protocol
(NCP). Packets received with an MLPPP header are subject to
fragmentation, reassembly, and sequencing. Packets received without
the MLPPP header cannot be sequenced and can be delivered only on a
first-come, first-served basis

IP/FR The ERX system supports IP over Frame Relay (FR) PVCs on any
module that supports fractional or full T1/E1 or T3/E3. The system
supports FR over POS interfaces on the OCx/STMx POS modules.
With this interface, the service provider can
• Take in traffic from subscribers that have CPE equipment such as
routers with FR interfaces
• Take in traffic from other network devices that send output in FR
such as DSLAMs and FR switches
• Use FR as an uplink technology on an unchannelized T3 or E3 link
 IP 3-15
ERX Edge Routers

Business and
Consumer Users

ERX System

IP/FR

IP/PPP/FR
Uplink to core
DSLAM
FR

IP/PPP/FR

Service Provider Network

IP/PPPoE/FR

Figure 3-6 ERX System IP/PPP and IP/FR Access Connections

Figure 3-6 illustrates that the ERX system can accept a number of
access technologies and support return paths to the CPE or paths to the
core. Typical FR interfaces come from a CPE-based router, a DSLAM,
or a public network-based Frame Relay switch.

Frame Relay Features

The ERX system supports the following FR features:
• RFC 2427/1490 standards compliance for IP and IS-IS
encapsulation
• Configuration of either DTE or DCE FR user-to-network
interfaces (UNIs) or network-to-network interfaces (NNIs)
• Packet format: 8188-byte information field size (8192 minus 2 bytes
for the address and a 16-bit CRC) or 8186-byte information field
size (8192 minus 2 bytes for the address and a 32-bit CRC)
• Multiple Frame Relay subinterfaces per major interface
• Local management interface (LMI) support in adherence with the
ANSI (T1.617 Annex D), CCITT (ITU-T Q.933 Annex A), and
original Group of Four (DEC, Nortel, Stratacom and Cisco)
specifications
• Support for 1,000 FR VCs on a single line module
3-16 CHAPTER 3
Software Overview

Figure 3-7 shows the structure of the ERX system Frame Relay
interface. Each Frame Relay major interface sits on top of an HDLC
interface. The FR implementation is divided into two levels: a “major”
interface and one or more “subinterfaces.” This line allows a single
physical interface to support multiple logical interfaces. Multiple IP
interfaces can also be assigned to each FR major interface via the
subinterfaces.

IP Interface IP Interface OSI Interface IP Interface

Frame Relay Frame Relay Frame Relay

Subinterface 1 Subinterface 2 Subinterface N

Frame Relay
Major Interface
Frame Relay Layer

HDLC

Figure 3-7 ERX System Frame Relay Interface Design

Figure 3-8 shows the structure of the FR protocols with the physical
layer as the foundation. For Frame Relay, this can be E1, E3, T1, T3,
or fractional amounts, as supported by the different line module ports.
The HDLC layer is on top of the physical layer and can support flexible
assignment of physical resources. For example, an HDLC channel can
support one DS0, Fractional T1s, or an entire T1. The major FR
interface sits on top of the HDLC resource, and the subinterfaces sit on
top of the major interface. The FR subinterfaces connect to the IP
interface layer.
 IP 3-17
ERX Edge Routers

IP
PPP

L
Frame Relay M
I

HDLC

Physical (DSx/Ex)

Figure 3-8 Structure of FR Protocols

The ERX system supports FR LMI (local management interface) to

provide the operator with configuration and status information relating
to the FR VCs in operation. LMI specifies a polling mechanism to
receive incremental and full status updates from the network. The
system can represent either side of the UNI interface and supports
unidirectional LMI. Bidirectional support for NNI is also provided.

Configurable LMI Parameters

The following LMI parameters can be configured on the system:
• The DTE keepalive polling interval to determine how often the
DTE polls the network for a status request (T391: range 5-30
seconds)
• The DCE network response interval for status verification (T392:
range 5-30 seconds)
• The DTE number of normal status requests before a full status is
requested (N391: range 1-255)
• The number of error counts such as invalid sequence number, CRC
error, or nonreceipt of a status response (N392: range 1-10) of the
last “n” packets received (N393: range 1-10) before the interface is
to be marked inactive
3-18 CHAPTER 3
Software Overview

Multilink Frame The ERX system supports Multilink Frame Relay (MFR) on any
Relay modules that are channelized to fractional or full T1/E1. The system
also supports MFR over POS interfaces on the OCx/STMx POS
modules.
MFR aggregates multiple physical links into a single logical bundle.
More specifically, MFR bundles multiple link-layer channels into a
single network-layer channel.
The systems joined by the multilink each assign the same unique name
to the bundle. A bundle can consist of multiple physical links of the
same type—such as multiple asynchronous lines—or can consist of
physical links of different types—such as leased synchronous lines and
dial-up asynchronous lines.
The system treats MFR like nonmultilink Frame Relay. Packets
received with an MFR header are subject to sequencing. Packets
received without the MFR header cannot be sequenced and can be
delivered only on a first-come, first-served basis.

IP/ATM The ERX system supports IP over ATM PVCs on modules that
support T3/E3 or SONET/STM interfaces (for example, T3/E3,
OC3c/STM1, and OC12c/STM4). This feature allows service
providers to take in traffic from subscribers that have CPE equipment
such as routers with ATM interfaces, to take in traffic from other
network devices that send output in ATM such as DSLAMs, and to
connect to service providers with ATM backbone structures. See
Figure 3-9.
 IP 3-19
ERX Edge Routers

Business and
Consumer Users

ERX System

IP/ATM

IP/PPP/ATM

ATM
DSLAM Uplink to
ATM

IP/PPP/ATM

Service Provider Network

IP/PPPoE/ATM

Figure 3-9 ERX System IP/ATM Access Connection

ATM Features
The ERX system supports the following ATM features:
• IP transport over ATM – RFC 2684, Multiprotocol Encapsulation over
ATM Adaptation Layer 5 (September 1999), which replaces RFC
1483. Both methods of RFC 2684 encapsulation are supported:
LLC encapsulation, where the LLC header is used to multiplex
multiple protocols on a single circuit; and VC multiplexing, where
no headers are used and only a single protocol may use that circuit.
• ATM Forum User-Network Interface (UNI) versions: 3.0, 3.1, 4.0
selectable per port
• ATM adaptation layer 5 (AAL5) frame format
• ATM monitoring per interface with support for ILMI. The ILMI
version is selectable and optionally enabled on a per-port basis.
ATM ILMI MIB – MIB-II System Group, Physical Port Group,
ATM Layer Group, Virtual Path Group, and Virtual Channel Group
are supported.
• ATM monitoring per circuit or path with support for operations,
administration, and maintenance (OAM). Specifically, the system
supports F4 and F5 cell flows, including ATM ping. Two types of
tests are supported to allow for test isolation: from the ERX system
to the end host and from the ERX system to the ATM switch.
3-20 CHAPTER 3
Software Overview

• Traffic shaping for UBR, VBR-RT, VBR-NRT, and CBR service

on an individual VC basis.
• Point-to-multipoint connection using nonbroadcast multiaccess
(NBMA) interfaces, allowing you to connect an ERX system to
multiple stations.

ATM Protocol Structures

Figure 3-10 shows the structure of the ATM protocols with the
physical layer as the foundation. For ATM, this can be SONET, DS3,
or E3 as supported by the different line modules. The major ATM
interface sits on top of the SONET/DS3/E3 resource, and the
subinterfaces sit on top of the major interface. The ATM subinterfaces
connect to the IP/OSI interface layer.

IP Interface IP Interface OSI Interface IP Interface

ATM ATM ATM

Subinterface 1 Subinterface 2 Subinterface N

ATM
Interface
ATM Layer

SONET DS3/E3

Figure 3-10 Structure of the ATM Interface Design

Figure 3-11 shows the structure of the ATM protocols. The physical
layer (SONET and DSx/Ex) is the foundation and provider of layer 1
framing service. The ATM layer is on top and provides cell, circuit, and
OAM services. The AAL5 layer provides a frame-oriented interface to
the ATM layer. ILMI provides local management across the UNI.
 IP 3-21
ERX Edge Routers

IP
PPP

RFC1483 Data Service I

L
M
LLC I

AAL5

ATM

SONET DSx/Ex

Figure 3-11 Structure of ATM Protocol

The AAL5 layer also supports RFC 2684 encapsulation. The RFC
2684 data service layer defines the ERX system subinterfaces that are
used by higher-level ATM services. The ATM subinterfaces connect to
the IP interface layer.

IP/Cisco HDLC The ERX system supports IP over Cisco HDLC on any module that
supports HSSI, T1/E1, T3/E3, or SONET/STM interfaces.
Cisco HDLC monitors line status on a serial interface by exchanging
keepalive request messages with peer network devices. It also allows
routers to discover IP addresses of neighbors by exchanging SLARP
address request and address response messages with peer network
devices.
The ERX system Cisco HDLC is compatible with Cisco Systems
HDLC protocol, the default protocol for all Cisco serial interfaces.

Cisco HDLC Features

The ERX system supports the following framing features:
• HDLC for data-link framing
• 18,000-byte information field size
The system also supports the exchange of keepalive messages that
identify inactive or failed connections.
3-22 CHAPTER 3
Software Overview

IP

Cisco HDLC

ATM HDLC

SONET DSx/Ex

Figure 3-12 Structure of Cisco HDLC Protocol

Figure 3-12 shows that the Cisco HDLC protocol can exist directly on
top of the HDLC layer or ATM or SONET interface. Both SONET
and DSx/Ex interfaces are supported at the physical layer.

Bridged IP Your ERX system supports bridged IP on the T3-ATM, E3-ATM, and
OC3 modules. You can configure a bridged IP interface on your ERX
system to manage IP packets that are encapsulated inside an Ethernet
frame running over a permanent virtual circuit (PVC).
When you configure a bridged IP interface, you can also configure the
system as a relay agent that forwards Dynamic Host Configuration
Protocol (DHCP) broadcasts.

DS3/DS1/E3/E1
The ERX system supports a number of line rates; these are listed per
line module below:
• CT3 line module supports channelized DS3 (channelized to DS1,
fractional DS1, or the DS0 level)
• T3 line module supports unchannelized DS3 and fractional T3
• CT1 line module supports T1 and fractional T1
• E3 line module supports unchannelized E3
• CE1 line module supports E1 and fractional E1
• cOCx/STMx line modules support T3, E3, T1, E1, and DS0 rates
For specifications on line modules, see Chapter 2, Hardware Overview.
A variety of protocols are supported over these interfaces, including
IP/FR, IP/ATM, IP/PPP, as well as the protocols to enable B-RAS
services (see B-RAS Support in this chapter for more information). The
ERX system DSx and E1/E3 implementations support termination,
 DS3/DS1/E3/E1 3-23
ERX Edge Routers

statistic gathering, alarm surveillance, and performance monitoring.

These links can be used for either network ingress or network egress.

CT3 ERX System Uplink to Core

FT1
Business T1 OC3/STM1
and
T3
Consumer E1
Users fE1 DS3/E3
E1

Edge Core
Service Provider Network

Figure 3-13 The ERX System Supports Fractional T1/E1 Through T3/E3 Interfaces

As shown in Figure 3-13, the system can support fractional, full, and
channelized interfaces.

Line Module The following features are supported by the line modules listed above:
Support
• Three different clocking options: internal timing, loop timing, and
chassis timing
• DS3 and DSI bit error rate tests (BERTs)
• DS3 framing type – both M23 framing and C-bit parity
• DS1 framing type – both D4 framing mode and ESF framing mode
• DS3 loopback – for line, payload, diagnostic, and DS1 (see
Diagnostic Support in Chapter 5 for more information)
• DS1 loopback – for line, payload, and diagnostic (see Diagnostic
Support in Chapter 5 for more information)
• SONET/SDH loopback
• DS3/DS1 line status/alarm monitoring
• DS1 line coding type – both AMI line encoding and B8ZS line
encoding
• Unique IP interface support – for each PPP or Frame PVC
interface
3-24 CHAPTER 3
Software Overview

Configurable The following HDLC parameters are configurable:

HDLC • Mapping of DS0 timeslots for T1/FT1 DS0 mapping
Parameters
• Setting the speed of the DS0 to Nx56 or Nx64
• HDLC CRC checking (enable/disable)
• HDLC CRC algorithm (CRC16 or CRC32)
• Channel Data Inversion (enable/disable)
• Maximum receive unit (MRU)
• Maximum transmit unit (MTU)
Statistics are also gathered per line interface.

SONET
The ERX system supports:
• IP/PPP and IP/FR over SONET on the cOCx/STMx line
modules
• IP/ATM and IP/PPP over SONET on the OCx/STMx line
modules
This support allows service providers to accept incoming optical
connections or connect the system to the backbone network via optical
connections. The ERX system SONET implementation supports
termination, statistic gathering, alarm surveillance, and performance
monitoring at the section, line, and path layers of a SONET interface.
See Figure 3-14.

ERX System Uplink to Core

Business FT1
and
OCx/STMx
Consumer T1
Users
E3
OC12/STM4
OC3/STM1

Edge Core
Service Provider
Network

Figure 3-14 The ERX System Supports SONET Interfaces

 SONET 3-25
ERX Edge Routers

SONET Features The ERX system supports the following SONET features:
• Telcordia Technologies GR-253-CORE common generic criteria
feature set
• Configurable SONET or SDH operational support
• SONET statistics collection
• Generation of remote defect indication (RDI) signals at the line and
path layers for loss of signal (LOS), loss of frame (LOF), loss of
pointer (LOP), and alarm indication signals at the line and path
(AIS-L and AIS-P)
• Signaling of remote error indication (REI) at the line and path
layers
• Transmit clock configuration options for recovered receive clock
(loop timing) or internal generation. The clock source can be pulled
from the internal clock on the SRP or any externally connected
clock source. A common system-wide clock is supported, as well as
configuration options for a different clock source per line module.
• Support for two loopback modes: Line Loopback to connect the
received network signal directly to the transmit network signal line
and Internal Loopback to connect the local transmitted signal to the
local received signal

SONET Statistics are gathered on the SONET section, line, and path interfaces
Statistics in 15-minute intervals:
• Errored seconds – section: SEF defect, LOS defect, or coding
violation (CV); line: seconds with AIS-L or CV; path: seconds with
AIS-P, LOP defect, or CV
• Severely errored seconds – section: errored seconds with x CV, SEF
defect, or LOS defect; line: errored seconds with x CV or AIS-L;
path: errored seconds with x CV, AIS-P, or LOP defect
• Severely errored framing seconds – section: seconds with SEF defect
• Coding Violations – section: BIP-8 errors (B1 byte); line: BIP-8*N
errors, (N=STS-N; B2 bytes); path: BIP-8 errors, (B3 byte)
• Unavailable seconds – line: 10 consecutive line SESs; path: 10
consecutive path SESs
3-26 CHAPTER 3
Software Overview

Switched Multimegabit Data Service (SMDS)

SMDS is a wide area networking service designed for LAN
interconnection. SMDS is a connectionless service. An SMDS network
is composed of:
• A series of SMDS switches inside a service provider’s network
• A series of CSUs/DSUs that connect subscribers to the network
• Routers and gateways to connect to each CSU/DSU

SMDS The ERX system’s SMDS implementation addresses an application in

Application which the ERX system offloads the central express ring in an SMDS
network. Figure 3-15 shows an SMDS network before ERX systems
are added.

Subscribers Subscribers

Subnet A Subnet C

Central
Express Ring

Subnet B Subnet D

Subscribers Subscribers

Figure 3-15 SMDS Network with Central Express Ring and Subnets

As shown in Figure 3-16, the ERX system provides a mesh of GRE

tunnel connections as a means of offloading the central express ring.
 Switched Multimegabit Data Service (SMDS) 3-27
ERX Edge Routers

ERX System ERX System

GRE
Tunnels

ERX System ERX System

Central Express
Ring

Figure 3-16 ERX System with GRE Tunnels to Offload the Central Express Ring

To connect the GRE tunnels to each of the subnets, the ERX system
connects to SMDS switches using the 3-port HSSI line module.

Subnet A Subnet C

ERX System ERX System

HSSI HSSI

SMDS Switch SMDS Switch

GRE
Tunnels

HSSI HSSI

SMDS Switch ERX System ERX System SMDS Switch

Subnet B
Subnet D

Figure 3-17 HSSI Line Modules in ERX Systems Provide Connections to SMDS
Switches
3-28 CHAPTER 3
Software Overview

SMDS The following components support the SMDS application:

Components
• HSSI line module – provides the physical interface to connect to the
SMDS switch.
• GRE tunnels – transport SMDS traffic among ERX systems.
• SMDS trunk interface – runs over the HSSI line module and GRE
tunnels.
• Connection-based forwarding (CBF) interfaces and connections –
forward SMDS traffic among SMDS trunk interfaces.
Figure 3-18 shows how these components make up the interface
columns for the SMDS application.

CBF CBF

SMDS SMDS

HSSI GRE Tunnel

Figure 3-18 Interface Columns for the SMDS Application

Routing
The ERX system is a carrier-class router that fully supports both the
interior and exterior IP-based routing protocols used by large service
providers, including BGP-4, OSPF, RIP, and IS-IS. This routing
support allows service providers to deploy the system into existing
network architectures and delivers full interoperability with older
routing products.
Full routing is supported between all line interfaces in the system,
including U-turn routing on a single port. All routing support
integrates fully into the other features supported by the system,
including layer 2 support and QoS capabilities, allowing a service
provider to build leading-edge routing services for their subscribers.
 Routing 3-29
ERX Edge Routers

Routing There are three key features of the ERX system routing
Features implementation:
• The system implements a fully distributed routing scheme that
supports wire-speed packet forwarding for small packet sizes across
all interfaces simultaneously.
• All Tier-1 ISP routing protocols are supported, including BGP-4,
OSPF, IS-IS, and RIP, and are highly scalable to address the needs of
large networks.
• The system allows multiple virtual routers to be created, with
separate route protocols and route tables supported on the different
router instances.
The following are additional features of the routing implementation:
• Scalable IP routing with standards support for routing requirements
for IPv4 – RFC 1812
• Routing protocol support for BGP-4, OSPF, RIP, and IS-IS
• Virtual router support
• IP multicast support for DVMRP, IGMP, MBGP, PIM
• Access list, route map, and distribution list support for creating and
applying routing filters
• Wire-speed performance forwarding with minimum packet sizes
• Load balancing to compute equal cost paths based on routing
protocol information

The ERX The ERX routing architecture is designed specifically to address the
Routing needs of large service provider routed networks. It has a highly scalable
Architecture design; as more line modules are added to a chassis, more packet
processing power is added. The system performs at wire speed, even
with 40-byte packets and all IP features (QoS, VPNs, statistics) enabled.
The routing architecture is distributed—each individual line module
executes route lookups and forwarding decisions based on a common
routing table. These two functions are described in detail below.
The ERX SRP module builds and stores a common IP route database
for up to 500,000 routes. The information maintained for each route
includes at least: destination IP address, prefix length, equal cost path
calculations, route redistribution information, the protocol that added
the route (static, RIP, OSPF, BGP-4), and attributes specific to that
protocol (such as layer 1 vs. layer 2 and interior vs. exterior).
3-30 CHAPTER 3
Software Overview

Routes in the routing table can be shared between routing protocols,

and any routing protocol can add routes to the table. The level of
interaction between the different routing protocols is configurable. The
common route table is stored centrally on the SRP module, but it is
compressed and multicast downloaded to each individual line module.
Note: If virtual routers are configured, each virtual router has its own logically
distinct route database.

Figure 3-19 shows the route table creation and distribution process.
The SRP module gathers the routing information and stores it in a
centralized table. It then sends updates to each line module. Each line
module maintains a complete route table. This feature allows incoming
packets to be processed quickly and efficiently in contrast to approaches
that must rely on IP address or route caching.
The ERX route lookup and forwarding execution is completely
distributed. When a packet is received on the line module, the route
table lookup is performed entirely on that module with the routing
table that is already located on the module. If the route is not in the
route table, the destination is considered unreachable and an ICMP
unreachable packet is sent. This distributed processing architecture
eliminates the performance restrictions found in centralized
approaches.
A route tag is prepended to the packet, which indicates the ERX egress
port associated with the route, and the packet is sent to the switch
fabric for transport to the egress port.
 Routing 3-31
ERX Edge Routers

1 Backbone Network
route
2 information

3 SRP 3

SRP Module
CT3 OC3

Line Module Line Module

1 SRP creates and maintains the route table.
2 SRP multicasts updates to the line modules.
3 Each line module has a full route table.

Figure 3-19 ERX System Route Table Distribution Overview

Route Control The ERX system supports a number of features that allow the service
provider to control the exchange of routing information between
virtual routers in the system, between routers in the network, and
between protocols within a router:
• Access lists – Provide filters that can be applied to route maps or
distribution lists. They allow policies to be created, such as those to
prevent forwarding of specified routes between the BGP-4 and
IS-IS route tables.
• Route maps – Modify the characteristics of a route (generally to set
its metric or to specify additional attributes) as it is transmitted or
3-32 CHAPTER 3
Software Overview

accepted by a router. Route maps may use access lists to identify the
set of routes to modify.
• Distribution lists – Control the routing information that is accepted
or transmitted to peer routers. Distribution lists always use access
lists to identify routes for distribution. For example, distribution lists
could use access lists to specify routes to advertise.
• Redistribute routes – Redistribution allows routes to be shared
between routing protocols and routing domains. For example, a
subset of BGP-4 routes could be leaked into the IS-IS route tables.

Virtual Routers
The ERX system supports multiple distinct routers within a single
system. This support allows service providers to configure multiple
separate secure routers within a single chassis. Applications for this
function include the creation of individual routers dedicated to
wholesale customers and corporate VPN users, or routers dedicated to
a specific traffic type. The system can support up to 240 virtual routers
per module or per chassis.
A network device attaching to an ERX router sees a router interface.
The attaching device has no notion of the virtual router behind the
interface. For example, a physical Frame Relay link may have circuits
that are connected to different virtual routers. The physical and
data-link layers are not aware that there are multiple router instances.
The ERX system implements the virtual routers by maintaining a
separate instance of each data structure for each virtual router and
allowing each protocol (TCP/UDP, RIP, OSPF, BGP-4, IS-IS) to be
enabled on a case by case basis. There is a table of router interfaces to
associate user connections (for example, PPP or FR) with one or more
IP interfaces within a virtual router.
As mentioned above, the ERX routing protocol suite provides full
support for BGP-4, IS-IS, OSPF, and RIP. These protocols can be
enabled or disabled for each instance of a router in the ERX system.
Each of these protocols is covered in detail in the following subsections.
In addition, each virtual router can be independently managed with
secure access between virtual routers.
 Routing 3-33
ERX Edge Routers

BGP-4 Support The ERX system supports a highly scalable and robust version of the
Border Gateway Protocol (BGP-4), designed specifically for large-scale
networks. Large service providers typically use BGP-4 as the protocol
of choice for interaction with external networks, such as peer and
wholesale networks.

BGP Features
BGP-4 features include:
• BGP-4 – RFC 1771
• BGP-OSPF interaction – RFC 1745
• Communities – RFC 1997, 1998 – community attributes
• Extended communities – draft RFC
• Confederations – RFC 1965
• Route reflectors – RFC 1966
• Route flap dampening – RFC 2439
• Tier 1 ISP class route filtering, route mapping and attribute
manipulation capabilities, as well as route redistribution
• Highly scalable BGP-4 architecture to support hundreds of BGP-4
peers and hundreds of thousands of routes. Scaling will increase with
future software releases.
• BGP-4 neighbor setup
• Exterior BGP (EBGP) multihop to accept and attempt BGP-4
connections to external peers residing on networks that are not
directly connected
• Next-hop self to disable the next-hop BGP-4 update route
processing
• Soft-reconfiguration inbound to enable storing of received updates
without regard to the inbound policy
• Update source to allow interior BGP (IBGP) sessions to use any
interface for TCP connections
• Advertisement interval, which sets the interval between sending
BGP-4 routing updates
• Shutdown to stop BGP-4
• Maximum prefix to restrict the number of prefixes that can be
received from a neighbor
• MD5 authentication to support MD5 authentication on a TCP
connection between two BGP-4 peers
3-34 CHAPTER 3
Software Overview

• Network command to specify BGP-4 route origin as IGP

• No synchronization command support to support network route
advertisement without waiting for the IGP
• BGP-4 peer groups to add BGP-4 neighbors as members of a peer
group
• BGP-4 aggregation – with/without AS sets, attribute modification
during aggregation
• BGP-4 access list – AS-path list, community list, distance/BGP
distance, distribute-list in/out, regular expressions (for AS-path list
comparisons)
• BGP multiprotocol extensions – RFC 2545
• BGP/MPLS VPNs – RFC 2547 – virtual private networks using
MPLS to carry data and BGP to carry routes and labels
• Route map support
• Overlapping VPNs
• Automatic route-target filtering
• Support for automatically ending BGP sessions if the link to any
adjacent external peer fails

IS-IS Support The ERX system supports a highly scalable version of the Intermediate
System–to–Intermediate System (IS-IS) protocol, designed specifically
for large-scale networks. IS-IS is a link state protocol. It is increasingly
being used by large service providers as the interior routing protocol to
share route table information between routers in the same service
provider network.

IS-IS Features
IS-IS features include:
• Integrated IS-IS – ISO 10589 standard and RFC 1195, use of OSI
IS-IS for routing in TCP/IP and dual environments, and draft
extensions to RFC 1195
• Level 1 and level 2 routing
• Internal optimization of route leaking from level 1 to level 2
• Highly scalable IS-IS architecture. The number of adjacencies and
routes will be scaled higher with future software releases.
• Subnetwork-dependent functions to enable IS-IS transport over all
media types supported by the interfaces
 Routing 3-35
ERX Edge Routers

• Configuration control over the maximum number of addresses per

area
• IS-IS computation for equal cost paths
• Adjacency and Link State Protocol (LSP) overrun to prevent other
routers from using ERX paths in overrun states during route
calculation
• Overload bit to force the system into overrun state
• ID field length configurable from 1-8 octets to support large-scale
networks
• Router ID included in IS-IS hello PDUs for unnumbered
point-to-point links
• Mesh groups to reduce the IS-IS protocol overhead within fully
meshed networks. When configured in a mesh group, LSPs seen on
one interface in a mesh group will not be flooded to another
interface in the same mesh group. Alternatively, you can select a
specific router in the mesh to be a server for all other routers within
the mesh group.
• Periodic complete sequence number packet (CSNP) on
point-to-point links to help mesh groups keep their databases
synchronized to recover quickly from failed mesh matrices
• No IS-IS database purge on checksum error/ignore LSP error
• Checksum errored IS-IS LSPs allowed to be ignored rather than
purging the LSPs
• Ability to configure up to three areas in one router
• Authentication within the IS-IS packet with PDU or MDU
• Selective route redistribution to control which routes should pass
between the different databases (level 1 and level 2)
• Commands – Timers: IS-IS hello-interval per level, hello-multiplier
per interface, LSP-interval per interface, retransmit-interval per
interface, retransmit-throttle-interval per interface, SPF interval,
LSP maximum life, summary address level 1, level 1-2, level 2, IS-IS
metric, CLNS host, log-adjacency-changes, IS-IS mesh-group
blocked
• Support for MPLS traffic engineering
3-36 CHAPTER 3
Software Overview

OSPF Support The ERX system fully supports the Open Shortest Path First (OSPF)
routing protocol. This protocol is used by service providers to keep
route table information updated between the routers in a service
provider network, and as a means to communicate with other
POP-based network equipment. OSPF is an interior link state based
routing protocol.

OSPF Features
The ERX system implementation supports the following key features:
• OSPF Version 2 – RFC 2328
• NSSA and Opaque LSA – RFC 1587 and RFC 2370
• Intra-area and interarea routes, with each area running as a separate
network in order to reduce the size of the link state database in large
networks
• Highly scalable OSPF architecture to support hundreds of OSPF
adjacencies and tens of thousands of routes. The adjacencies and
routes will be scaled higher with future software releases.
• Virtual link to create a logical link between two backbone area
routers that are not physically adjacent, where the logical link
tunnels through a nonbackbone area
• Nonbroadcast network, where a separate IP interface is defined for
each neighbor, creating a series of separate point-to-point links
• Three types of authentication for protocol exchanges: null
authentication, simple password authentication, and cryptographic
authentication
• Opaque LSAs that will be accepted from other routers and be
flooded accordingly
• Capability of new routes to be leaked into the routing table either
by another routing protocol or through a static route
• Equal-cost multipath to insert all equal instances of available routes
• MD5 authentication
• Type 1 and Type 2 external routes
• Load sharing to balance loads across equal cost paths
 Routing 3-37
ERX Edge Routers

RIP Support The ERX system supports RIPv1 and RIPv2 routing protocols.
Service providers use RIP to communicate with other POP-based
networking equipment or, on subscriber access links, to communicate
with CPE devices that are running RIP.

RIP Features
The system supports the following features:
• Compliance with RFC 2453 – RIPv2
• Backward compatibility with RIPv1

MPLS Support Unisphere’s ERX system is designed to support the emerging

requirements for Multiprotocol Label Switching (MPLS) as an
integrated IP technology for improving traffic engineering, adding
VPN functions, and scaling capabilities for IP networks. Unisphere is
closely following the work on MPLS and is an active participant in the
IETF and external MPLS user forums.
MPLS specifies a means to generate and attach a “label” to individual
packets. This label, rather than the information contained in the IP
header (such as the source or destination address), is then used to make
forwarding decisions about the packet. This process is a departure from
current routing practice, where every router node in the network
handles an IP lookup to make a forwarding decision, resulting in a
hop-by-hop approach to packet control. The IP packets are labelled at
the edge of the network by the ERX edge router. The rest of the
network then relies on the label to forward the packet over an
appropriate path. As the packet leaves the network, the MPLS label is
removed.
Service providers can use MPLS to set up sophisticated
subscriber-based or traffic-based policies at the network edge, while
easing the lookup and transport requirements on the backbone. Service
providers can use the ERX system to perform a multifield search on the
IP header to determine the type of MPLS label to apply. Once the label
is applied, the rest of the network can use the labels to handle lookup,
rather than performing lookups against the entire route table.
The system supports MPLS for both traffic engineering and scalable
VPNs.
3-38 CHAPTER 3
Software Overview

MPLS Features
The ERX system supports the following MPLS features:
• LDP, CR-LDP, or RSVP-TE
• ATM, POS, Gigabit/Fast Ethernet
• Integration with extended IGP protocols (OSPF, IS-IS) to support
traffic engineering via constraint-based explicit routes
• Label edge routing (initiate/terminate LSP) or core LSR (forward
only based on label)
• Label stacking
• CAC for bandwidth accounting and service enforcement
• Downstream-on-demand, ordered control label distribution and
downstream-unsolicited, independent control label distribution
• Topology-driven LSPs for LDP hop-by-hop MPLS networks,
which enable the LDP to learn all IGP routes from IP and
automatically create LSPs for all routes, resulting in a fully meshed
MPLS network
• Label filtering for topology-driven mode, which determines
whether and where incoming labels are distributed

MPLS Applications
• Traffic engineering
• VPNs (including MBGP support)
• QoS/CoS
> Classifier association of traffic with LSP
> Ability of all LSPs to make use of QoS features

BGP/MPLS VPNs
The ERX system supports the BGP multiprotocol extensions, which
enable BGP to exchange routing information for different types of
address families. The VPN-IPv4 address family enables the outsourcing
of IP backbone services via the configuration of virtual private
networks across the IP backbone. BGP/MPLS VPNs are scalable and
flexible and enable service providers to offer value-added services. BGP
carries routing information for the network and MPLS labels, while
MPLS transports the data traffic. Figure 3-20 shows a typical scenario.
 Routing 3-39
ERX Edge Routers

Customer
Site CE
Newport
CE
Boston

CE
PE
CE

Service
Provider
CE CE
Core
PE P

P PE

CE
P
CE

P
PE
CE

CE PE
VPN A
VPN B
VPN C

Public Internet

Figure 3-20 BGP/MPLS VPN Scenario

The backbone through the service provider core comprises two types
of routers:
• Provider edge routers (PEs) sit at the edge of the service provider
core and connect directly to customer sites. These routers must run
BGP-4, including the BGP/MPLS VPN extensions. They must also
be able to originate and terminate MPLS LSPs.
• Provider core routers (Ps) connect directly to PEs or other Ps and
do not connect directly to customer sites. These routers must be
able to switch MPLS LSPs. It is not necessary to run BGP-4 on the
P routers to be able to exchange routing information for VPNs.
The P routes do not need to possess any information about
customer sites.
PEs communicate with customer sites via a direct connection to a
customer edge (CE) device that sits at the edge of the customer site.
The CE can be a single host, a switch, or a router. If the CE is a router,
3-40 CHAPTER 3
Software Overview

it is a routing peer of all directly connected PEs, but it is not a routing

peer of CEs at any other site. The link between the CE and the PE can
employ any type of encapsulation. It is not necessary to use MPLS. In
Figure 3-20, each PE connects to multiple CEs and at least one P.
Although only one customer site is shown, each CE lies within a
customer site.
Each customer site is a network that can communicate with other
networks in the same VPN. A customer site can belong to more than
one VPN. Two sites can exchange IP packets with each other only if
they have at least one VPN in common.
Each customer site that is connected to a particular PE is also associated
with a forwarding table, known as a VPN routing and forwarding table
(VRF), as shown in Figure 3-21.
You assign one or more (sub)interfaces to a given VRF. If multiple
customer sites are members of the same set of VPNs, they can share a
VRF. The system looks up a packet’s destination in the VRF associated
with the interface on which the packet is received. The VRFs are
populated by BGP as it learns routes from the VPN. If a customer site is
a member of multiple VPNs, the routes learned from all those VPNS
populate the VRF associated with the site.
VRFs exist within the context of a virtual router (VR). A given virtual
router can have zero or more VRFs, in addition to its global routing
table (which is not associated with any VPN, CE, or customer site). An
ERX system can support up to 240 forwarding tables; that is, up to a
total of 240 VRs and VRFs per module or per chassis.
 Routing 3-41
ERX Edge Routers

Customer
Site 1 PE1
CE1

Virtual Router 1
Customer
Site 2
VRF A
CE2
VRF
forwarding VR1 global
Customer
table forwarding to another
Site 3 VRF B table PE router
CE3
VRF
forwarding
table
Customer
Site 4 VRF C
CE4 VRF
forwarding
table
Customer
Site 5 Virtual Router 2
CE5
VR2 global
forwarding
table
VPN A
VPN B

Figure 3-21 BGP/MPLS VPN Components

IP Multicasting The ERX system supports IP multicasting. IP multicasting improves

network efficiency by allowing a host to transmit a datagram to a
targeted group of receivers. For example, a host may want to send a
large video clip to a group of selected recipients. It would be
time-consuming for the host to unicast the datagram to each recipient
individually. If the host broadcasts the video clip throughout the
network, network resources are not available for other tasks. The host
uses only the resources it needs by multicasting the datagram. A
multicast datagram is effectively a broadcast to a limited group of
network devices.
Routers use multicast routing algorithms to determine the best route
and transmit multicast datagrams throughout the network. Table 3-1
lists the protocols the system supports and the function that each
protocol provides.
3-42 CHAPTER 3
Software Overview

Table 3-1 Function of Multicast Protocols on a Router

Protocol Function
Internet Group Discovers hosts that belong to multicast group.
Membership Protocol
(IGMP)
Protocol Independent Discovers other multicast routers that should receive
Multicast Protocol (PIM) multicast packets.
Distance Vector Multicast Routes multicast datagrams within autonomous systems.
Routing Protocol
(DVMRP)
BGP Multicasting Protocol Routes multicast datagrams between autonomous
systems.

The ERX system supports up to 16,384 multicast forwarding entries

(multicast routes) at any time.

IGMP
IP hosts use Internet Group Management Protocol (IGMP) to report
their multicast group memberships to neighboring routers. Similarly,
multicast routers, such as the ERX system, use IGMP to discover
which of their hosts belong to multicast groups.
The IPv4 address scheme assigns Class D addresses for IP multicasting.
IGMP is the protocol that uses these addresses, which can be in the
range 224.0.0.0 to 239.255.255.255. The following addresses have
specific functions or are unavailable:
• 224.0.0.0 is reserved and you cannot assign it to a group.
• 224.0.0.1 is the all-hosts address – a packet sent to this address
reaches all hosts on a subnet.
• 224.0.0.2 is the all-routers address – a packet sent to this address
reaches all routers on a subnet.
This implementation of IGMP complies with RFC 2236 (IGMPv2).
IGMPv2 routers support both IGMPv1 and IGMPv2 hosts.

PIM
Protocol Independent Multicast (PIM) is the protocol that allows
multicast routers to identify other multicast routers that should receive
packets. This implementation of PIM supports PIM dense mode (DM),
PIM sparse mode (SM), and PIM sparse-dense mode (S-DM).
 Routing 3-43
ERX Edge Routers

Figure 3-22 represents how PIM builds a source-group entry in a

source based tree. The designated router (DR) receives data from the
source on interface 1/0 and multicasts the data to its downstream
neighbors on interfaces 1/1, 2/0, and 2/1. In the DR routing table, the
entry for this operation lists the source as the IP address of the source
and the group as the IP address of the multicast group.

Source DR Routing Table Entry

128.5.4.33
Source 128.5.4.33
Group 225.1.3.5
1/0 Register 1/0
DR
2/1 RP 1/1, 2/0, 2/1
1/1 2/0
Input Interface 1/0
Output Interface 1/1, 2/0, 2/1

Pim Router Pim Router Pim Router

Figure 3-22 Source-Routed Tree

DVMRP
The ERX system supports Distance Vector Multicast Routing Protocol
(DVRMP) on virtual routers to forward multicast datagrams through a
network. DVMRP is an interior gateway protocol that supports
operations within an autonomous system, but not between
autonomous systems. The multicast backbone of the Internet,
MBONE, uses DVMRP to forward multicast datagrams.
DVMRP is a dense mode multicasting protocol and therefore uses a
broadcast and prune mechanism. The protocol builds an SRT in a
similar way to PIM-DM (see Figure 3-22). DVMRP routers flood
datagrams to all interfaces except the one that provides the shortest
unicast route to the source. To prevent unnecessary sending of multicast
messages through the SRT, DVMRP uses pruning. A DVMRP router
sends prune messages to its neighbors if it discovers that:
• The network to which a host is attached has no active members of
the multicast group.
• All neighbors, except the next-hop neighbor connected to the
source, have pruned the source and the group.
When a neighbor receives a prune message from a DVMRP router, it
removes that neighbor from its source group table, which provides
information to the multicast forwarding table.
3-44 CHAPTER 3
Software Overview

If a host on a previously pruned branch wants to join a multicast group,

it sends an IGMP message to its first-hop router. The first-hop router
then sends a graft message upstream.

BGP Multicasting
BGP multicasting is an extension of the BGP unicast routing protocol.
Many of the functions available for BGP unicasting are also available for
BGP multicasting.
The BGP multiprotocol extensions specify that BGP can exchange
information within different types of address families. The address
families available are unicast, multicast, and unicast vpn. When you
enable BGP, the ERX system employs unicast IPv4 addresses by
default. To enable BGP multicasting, you must configure commands
for the multicast address family.

IP QoS

Quality of service is becoming more and more important for several

reasons. Two of those reasons are:
• Bandwidth oversubscription of the edge and the need to prioritize
traffic; for example, business subscribers can be prioritized over
residential users and mission-critical applications over best-effort
data.
• Converged network infrastructure, that is, voice traffic is now
carried over data networks.

Bandwidth Over In most service provider networks, the IP edge is oversubscribed in

Subscription terms of bandwidth. Oversubscription at the edge calls for mechanisms
to provide contractually agreed upon bandwidth guarantees, as well as
to make sure that subscribers get at least a fair amount of the bandwidth
that is available.
Therefore, the following features must be supported in the B-RAS to
ensure traffic prioritization and true QoS at the edge:
• A set of different traffic classes per IP interface and subscriber,
including strict priority queuing.
• Per subscriber and per IP interface queuing; that is, a queue per
traffic class and subscriber.
 IP QoS 3-45
ERX Edge Routers

• Multilevel hierarchical scheduler that can be attached to a physical

port, subport level (for example, ATM PVC), and IP interface
(subscriber).
A high aggregation edge router and B-RAS, such as the ERX system,
must potentially support tens of thousands of queues for each line
module, because each subscriber can have multiple queues. Figure 3-23
shows a single ingress queue being demultiplexed to many egress
queues.

Interface Queuing at the Edge Router

à Uplink: T x N ingress queues are aggregated into a single egress queue (core)

à Downlink: Single ingress queue de-multiplexes into N egress queues (access)

IP Interface

Major I/F
(e.g. VLAN)
Port
n=1
(e.g. ETH)

Core
Access n=N Core
IP Interface w/
4 queues each

- Low Latency Queue

- Best-effort Queue
Edge Router / BRAS - Low Loss Queue
- Low Latency/Jitter Queue

Figure 3-23 Interface Queuing at the Edge Router

Converged In converged network environments (voice media gateways attached to

Network an IP data network), the edge router must assure that voice traffic is
Infrastructure treated differently and is prioritized over all other traffic, because
real-time applications such as voice are sensitive to delay and jitter.
Traffic classes that are emerging in service provider networks are:
• Low latency and low jitter for voice applications
• Low latency for streaming applications
• Low loss for mission critical applications as well as signalling
• Best effort
3-46 CHAPTER 3
Software Overview

The low-latency traffic classes support the DiffServ model of expedited

forwarding as specified in RFC 2598, whereas the low-loss traffic class
is equivalent to the assured forwarding model in RFC 2597.
To offer true quality of service, there are three fundamental
requirements for IP QoS that need to be met in a B-RAS and edge
router:
• Wire-speed forwarding on all interfaces and all packet sizes. That is,
the ability to perform route lookup and packet forwarding at line
rate in all circumstances without dropping a single packet, even at
packet sizes of 40 bytes.
• Wire-speed classification of all packets on all interfaces: on the
ingress and the egress interface. Packet classification is used to
determine the traffic class to which an IP packet belongs and the
service it gets. If a system cannot classify at wire speed, it must drop
packets, even packets with the highest priority.
• Wire-speed performance while applying policy decisions on
forwarding, imposing rate limits, and reclassifying packets such as
marking and stamping and queuing packets.

The ERX Support for quality of service is hardware assisted on the line modules
System by the FPGAs and ASICs. For example, hardware assists with
Implementation color-based thresholding and a single queue per subscriber and IP
of QoS interface.

A common flow of an IP packet through the ERX system involves the

following steps:
1 A packet arrives on ingress line module, where the route look-up and
classification are performed.
Before assigning an IP packet to a traffic class (queue) and giving it a
specified priority, the packet needs to be classified. The packet
classification can be based on any combination of the fields in the IP
header, including TCP flags, and is performed at wire speed in the
FPGAs on the line modules.
2 The packet is forwarded through the switch fabric to the egress line
module using a specific fabric queue according to its priority.
3 The packet arrives on the egress line module and can be queued before
it is scheduled to be forwarded to the fiber or wire.
Figure 3-24 shows this process.
 IP QoS 3-47
ERX Edge Routers

Packet Flow at Ingress

Ingress
Classify Packet
@ wire-speed

IP Header SA DA SP DP PROT ToS FLAG FRAG

Assign Packet Fabric Queues per

to Fabric Queue Traffic Class

Forward Packet to
Egress Line Card
Egress Line Card

Figure 3-24 Packet Flow in the ERX System at Ingress

Packets can be classified on the ingress and the egress line module. The
packet classification can have a rate-limit profile as the result on ingress
and egress, whereas traffic shaping is performed only on egress.
Figure 3-25 shows packet flow in the ERX system at Egress.

Packet Flow at Egress

Switch Fabric / Fabric Queues

Classify Packet
@ wire-speed

IP Header SA DA SP DP PROT ToS FLAG FRAG

Queue Packet Queues per

per Traffic Class IP Interface

Packet Scheduling

Egress

Figure 3-25 Packet Flow in the ERX System at Egress

3-48 CHAPTER 3
Software Overview

The actual packet queuing and scheduling is done in the ASICs on the
line modules, including traffic shaping. Each ASIC-based line module
supports up to 32,000 queues.

Traffic Classes
The ERX system supports up to eight traffic classes including several
low-latency classes, a low-loss class, and a best-effort class. A traffic class
characterizes a specific QoS profile such as low latency in the chassis.
The class is mapped onto fabric queues in the switch fabric and IP
interface queues on the egress line module. In compliance with the
DiffServ model, the ERX system accommodates the concept of
expedited and assured forwarding. Traffic classes conforming to
expedited forwarding result in strict-priority queues. Packets in
strict-priority queues have precedence over all other packets, no matter
when they arrive.
Note that a strict-priority queue can be traffic-shaped and thus
throttled back in bandwidth, so it does not take up all the bandwidth
available on the physical port.

Scheduler and QoS Profile

Egress queues are served by a three-level hierarchical scheduler, shown
in Figure 3-26, that is running a weighted round robin (WRR)
algorithm to provide weighted fair queuing (WFQ). The scheduler
comprises scheduler nodes that can be attached to:
• Physical layer 2 interface; for example, ATM PVC on 4-port OC3
(ATM) modules and VLAN on GE (first-level scheduler)
• IP interface (second-level scheduler)
• Traffic class or queue (third-level scheduler)
The scheduler node determines the bandwidth allocated to a queue or
interface. Each level can have a specific configuration. Parameters are:
• Relative weight—how often a queue is selected relative to
others—determines minimum rate
• Shaping rate determines maximum rate
If a queue is empty, the relative weight is automatically recalculated and
applied across the remaining queues of the same scheduler level.
The scheduler profile, which describes the characteristics of the
scheduler node, is one part of the QoS profile. The other part is the
 IP QoS 3-49
ERX Edge Routers

queue profile, which describes the buffer allocated to a specific queue.

Configurable parameters are:
• Queue length (buffer)
• Color threshold
• Traffic shaping

1 11 Mbps
2 23 Mbps
IP #1 1 34 M
bps

1 9 Mb
1
ps
VC #1 2
2
IP #2 2 69 Mbp
s 10
3M
bp
ps s
4 34 Mb
OC-3
6 Mbps
1 s
2 IP #3 1 17 M bp
11 Mbps bps
52
M Physical Port
Level
1 5 Mbps VC #2 1
ps
2 34 Mb
2 IP #4
ps
4 20 Mb

3rd Level Scheduler 2nd Level Scheduler 1st Level Scheduler

(Traffic Class ) (IP Interface) (L2 – Sub Port Level) - Best Effort
- Low Loss
- Low Latency
- Low Latency & Jitter

Figure 3-26 Three-level Hierarchical Scheduler

The QoS profile is attached to an interface, including:

• Serial, ATM, POS, ETH
• VC (ATM, FR), VLAN
• IP, L2TP, L2F, MPLS, tunnels
• PPP, PPPoE, ML-PPP, ML-FR
More than one QoS profile can be configured per interface using
precedence rules.

QoS Support for MPLS

The EXP field (bits) of an MPLS shim header can be used to classify
MPLS frames and map them onto the corresponding traffic classes. The
assignment of EXP bits to traffic classes is configurable in the ERX
system. In case of label stacking, the outer label determines the traffic
3-50 CHAPTER 3
Software Overview

class and therefore the quality of service. If a label gets popped, then the
original EXP bits are preserved to apply the originally intended service
quality. Every LSP can have its own set of queues reflecting different
traffic classes. In case of traffic-engineered LSPs, the queue profile is
automatically set to match the TE parameters and constraints.

Congestion and Backpressure

Usually, the egress line modules and switch fabric are potential points of
congestion. The ERX system is a high aggregation router; it has
thousands of interfaces and potentially tens of thousands of queues per
line module. Some of these queues may be empty; others may be full.
The knowledge of the queue status is local. A decision on dropping
packets because a queue is saturated must be made as close to the egress
interface as possible because a packet destined for a saturated queue is
dropped on the egress line module and not before (no backpressure is
applied here). Mechanisms such as WRED and RED can help to
reduce the saturation of queues.
Theoretically, the ERX switch fabric (fabric queues) can be congested,
but the fairness of draining packets between ingress line modules into a
single egress line module is guaranteed by:
• At least one fabric queue per ingress-egress line module pair.
• WRR fabric scheduler provides fairness among fabric queues
coming from different ingress line modules and destined for the
same egress line modules.
• Each fabric queue representing a certain traffic class can carry
different fabric scheduler weights (low latency versus best effort).
Each line module is drained at less then 1 Gbps, making congestion
highly unlikely. In case of a congested fabric queue, backpressure is
applied between the fabric queue and the ingress line module (IFA);
that is, packets are buffered or dropped at ingress.

QoS Feature Summary

Table 3-2 lists the QoS features supported on the ERX system.

Table 3-2 QoS Features Supported on the ERX System

Feature Offered
All QoS features mentioned earlier yes
Full packet classification at wire-speed
 IP QoS 3-51
ERX Edge Routers

Table 3-2 QoS Features Supported on the ERX System (continued)

Feature Offered
Rate-limiting at wire-speed per IP flow
Traffic shaping (per subscriber) per queue
Traffic classes (EF/AF) up to 8
Queue assignment at wire-speed per subscriber
Queue assignment per subscriber and traffic class
Hardware support through ASICs and FPGAs
Number of queues per line module 32,000
Fabric queues 1,200 (T x N2)
Hierarchical schedulers 3 levels
Scheduling WRR, WFQ

Benefits Provided By the ERX System

The ERX system QoS features provide the following benefits:
• Tens of thousands of queues at the edge
• Queue per subscriber and per IP interface
• Fairness between subscribers
• Rate control per IP interface
• Assured bandwidth per subscriber
• Configurable amount of loss
• Wire rate
• No performance degradation

Application Real-time Audio and Video

Scenarios With Figure 3-27 shows a real-time audio and video application using the
the ERX System ERX system. This application provides:
• Real-time video (TV) over DSL/FTTH plus Internet access
• TV (video) is distributed via multicast and not impacted by Internet
access
• 2 queues per subscriber including traffic shapers:
> Strict-priority queue (low latency traffic class); for example,
shaped to 5 Mbps
> Best-effort queue
> Scheduler nodes are attached to IP interface and traffic class
3-52 CHAPTER 3
Software Overview

Real-time Video and Internet Surfing

Real- time Video Queue

Internet Access Queue
Set- top
Box

User 1

Core
Access User N Core AOL
AOL Acquires
Acquires Time
Time Warner
Warner
Set- top After
After FCC
FCC Approval
Approval

Box View
View the
11 hour
the
hour clip
clip

ERX - BRAS

Figure 3-27 Real-time Audio and Video Application

Guaranteed Bandwidth Services

Using the DiffServ model, Figure 3-28 shows how bandwidth is
guaranteed for different subscribers. This application has the following
characteristics:
• Business versus residential users.
• In case of a congestion business users have priority (for example,
100:1).
• Each subscriber has more than one queue (for example,
strict-priority and best-effort queue).
• Scheduler nodes attached to subport level (for example, VC), IP
interface, and traffic class.
• Scheduler weight at IP interface and traffic class (queue) level are
equal. At subport level the queues of business customers are selected
100 times (100:1) more often than the queues of residential
customers.
 IP QoS 3-53
ERX Edge Routers

Differentiated Services

VoIP Queue Application Queue

Scheduler weights,
at VC level ERX

100 User 1

Core
Access User N Core AOL
AOL Acquires
Acquires Time
Time Warner
Warner
1 After
After FCC
FCC Approval
Approval

View
View the
the
11 hour
hour clip
clip

Streaming Queue

Figure 3-28 Differentiated Services for Business Customers Versus Residential

Customers

Media Gateway Aggregation

Figure 3-29 shows packetized voice over routed networks, which have
the following characteristics:
• Media gateway (M-GW) with packetized voice (VoIP-GW) plus
dial-up traffic (NB – RAS).
• ERX edge router aggregating multiple media gateways.
• n> 3 queues per media gateway (for example, OC-3 ports).
• Strict priority queue for VoIP payload (low latency and jitter) plus
traffic shaper (100 Mbps).
• Low-loss queue for VoIP signaling and VPN traffic (49 Mbps).
• Best-effort queue (1 Mbps).
• Scheduler nodes are attached to the port level; queues carry
different weights.
3-54 CHAPTER 3
Software Overview

Packetized Voice over Routed Networks

VoIP Payload Queue Voice Signaling Queue

ERX
VoIP - GW
M- GW 1
VoIP - GW
Core
NB - RAS
M- GW N

NB - RAS

Media-GW Best- effort Queue

Figure 3-29 Packetized Voice Over Routed Networks

Policy Management
Policy management allows service providers to implement packet
forwarding and routing specifically tailored to their customers’
requirements. Using policy management, customers can implement
policies that selectively affect packets.
Policy management provides the following types of services:
• Policy routing – directs packet flow to a destination port without a
route-table lookup
• Packet filtering – marks or drops packets conforming to a classifier
control list
• Packet forwarding – forwards packets that match a policy list
• Packet logging – allows you to log a classified packet flow
• QoS classification and marking – processes packets outside the
context of the system
• Rate limiting – enforces line rates below the physical port line rate
and provides rate limiting on a packet flow conforming to a classifier
control list. Packets that do not fit the profile can be marked or
dropped.
• RADIUS policy definitions – allows you to configure a policy that
consists of Filter/Forward rules based on classified packet flows
• Traffic shaping – allows you to queue packets and transmit them at a
specified rate
 Policy Management 3-55
ERX Edge Routers

Policy Lists The main tool for implementing policy management is the policy list. A
policy list is a set of rules that can affect a packet. A rule is a policy
command optionally combined with a classification.

Classifier Control Lists

A classification is specified by a classifier control list. Classifier control lists
are used in classifying packets arriving on an interface so that different
actions can be applied, based on which classifier control list the packet
matches.
A classifier control list defines the values of IP packet header fields used
for classification. The system applies a list of mask and match clauses to
the IP header of a packet. The system supports 32 unique classification
ranges per policy list.
The ERX system supports the following types of classifier lists:
• Precedence – matches the value of the precedence bits in the ToS
byte of the IP packet header
• Protocol number – matches a protocol to a protocol number
• IP – matches IP protocol attributes such as source and destination IP
address and IP mask
• ICMP – matches ICMP attributes such as source and destination IP
address and IP mask, ICMP type and code
• IGMP – matches IGMP attributes such as source and destination IP
address and IP mask, and IGMP type
• TCP – matches TCP attributes such as source and destination IP
address and IP mask, and source and destination TCP operator and
port
• UDP – matches UDP protocol attributes such as source and
destination IP address and IP mask, and source and destination UDP
operator and port

Rules
Rules are created when a user specifies a policy command or combines
policy commands and classifier control lists, or creates a rate-limit profile.
These rules become part of a policy list that is attached to an interface
as either an input or output policy. The ERX system implements the
rules in the policy list associated with the interface.
Figure 3-30 shows how a policy list is constructed.
3-56 CHAPTER 3
Software Overview

tiered12MB
AcmeCompanyUDP
hardlimit9MB
XYZCorpIGMP
hardlimit3MB XYZCorpICMP

Database

filterForHighSecurity
Rate Limit Profiles Classifier Control Lists
routeForAcmeCompany
routeForXYZCorp
next-interface action classification
Rule 1
next-hop
Rule 2
filter Rule 3 Rule = Action + Classification

forward
action
rate-limit-profile
Rule n
mark
Policy Lists
log

Policy Action Commands

Figure 3-30 Constructing a Policy List

Rate-Limit Profiles
Rate limiting is the process of limiting either a classified packet flow or
source interface at a configured rate that is less than the physical rate on
the port. When a policy list is created, a rule can be created that has a
rate limit for an action.
A rate-limit profile is a set of bandwidth attributes and associated
actions. Rate-limit profile attributes are:
• Committed rate – target rate for the traffic that the policy list covers
• Committed burst – amount of bandwidth allocated to
accommodate bursty traffic
• Peak rate – amount of bandwidth allocated to accommodate excess
traffic flow over the committed rate
• Peak burst – amount of bandwidth allocated to accommodate bursty
traffic in excess of the peak rate
• Committed action – policy action (drop, transmit, or mark) if traffic
flow does not exceed the committed rate
• Conformed action – policy action (drop, transmit, or mark) if traffic
flow exceeds the committed rate but remains below the peak rate
 Dynamic Interfaces 3-57
ERX Edge Routers

• Exceeded action – policy action (drop, transmit, or mark) if traffic

flow exceeds the peak rate
• Committed mark value – sets the value of the type of service (ToS)
byte in the IP packet header when the committed action is set to
mark and the traffic flow does not exceed the committed rate
• Conformed mark value – sets the value of the ToS byte in the IP
packet header when the conformed action is set to mark and the
traffic flow exceeds the committed rate but remains below the peak
rate
• Exceeded mark value – sets the value of the ToS byte in the IP
packet header when the exceeded action is set to mark and the
traffic flow exceeds the peak rate
• Mask value – mask of specific bits in the ToS byte to mark

Dynamic Interfaces
Dynamic interfaces are created through some external event, typically
through the receipt of data over a lower-layer link, such as an ATM
virtual circuit (VC). In contrast, each layer of a static interface is created
and configured through an existing configuration mechanism such as
CLI or SNMP. Dynamic interface layers are created based on the
packets received on the link and can be configured through:
• RADIUS authentication
• Profiles
• A combination of RADIUS authentication and profiles
Unlike static interfaces, dynamic interfaces are not restored through
nonvolatile storage (NVS) after a reboot.
The ERX system software currently supports the following types of
dynamic interfaces:
• IP over ATM (IPoA)
• IP over PPP over ATM
• IP over PPPoE over ATM
• IP over Bridged Ethernet over ATM
3-58 CHAPTER 3
Software Overview

Autodetection The ERX system software performs a process called autodetection, also
referred to as autosensing, to determine the layers of each dynamic
interface. Autodetection is done by conditionally constructing interface
layers based on the encapsulation type of the incoming packet.
Unlike static interfaces, which always allocate system resources upon
creation, autodetection uses system resources only on demand based on
what is detected in the incoming packet. Static interfaces always
consume system resources, even when the interface is quiescent.
Dynamic interfaces, however, are created as a result of traffic on the
interface. Dynamic interfaces may also be dynamically deleted without
your intervention, thereby allowing any consumed system resources to
be returned.

RADIUS RADIUS helps protect your network against unauthorized access. To

Authentication achieve such protection, RADIUS clients running on your ERX
system send authentication requests to a central RADIUS server.
Dynamic interfaces can be configured through RADIUS
authentication.
When a packet is received, the authenticating interface (either PPP or
ATM 1483) establishes a session with RADIUS and passes the
RADIUS server the username and password. For dynamic IPoA, the
RADIUS username and password are obtained from the information
specified by a CLI command. The RADIUS authentication server
returns a grant or deny indication. If authentication is granted, the
RADIUS attributes are returned, a user login is created, and the
dynamic interfaces are configured from the RADIUS attributes.
ATM 1483 interfaces may receive configuration data from the
RADIUS server in the form of traffic-shaping parameters.
Any changes made to a RADIUS configuration for a given dynamic
interface do not take affect until an existing dynamic interface
configured from this RADIUS entry is recreated—that is, deleted and
then dynamically created.

Profiles Dynamic interfaces can also be configured by profiles. A profile is a set

of characteristics that act as a pattern. This pattern can then be
dynamically assigned to interfaces. By using a profile, you reduce the
management of a large number of interfaces by applying a set of
characteristics to multiple interfaces.
 B-RAS Support 3-59
ERX Edge Routers

When you are configuring a large number of interfaces with the same
attributes at the higher layers, you can use a profile to apply all the
common attributes to each layer. This action comprises one or more
dynamic layers of the interface column. Once the static lower layers are
defined, a profile is assigned to the highest static layer of the interface
column.
You define profiles using CLI commands similar to the ones used to
configure static interfaces. Profiles can be configured for IP, PPP, or
PPPoE interfaces.

B-RAS Support
A separate application for the ERX system aggregates the output from
DSLAMs, provides PPP session termination, enforces QoS policies, and
routes traffic into the backbone. This application is called Broadband
Remote Access Server (B-RAS).
For service providers to deploy xDSL services economically, they reuse
OSS structures that are already in place for dial service offerings.
Therefore, the system supports a number of dial access–oriented
protocols to accommodate this application.

B-RAS Features The system features that are specifically supported for B-RAS include:
• Enhanced PPP
> RFC 1661 – The Point-to-Point Protocol (PPP) (July 1994)
> RFC 1662 – PPP in HDLC-like Framing (July 1994)
> RFC 1332 – The PPP Internet Protocol Control Protocol (IPCP)
(May 1992)
> RFC 1877 – PPP Internet Protocol Control Protocol Extensions for
Name Server Addresses (December 1995)
• Password Authentication Protocol (PAP) – RFC 1472 – The
Definitions of Managed Objects for the Security Protocols of the
Point-to-Point Protocol (June 1993)
• Challenge Handshake Authentication Protocol (CHAP) – RFC
1472 – The Definitions of Managed Objects for the Security Protocols of
the Point-to-Point Protocol (June 1993)
• Domain Parsing based on destination domain (for example,
@mu.edu, @company1, @isp1)
3-60 CHAPTER 3
Software Overview

• RFC 2131 – Dynamic Host Configuration Protocol (March

1997)—where the ERX system is a DHCP proxy client
• IP address pooling
• PPP/Ethernet emerging specification
• Support for 32,000 IP interfaces in a single system
• L2TP access concentration to initiate tunnels from the system
See also the following RADIUS RFCs:
• RFC 2865 – Remote Authentication Dial In User Service (RADIUS)
(June 2000)—where the ERX system is an authentication client
• RFC 2866 – RADIUS Accounting (June 2000)—to support
accounting
• RFC 2867 – RADIUS Accounting Modifications for Tunnel Protocol
Support (June 2000)

B-RAS Protocol Figure 3-31 shows a number of protocols the system supports for
Support B-RAS applications. These include:
• IP/PPP/ATM
• IP/PPP/Ethernet/ATM
• IP/PPP/FR
• IP/PPP/Ethernet/FR

IP

L PPP L
2 2
T T
P PPPoE P

ATM FR

Physical (SONET, DS3, E3)

Figure 3-31 B-RAS Protocol Support

This protocol support allows service providers to install the ERX

system as a central site router that supports the encapsulation schemes
 B-RAS Support 3-61
ERX Edge Routers

from a wide variety of CPE xDSL devices. The signal support is

provided over the OC3, T3, and E3 modules.

B-RAS Data There are several tasks that the system must accomplish for subscribers
Flow to establish their connections:
• The subscriber must be authenticated. The system can use the
RADIUS authentication with PAP and CHAP to allow the
subscriber to be verified.
• The connection must be assigned an IP address. The system
supports IP address assignment for the end-user through DHCP,
local IP pools, and RADIUS.
• The PPP session must be terminated. The system supports all
varieties of xDSL encapsulation schemes to support all types of
xDSL modems.
• Subscribers are matched to their routing and/or QoS policy. The
system can match subscribers via the ERX classification features or
via RADIUS attributes. Either of these methods can associate the
destination route and the level of service quality with the subscriber
session. For example, with RADIUS, session timeout and idle
timeout values can be associated with the subscriber session to
support oversubscription by the service provider; or, to
accommodate wholesaling applications, subscriber sessions can be
directed to a specific virtual router.
• Accounting data must be collected. The system supports RADIUS
accounting to allow the service provider to bill users based on call
duration.
The ERX system offers a contrast to current solutions that require
multiple separate network elements to provide B-RAS service. With
comprehensive support for B-RAS features combined with the
carrier-class product design and strong routing protocol support, the
system gives service providers a single network element that can
terminate large numbers of xDSL sessions, authenticate them, apply
QoS policies, and route them into the core network.
3-62 CHAPTER 3
Software Overview

Zero-Touch The system supports a unique provisioning scheme that can provision a
Provisioning subscriber connection without operator involvement. This scheme is
handled by:
• Autodetection of the incoming protocol
• Autoassignment of the service profile via the ERX system or
RADIUS
• Autocreation of the IP interfaces
All this is achieved independent of the protocol type, allowing for
streamlined operation and cost savings.

RADIUS Server RADIUS is a distributed client/server system that protects networks

Support against unauthorized access. RADIUS clients running on an ERX
system send authentication requests to a central RADIUS server.
The central RADIUS server contains all the required user
authentication and network access information. The RADIUS server is
configured and managed by a RADIUS administrator.
The RADIUS client in the ERX system uses the router ID of the
virtual router as the source IP address regardless of the interface from
which RADIUS packets are sent.
RADIUS provides three distinct services:
• Authentication – determines that a user may access a specific service
or resource
• Authorization – associates connection attributes or characteristics
with a specific user
• Accounting – tracks service use by subscribers

Basic Client-to-Server Interaction

The ERX system supports configuration of up to ten authentication
and accounting servers. The order in which a server is configured
determines which servers the system submits requests to on behalf of
clients. The first configured authentication or accounting server is the
primary authentication or accounting server, the next the secondary,
and so on.
 B-RAS Support 3-63
ERX Edge Routers

The ERX system offers two options by which servers are accessed:
• Direct – treats the first configured server as primary for all users
• Round-robin – treats the first configured server as a primary for the
first request, the second server configured as primary for the second
request, and so on. When the system reaches the end of the list of
servers, it starts again at the top of the list.
Each authentication and accounting server is capable of handling a
maximum of 255 outstanding requests. Once that number is reached,
the system submits the request to the next configured server.
The ERX system allows the service provider to specify configuration
parameters for managing RADIUS client to server interaction:
• Maximum number of times the system retransmits a RADIUS
packet to an authentication or accounting server
• Interval (in seconds) before the system retransmits a RADIUS
packet to an authentication or accounting server
• Maximum number of outstanding requests allowed to a RADIUS
server
• Amount of time (in minutes) that a RADIUS server is marked as
unavailable if a request times out for the configured retry count
• Accounting interval between updates
• Algorithm for RADIUS server access (direct or round-robin)
• Encryption of the primary, secondary, and tertiary RADIUS
authentication server secret
• Enabling of the duplicate accounting records feature to specify if
duplicate records are sent to the RADIUS accounting server for a
virtual router
• Collection of RADIUS statistics
The interaction between the ERX system and the RADIUS server is
powerful and can be used by the service provider to centralize all
subscriber profiles. For example, the RADIUS server can return all
information required to start the subscriber session, including IP
address, service profile, and authorization. This interaction streamlines
operations across multiple ERX systems.
3-64 CHAPTER 3
Software Overview

Non-PPP Equal Access Support

You can configure the system to allow remote access via non-PPP equal
access. This configuration is particularly useful for broadband (cable and
DSL) environments or environments that use Bridged Ethernet over
ATM.
Using PPP in these environments requires a PPPoE client for each
subscriber’s computer. Using non-PPP equal access in these
environments requires no additional software for subscribers’
computers, because the system provides IP addresses to the computers
via Dynamic Host Configuration Protocol (DHCP). It is easier for
network operators to support a central system than to maintain software
on subscribers’ computers.
Non-PPP equal access requires the use of the following key
components:
• The system’s DHCP local server
• Either the Unisphere Networks Service Selection Center (SSC) or
the system’s HTTP local server
• The system’s authentication, authorization, accounting, and address
assignment utility (AAAA)
• A RADIUS server

DHCP Local The system offers an embedded DHCP server, known as the DHCP
Server local server. The system does not function as an independent DHCP
server; the sole purpose of the DHCP local server is to enable non-PPP
equal access. The DHCP local server complies with RFC 2131 –
Dynamic Host Configuration Protocol (March 1997).
The DHCP local server performs the following functions:
• Assigns a temporary IP address, known as the token IP address, which
enables the subscriber to access the SSC or the HTTP local server.
• Communicates with the SSC or the HTTP local server.
• Communicates with the RADIUS server.
• Assigns an IP address with a long lease time, known as the enduring
IP address, which allows the subscriber to access services.
 Non-PPP Equal Access Support 3-65
ERX Edge Routers

SSC SSC is a component of the Unisphere Management Center (UMC)

software. SSC provides a Web-based interface that allows subscribers to
access services, such as the Internet, an intranet, or an extranet. For
more information about SSC, see Chapter 4, Element and Network
Management.
The SSC performs the following functions:
• Allows subscribers to log in via a Web browser.
• Communicates login parameters to the system via the Common
Open Policy Service (COPS) interface.
• Emulates PPP authentication functions.

HTTP Local The system offers an embedded Web server, known as the HTTP local
Server server, which complies with RFC 2616 – Hypertext Transfer Protocol –
HTTP/1.1 (June 1999). You can configure one HTTP local server per
virtual router.
The sole purpose of the HTTP local server is to allow user login and
authentication without the SSC. The HTTP local server performs the
same functions as the SSC.

The Connection The following sample sequence describes how the subscriber connects
Process to the network for the first time. Figure 3-32 illustrates the process.
1 The subscriber’s computer boots and issues a DHCP request.
2 The DHCP local server on the system grants the subscriber a token IP
address—a unique, private address with a very short lease time in the
range 10–30 seconds.
Since the lease time is very short, the subscriber’s computer repeatedly
requests renewal of the token IP address, and the DHCP local server
repeatedly renews the address. This process keeps the subscriber’s
connection to the network active until the subscriber’s computer
receives an enduring IP address.
The system maintains a host route that maps the token IP address to the
system’s interface associated with the subscriber’s computer.
3 The system installs a policy that:
• Directs all traffic, with the exception of the DHCP renewal
requests, from the subscriber to the SSC.
• Specifies a host route for return traffic.
3-66 CHAPTER 3
Software Overview

4 The subscriber logs in to the SSC, which matches the user name and
password to the subscriber’s service profile.
The service profile includes information such as the selected ISP, the
QoS, and the virtual router.
5 The SSC sends the subscriber's domain and private address to the
RADIUS server via the DHCP server.
6 The RADIUS server authenticates the subscriber and returns the
authentication to the DHCP local server.
7 When the subscriber's computer next requests an IP address, the
DHCP local server revokes the token address, forcing the subscriber’s
computer to issue a DHCP broadcast.
8 After standard DHCP negotiations, the DHCP local server supplies an
enduring IP address to the subscriber’s computer from the address pool
configured for ISP Boston.
The system maintains a host route that maps the enduring IP address to
the system’s interface associated with the subscriber’s computer.
9 The subscriber’s computer retains the enduring IP address until the
subscriber switches off the computer.
10 The system modifies the subscriber’s policy to:
• Route all traffic, except that addressed to the SSC, from the new IP
address to the correct domain.
• Route traffic addressed to the SSC.
• Specify a new host route for return traffic.
This policy maintains the subscribers’ connections to the SSC so that
access to other services is available.
 L2TP Support 3-67
ERX Edge Routers

RADIUS
Server
ERX System

3
Subscriber’s PC
1 4 DHCP Local 3 4
Server AAAA
2
1 1 4
2
3 3 Token
Address Local Address Pools
SSC SSC Client
Pool ISP Boston
ISP Chicago
1
ISP Cleveland
HTTP Local 3
Server

1 Subscriber’s PC receives and requests Token IP address.

2 Subscriber logs in via SSC or HTTP Local Server.

3 RADIUS server authenticates subscriber.

4 Subscriber’s PC receives enduring IP address.

Figure 3-32 Non-PPP Equal Access Via the ERX System

L2TP Support

Related to B-RAS is the Layer Two Tunneling Protocol (L2TP). L2TP

allows you to encapsulate layer 2 packets, such as PPP, for transmission
across a network. In an L2TP relationship, an L2TP Access
Concentrator (LAC) forms a client-server relationship with a
destination, known as an L2TP Network Server (LNS), on a remote
network.
3-68 CHAPTER 3
Software Overview

L2F Support
Layer Two Forwarding (L2F) provides a method for virtual dial-up
service over the Internet. The traditional method for a remote user to
access a company’s network is through remote access equipment that is
directly attached to the corporate network. This method requires a
significant investment in equipment and support in addition to the cost
of telephone charges for remote workers calling into the access
equipment.
By employing L2F, an Internet service provider (ISP) can provide local
access for remote workers and forward their data traffic through a
tunnel to the corporate network. This method allows a company to
outsource the investment in remote access equipment to the ISP, while
retaining full control over access to the corporate network. In
particular, L2F allows leveraging multiple protocols and private
addressing across the existing Internet infrastructure.
In the Unisphere implementation of L2F, the ERX system, configured
as a Network Access Server (NAS), receives packets from a remote
client and forwards them through a tunnel to a home gateway on a
remote network.
 VLAN Support 3-69
ERX Edge Routers

VLAN Support
The ERX system supports VLANs (IEEE 802.1q) on Fast Ethernet and
Gigabit Ethernet interfaces. IEEE 802.1q describes two key Ethernet
fields that have been added to the Ethernet frame to identify and
prioritize traffic: VLAN ID (virtual LAN identifier) and user priority
values (802.1p).

IEEE 802.1q Header/Tag

(4 bytes)

PRE SF DA SA TPI P C VI L/F Data CRC

Octet 1 Octet 2 Octet 3 Octet 4

1 2 3 4 5 6 7 8
C
Ethernet-encoded TPID F
I

802.1p VLAN ID
(3 bits) (12 bits)

TPID – Tag Protocol Identifier User Priority VLAN Identifier

(Frame contains 802.1q data) (QoS) (Frame membership)

Figure 3-33 Ethernet Frame with 802.1q Fields (VLAN)

Ethernet frames using this standard can be tagged and viewed in the
same way that ATM VCs (VPI/VCI) are represented on an ATM
circuit. When an Ethernet frame is sent over a shared medium (for
example, a GE line), it is logically defined as belonging to a specific
virtual LAN and provisioned in the same way as a PVC on an ATM
circuit. The Tag Protocol Identifier (TPID) in the Ethernet header
indicates that this Ethernet frame contains 802.1q data. The VLAN ID
indicates the virtual LAN (virtual circuit) to which this frame belongs.
The three bits in the 802.1p field can be used to determine the priority
of this frame.
On a given physical link, Ethernet frames may be tagged or untagged.
The VLAN ID in the 802.1q tag explicitly identifies the VLAN for
tagged frames; the ID may be 0. Untagged frames are implicitly in
VLAN 0, which is considered to be the default VLAN. This
3-70 CHAPTER 3
Software Overview

implementation is different from ATM, where all frames are required to

have an explicit VPI/VCI.
The VLAN ID field is 12 bits, allowing 4096 VLAN IDs. Tagged
frames are identified by the value 0x8100 in the Ethernet protocol type
field; the actual protocol type of the frame then follows the tag. Some
attached devices may not accept 802.1q-tagged frames, and therefore
can reside only in VLAN 0.
Conversely, some devices may accept only tagged frames, requiring that
even frames in VLAN 0 be tagged. Ports that have been explicitly
added to VLAN 0 will tag frames unless the untagged option is
specified. Ports that do not have VLANs configured will not tag frames.
On ingress to a VLAN port, the Ethernet protocol type field of a frame
is examined to determine if it is tagged. If so, the VLAN ID is extracted
from the tag and the actual protocol type field following the tag is used
to identify the protocol. If not, the frame is in the default VLAN, and
the type field is used to identify the protocol.
On egress, a frame destined for the default VLAN may be sent
untagged or tagged (depending on whether the untagged option was
specified). A frame destined for any other VLAN is sent tagged.

Interface Modes Ethernet interfaces are configured to operate in one of the following
modes, depending on the combination of protocol and VLAN usage:
• Single protocol non-VLAN (that is, IP only)
The Ethernet interface supports only one upper-layer protocol
interface (without VLANs). Such support is backward compatible
with the initial implementation of Ethernet interfaces.
• Single protocol VLAN (that is, VLANs and IP)
The Ethernet interface supports a single upper-layer protocol on
each of one or more VLANs.
• Multiprotocol VLAN (that is, VLANs, PPPoE, and IP)
The Ethernet interface supports multiple upper-layer protocols, one
upper-layer interface per protocol, on each of one or more VLANs.
The first upper-layer interface configured on an Ethernet interface
determines the mode. Switching to a different mode requires first
removing the entire stack above the Ethernet interface. The supported
upper-layer protocols are IP and PPPoE. Figure 3-34 shows the
interface stacks for the different modes.
 VLAN Support 3-71
ERX Edge Routers

Single Protocol Single Protocol Multi-Protocol

No VLAN VLAN VLAN
FastEth 2/0 FastEth 2/0.1 FastEth 2/0.2 FastEth 2/0.1 FastEth 2/0.1.1 FastEth 2/0.1.2
IP IP IP IP IP IP

PPP PPP

PPPoE

VLAN 100 VLAN 200 VLAN 100 VLAN 200

Ethernet Ethernet Ethernet

FastEth 2/0 FastEth 2/0 FastEth 2/0

Figure 3-34 Interface Stacks for VLANs

3-72 CHAPTER 3
Software Overview
Element and Network
Management

This chapter explains Unisphere’s element and network management

features for the ERX edge routers.

Topic Page
Network Management Overview 4-1
Managing the ERX System 4-2
SNMP Features 4-4
Command Line Interface 4-9
Collecting Bulk Statistics 4-12
Security Features 4-12
NMC-RX Overview 4-14
UMC Application Overview 4-22

Network Management Overview

Management of the edge network is a key and critical function for a
profitable, competitive network. The ERX system offers service
providers both element-specific and network-wide management
control. Element-specific control allows a service provider to manage a
single ERX system. Network-wide control allows the service provider
to manage a set of ERX edge routers and other edge elements to create
and apply global policies.
At its foundation, the ERX system supports standard-based methods of
management access, including SNMP and CLI. All management
functional areas (MFAs) are supported, including configuration, fault
handling, monitoring, and statistics gathering. Multiple types of
4-2 CHAPTER 4
Element and Network Management

management access are supported to ensure that service providers can

integrate the system into their operations support system (OSS)
environments. Value-added management services, such as customer
network management (CNM), are also supported. The strength of the
system’s management capabilities makes it easy to configure, deploy, and
maintain new IP edge services.

Managing the ERX System

There are a number of ways to manage ERX systems so that service
providers can control the element in the best manner for their
operational environment. Figure 4-1 shows a number of applications
and access methods for the system.

NMC-RX Policy Server Third-Party and

(RADIUS, DHCP, SSC) ISP Apps/OSSs
(OpenView, Netcool)

dB
Applications

Command
RADIUS Bulk DHCP
Line/Scripts SNMP
SNMP COPS Stats
Traps
Sets/Gets
Access Methods

ERX-1400
ERX-700

Any IP Path

Elements

Figure 4-1 Management of ERX Edge Routers

Starting at the bottom of Figure 4-1 with the ERX edge router itself,
the ERX system can be managed in several ways:
• Via standard SNMP MIB variables. This is the method by which
the NMC-RX network management application communicates
with the ERX system. SNMP traps and SNMP statistics are also
issued by the ERX system and can be sent to multiple host
destinations.
 Managing the ERX System 4-3
ERX Edge Routers

• Via a Cisco-like command line interface (CLI). Service provider

operators who are familiar with the Cisco CLI can configure and
manage the ERX system immediately with no additional training.
In addition, scripts developed for Cisco routers can be used with the
next-generation ERX edge router.
• Via a Common Open Policy Server (COPS). This interface allows
the system to be controlled by other applications with a reliable
delivery mechanism for real-time configuration changes. The
Unisphere Service Selection Center (SSC) uses COPs to
communicate with the ERX system.
• Via Bulkstats. The ERX system has the ability to collect and store
statistics in an ASCII file that can be retrieved from the system via
FTP. This allows for efficient gathering of statistical information,
eliminating the polling overhead of SNMP statistics retrieval. You
can FTP the file to a server as often as every five minutes or only
once per day.
A number of applications can control the ERX system:
• NMC-RX application – A network management application that
delivers a graphical way to manage and control a network of ERX
and CRX systems. It can dramatically reduce provisioning times for
service provider operators who prefer GUI-based interfaces. It also
delivers advanced management control, allowing service provider
operators to manage ERX and CRX systems logically, by customer
and service, in addition to managing by the standard physical level.
• Policy servers – Servers such as RADIUS or the Unisphere
Management Center (UMC) Service Selection Center (SSC)
product can dynamically configure the ERX system in response to
customer input. These types of servers are especially valuable in
Broadband Remote Access Server (B-RAS) applications, where
subscriber configurations need to involve minimal operator
assistance. Interaction with these servers allows an ERX system to
provision individual subscribers dynamically, with “zero touch” by
the operators after the initial system configuration.
• Operations support systems (OSSs) – The NMC-RX application
has an open architecture that allows it to interface with existing
OSSs. Its northbound Common Object Request Broker
Architecture (CORBA) and Java Remote Method Invocation
(RMI) interfaces allow information to pass to higher-level
applications seamlessly.
4-4 CHAPTER 4
Element and Network Management

• HP OpenView – The ERX system can be managed via integration

with HP OpenView Network Node Manager, which allows for
icon display and coloring, and fault management. In addition, the
NMC-RX application can be integrated into the OpenView
application for a single management interface to the element.
• Other third-party applications – The ERX system can be managed
by any standards-based, third-party application, such as provisioning,
monitoring, or fault-management tools. There are specific
applications for which the ERX edge router is already integrated,
alleviating this work from the service provider. These include:
Micromuse Netcool for fault management, Quallaby Provisio for
performance management, including generation of reports, and
Orchestream for MPLS VPN management.

SNMP Features
Each ERX system has its own SNMP agent. The agent is located on
the system’s active SRP module. UDP/IP is used for the transport.
The following SNMP features are supported:
• Trilingual support for SNMP Version 1 (v1), Version 2
Community-based (v2c), and Version 3 (v3)
• SNMP control of the system with GET and SET support
• SNMP access control
• SNMP trap management and filtering
• SNMP error statistics
• PDU size support from 484 – 8192 bytes
• 32-bit and 64-bit octet statistical SNMP counter support to handle
high-speed interfaces (such as Gigabit Ethernet and OC12/STM4)
• All SNMP control parameters can be configured through the CLI

RFCs Supported • RFC 1155 – Structure and Identification of Management Information for
TCP/IP-based Internets (May 1990)
• RFC 1157 – A Simple Network Management Protocol (SNMP) (May
1990)
• RFC 1212 – Concise MIB Definitions (March 1991)
• RFC 1215 – A Convention for Defining Traps for use with the SNMP
(March 1991)
 SNMP Features 4-5
ERX Edge Routers

• RFC 1901 – Introduction to Community-based SNMPv2 (January

1996)
• RFC 1902 – Structure of Management Information for Version 2 of the
Simple Network Management Protocol (SNMPv2) (January 1996)
• RFC 1903 – Textual Conventions for Version 2 of the Simple Network
Management Protocol (SNMPv2) (January 1996)
• RFC 1904 – Conformance Statements for Version 2 of the Simple
Network Management Protocol (SNMPv2) (January 1996)
• RFC 1905 – Protocol Operations for Version 2 of the Simple Network
Management Protocol (SNMPv2) (January 1996)
• RFC 1906 – Transport Mappings for Version 2 of the Simple Network
Management Protocol (SNMPv2) (January 1996)
• RFC 1907 – Management Information Base for Version 2 of the Simple
Network Management Protocol (SNMPv2) (January 1996)
• RFC 1908 – Coexistence between Version 1 and Version 2 of the
Internet-standard Network Management Framework (January 1996)
See Security Features later in this chapter for information on
management access to the individual ERX devices.
Each virtual router instance can have a unique SNMP proxy agent to
maintain secure management access between virtual routers.

SNMP Traps The system fully supports SNMP traps. Traps are generated for the
following categories:
• Standard SNMP traps (for example, coldstart, authentication, link
up, link down)
• ERX system-level traps (for example, board insert, board removal,
temperature change)
• Routing protocol traps (for example, BGP-4-specific traps)
Traps issued by the system can be sent to up to eight different IP hosts
simultaneously. Several parameters can be controlled, including the:
• IP address of the host
• Community name to send in the trap message
4-6 CHAPTER 4
Element and Network Management

• SNMP format (v1, v2c, or v3) of the trap

• Categories of traps to be sent (for example, SNMP, system-level,
routing protocol)
These features allow a service provider to assign varied classes of traps to
different service provider network operators, such as all system-level
traps to network operator #1 and all routing-level traps to network
operator #2. Individual traps can also be enabled or disabled for each
ERX system and for each IP host destination. This feature reduces the
number of SNMP traps issued by the system.

SNMP Support Unisphere supports the standard MIBs in the following list on the ERX
system. In addition to standard MIBs, Unisphere supports a wide array
of proprietary MIBs for your system.

ATM MIBs
• RFC 1695 – Definitions of Managed Objects for ATM Management
Version 8.0 using SMIv2 (August 1994)
• ATM Interface Configuration Group
• ATM Interface TC Group
• ATM Interface DS3 PLCP Group
• ATM VCC Termination Group
• ATM AAL5 VCC Group

BGP-4 MIB
• RFC 1657 – Definitions of Managed Objects for the Fourth Version of the
Border Gateway Protocol (BGP-4) using SMIv2 (July 1994)

Ethernet MIB
• RFC 2358 – Definitions of Managed Objects for the Ethernet-like
Interface Types (June 1998)

Frame Relay MIBs

• RFC 2115 – Management Information Base for Frame Relay DTEs
Using SMIv2 (September 1997)
• RFC 2233 – The Interfaces Group MIB using SMIv2 (November
1997)
 SNMP Features 4-7
ERX Edge Routers

Interface MIBs
• RFC 1406 – Definitions of Managed Objects for the DS1 and E1
Interface Types (January 1993)
• RFC 1407 – Definitions of Managed Objects for the DS3/E3 Interface
Type (January 1993)
• RFC 2233 – The Interfaces Group MIB using SMIv2 (November
1997)
• linkUp/Down SNMP trap support – RFC 2233

IP MIBs
• MIB-II
• RFC 1213 – Management Information Base for Network Management of
TCP/IP-based Internets: MIB-II (March 1991)
• RFC 2011 – SNMPv2 Management Information Base for the Internet
Protocol using SMIv2 (November 1996)
• RFC 2012 – SNMPv2 Management Information Base for the
Transmission Control Protocol using SMIv2 (November 1996)
• RFC 2013 – SNMPv2 Management Information Base for the User
Datagram Protocol using SMIv2 (November 1996)
• RFC 2096 – IP Forwarding Table MIB (January 1997)
• RFC 2667 – IP Tunnel MIB (August 1999)

OSPF MIB
• RFC 1850 – OSPF Version 2 Management Information Base
(November 1995)

PPP MIBs
• RFC 1471 – The Definitions of Managed Objects for the Link Control
Protocol of the Point-to-Point Protocol (June 1993)
• RFC 1473 – The Definitions of Managed Objects for the IP Network
Control Protocol of the Point-to-Point Protocol (June 1993)
• RFC 2233 – The Interfaces Group MIB using SMIv2 (November
1997)

RIP MIB
• RFC 1724 – RIP Version 2 MIB Extension (November 1994)
4-8 CHAPTER 4
Element and Network Management

SNMP MIBs
• MIB-II
• RFC 1907 – Management Information Base for Version 2 of the Simple
Network Management Protocol (SNMP v2) (January 1996)

SNMP v3 MIBs
• RFC 2271 – An Architecture for Describing SNMP Management
Frameworks (January 1998)
• RFC 2272 – Message Processing and Dispatching for the Simple Network
Management Protocol (SNMP) (January 1998)
• RFC 2273 – SNMPv3 Applications (January 1998)
• RFC 2274 – User-based Security Model (USM) for version 3 of the
Simple Network Management Protocol (SNMPv3) (January 1998)
• RFC 2275 – View-based Access Control Model (VACM) for the Simple
Network Management Protocol (SNMP) (January 1998)
• SNMP Notification – SNMP-NOTIFICATION-MIB

SONET MIBs
• RFC 1595 – Definitions of Managed Objects for the SONET/SDH
Interface Type (March 1994)
• sonetMediumTable
• sonetSectionCurrentTable
• sonetSectionIntervalTable
• sonetLineCurrentTable
• sonetLineIntervalTable
• sonetPathCurrentTable
• sonetPathIntervalTable

UDP MIB
• RFC 2013 – SNMPv2 Management Information Base for the User
Datagram Protocol using SMIv2 (November 1996)

Unisphere Enterprise MIB

• Boot and dump configuration parameters, diagnostics results for
each slot, software revision, SNMP control, control for interface
creation and deletion (such as the FT1, T1, PPP, Frame Relay [FR],
 Command Line Interface 4-9
ERX Edge Routers

FR subinterfaces, ATM AAL5, and ATM subinterfaces), and virtual

router configuration.

Command Line Interface

The ERX system supports a complete command line interface (CLI) to
support system configuration, monitoring, and troubleshooting. The
CLI has an industry de facto standard look and feel, and requires little, if
any, operator retraining for operators familiar with routing interfaces.
Operator access to the CLI is covered in the Security Features section
later in this chapter.
Following is a set of example configuration commands that could be
used to configure an ATM uplink. (See ERX Physical & Link Layers
Configuration Guide, Chapter 10, Configuring ATM, for the exact
command syntax when configuring the system.)
1 Configure a physical interface.
ERX-0-1-90(config)#interface atm 0/1

2 Configure the subinterface.

ERX-0-1-90(config-if)#interface atm 0/1.20

3 Configure a PVC by specifying the virtual circuit descriptor (VCD),

virtual channel identifier (VCI), the virtual path identifier (VPI), and
the encapsulation type.
ERX-0-1-90(config-if)#atm pvc 10 22 100 aal5snap

4 Assign an IP address and subnet mask to the PVC.

ERX-0-1-90(config-subif)#ip address 192.32.10.20
255.255.255.0

Show commands are also supported. The example below shows the
result displayed for a show atm interface command. (Refer to the
Command Reference Guide for exact command syntax for show
commands.)
Router#>show atm interface atm 3/0
ATM Interface ATM 3/0 is up line protocol is up
IP address is 158.101.112.2 subnet mask is 255.255.0.0
AAL enabled: AAL5, Maximum VCs: 50, Current VCs: 1
VCIs per VPI: 32, MTU Size: 4478
PHY Type: OC3c, Framing SONET, TX clocking: INTERNAL
Loopback: disabled, ILMI Keepalive: enabled (10 seconds)
0 packets input, 0 bytes
4-10 CHAPTER 4
Element and Network Management

0 input errors: 0 CRC, 0 overrun

0 packets output, 0 bytes
0 output errors
0 interface resets

Script The ability to automate device configuration is critical to large service

Capability providers. Automation reduces configuration time and errors by
implementing a consistent process for the operator. The ERX system
offers two scripting functions: the ability to load external CLI scripts
and an innovative, versatile macro language.

External CLI Scripts

External scripts can be referenced by the ERX system to allow
administrators to create and perfect a set of commands and then
consistently use them in standard configurations. These scripts are
ASCII files that contain any number of CLI commands.
Scripts are executed by the operator using a CLI command and can be
stored in NVS on the SRP module or on a network-resident host.
Scripts can also be generated from the existing system configuration
with a show config command. This ability allows the service provider
to capture the existing configuration within the system for duplication
on other systems or for archival storage.
The ERX system’s script function can interpret scripts developed for
Cisco routers to configure the system. This function allows service
providers to use existing scripts developed for a Cisco router with their
new ERX edge router.

Scripting Language
The system supports a powerful internal scripting language that allows
the operator to automate repetitious tasks and create miniprograms to
configure the system. Macros are loaded into the system by the operator
through the CLI and can be run on an ERX system during operation.

Example The following is an example of the system’s scripting capability:

<# atmIf #>
<# slotPort:=env.getline("slot/port?") #>

<# while (vcType != 1 && vcType != 2);

vcTypeStr :=env.getline("VC type (1 = AAL5MUX IP, 2 =
AAL5SNAP)?");
 Command Line Interface 4-11
ERX Edge Routers

vcType := env.atoi(vcTypeStr);
endwhile #>
<# if vcType = 1; vcTypeStr := "aal5mux ip”; else; vcTypeStr
:= aal5snap; endif #>

<# encapRouted:=1; encapBridged:=2; encapPPP:=3 #>

<# while (encapType < encapRouted || encapType > encapPPP );
encapTypeStr :=env.getline(“encapsulation (1 = routed, 2
= bridged, 3 = ppp)?”);
encapType := env.atoi(encapTypeStr);
endwhile #>
<# if encapType = encapPPP #>
<# authNone:=1; authPap:=2; authChap:=3; authPapChap:=4;
authChapPap:=5 #>
<# while (authType < authNone || authType > authChapPap );
authTypeStr :=env.getline(“authentication (1 = None, 2 =
PAP, 3 = CHAP, 4 = PAP/CHAP; 5 = CHAP/PAP)?”);
authType := env.atoi(authTypeStr);
endwhile #>
<# endif #>

<# vpStartStr := env.getline(“Starting VP number?”);

vpStart:=env.atoi(vpStartStr)#>
<# vpEndStr := env.getline(“Ending VP number?”); vpEnd
:=env.atoi(vpEndStr)#>
<# vcStartStr := env.getline(“Starting VC number?”);
vcStart:=env.atoi(vcStartStr)#>
<# vcEndStr := env.getline(“Ending VC number?”); vcEnd
:=env.atoi(vcEndStr)#>

<# loopbackStr := env.getline(“Loopback interface number or

<cr>?”) #>

<# vp := vpStart; while vp <= vpEnd, ++vp #>

<# vc := vcStart; while vc <= vcEnd, ++vc #>
interface atm <#slotPort $ '.' $ ++i;'\n'#>
atm pvc <# i; ' '; vp; ' '; vc; ' '; vcTypeStr;'\n'#>
<# if encapType = encapPpp #>
encap ppp
<# if authType = authPap#>
ppp authentication pap
<# elseif authType = authPapChap#>
ppp authentication pap chap
<# elseif authType = authChapPap#>
ppp authentication chap pap
<# elseif authType = authChap#>
ppp authentication chap
<# endif #>
<# elseif encapType = encapBridged #>
4-12 CHAPTER 4
Element and Network Management

encap bridged1483
<# endif #>
<# if loopbackStr != “” #>
ip unnumbered loopback <# loopbackStr;”\n" #>
<# endif #>
!
<# endwhile #>
!
<# endwhile #>
<# endtmpl #>

Collecting Bulk Statistics

The ERX system offers an efficient data collection and transfer facility
for accounting and performance-monitoring applications. The
Unisphere Networks SNMP MIBs extend the accounting data
collection mechanism defined in RFC 2513 to include support for
connectionless networks.
Service providers need reasonably accurate data about customers’ use of
networks. This data is used for billing customers and must be available
at a customer’s request. Accounting applications based on SNMP
polling models consume significant network bandwidth because they
poll large volumes of data frequently.
Unfortunately, SNMP is not well suited for gathering large volumes of
data, especially over short intervals. The bulk statistics (bulkstats) feature
provides the capability for doing this by avoiding the need for
continuous polling of SNMP statistics. It uses applications known as
collectors to retrieve data. The ERX system then sends collected statistics
via FTP to assigned hosts, known as receivers.
The data is stored in an ASCII file on the system and can be sent to
servers periodically via FTP. The data can then be used by any
third-party application.

Security Features
Operator access to the ERX system is protected by the network
management architecture. Of course, the service provider should
implement other security means, such as physical security or logical
security via firewalls between the outside world and the operations
centers.
 Security Features 4-13
ERX Edge Routers

All ERX management access methods such as, CLI, SNMP, and
NMC-RX, implement authorization checks before enabling operator
access.

CLI The CLI supports access-level security that permits up to 16 unique

levels of operator access. Each level can be configured for read and
read-write access, as well as for restrictions on individual commands or
command sets. To be permitted to an access level, the operator must log
in with the correct password. This supports different levels of operators
who may need access to the system. Optionally, RADIUS-based
operator authentication provides security at the individual operator
level.

SNMP Access lists are used to control operator access to the SNMP agent on
the system. Both the source IP address of the NMS and the SNMP
community name can be used to create the access list. This feature
means that an incoming SNMP request is checked against the IP
address/community name access filter list before it is fulfilled.
Unauthorized users are not allowed access. This approach allows the
service provider to control which SNMP operators or applications
access the MIBs.

SSH The ERX system supports the Secure Shell (SSH) Server protocol
version 2 as a secure alternative to Telnet for ERX system
administration. SSH supports secure remote login and other secure
network services. It allows operators to manage remotely over a secure
connection.

RADIUS Remote Authentication Dial-In User Service (RADIUS) is a

distributed client/server system that protects networks against
unauthorized access. Operators can be authenticated via RADIUS
before access to the system is permitted.
4-14 CHAPTER 4
Element and Network Management

NMC-RX The NMC-RX application supports detailed security control. All

operators must supply a username and password before they are allowed
access to the ERX system. One administrator is supported and can
create operator profiles. The administrator can set profile options for
read and read-write access, as well as restricting users to individual
ERX devices. This capability allows the service provider to divide up
the network securely, with different operators managing different
systems.

NMC-RX Overview
The NMC-RX application is a stand-alone network management
application that is capable of provisioning and controlling an entire
network of ERX edge routers. This software application delivers a set
of tools that enables service providers to quickly and easily provision an
ERX system and its physical interfaces, protocols, and services. In
addition, it delivers a key advantage over other applications by allowing
operators to view and manage the ERX network elements in terms of
customers and services.
The Java-based NMC-RX application provides a graphical user
interface (GUI) to augment traditional CLI and SNMP-based methods
of configuring the ERX system. With a GUI-based application,
operators are freed from learning arcane commands and have a more
intuitive window into the network operation. The NMC-RX
application also stores all configuration information in a relational
database, giving operators new levels of ability in terms of organizing
element data, synchronizing element configurations, and speeding
element configuration. In addition, the NMC-RX application is a
cost-effective client/services platform, easily able to support all
operators who need access to the software.
The NMC-RX application is one component of the UMC (Unisphere
Management Center), a comprehensive, standards-based network
management toolset that allows service providers to integrate software
components into an existing operations support system (OSS)
environment while delivering significant next-generation management
capabilities. See UMC Application Overview later in this chapter.

NMC-RX The NMC-RX application is optimized for GUI-based provisioning

Architecture control of the ERX system. The NMC-RX application runs on both
Windows (95/98/NT) and Sun Solaris UNIX (Version 2.7). The
 NMC-RX Overview 4-15
ERX Edge Routers

Windows version delivers a cost-effective program that allows operators

to install the NMC-RX client application on laptops and home
systems.
The NMC-RX architecture comprises several key elements:
• ODBC relational database
• Java client application installed on each management station
• Polling Service
• Config Synchronization Service
• Web Server that manages Customer Network Management (CNM)
GUI applet served to each subscriber terminal
These elements are individual applications and can be run as separate
processes over multiple host machines if desired to scale performance.

Relational Database
The NMC-RX architecture is based on an SQL-compliant ODBC
(Open Database Connectivity) relational database system (RDBS). This
standards-based approach allows the NMC-RX client applications to
communicate with a single centralized host. It also allows the
NMC-RX architecture to be independent of vendor databases, capable
of supporting any SQL-compliant database including Sybase, Microsoft
SQL, and Oracle. The current version of the product ships with Sybase
SQL.
This NMC-RX database architecture enforces a tight security policy,
with all function calls entered and checked by the database before they
are issued to the element. This policy provides a secure buffer between
operators and subscribers alike.

Java Technology
The NMC-RX uses a Sun Microsystems Java-based architecture. Java
allows all applications to be platform independent and capable of
running on multiple different operating systems. This capability allows
Unisphere to draw from a wide base of experienced programmers to
quickly add new features and reports for our service provider customers
and their subscribers.

Java application Java downloads to run on one or more client

management machines and then executes locally on the client machine.
Java provides platform independence for the application, allowing it to
be run on Windows, NT, or UNIX machines.
4-16 CHAPTER 4
Element and Network Management

Customer Network Management (CNM) application The

NMC-RX application is architected to provide CNM access to
network and service information with a scalable, secure approach. The
NMC-RX CNM allows subscribers to view statistical information on
service level agreement (SLA) performance, service utilization, and
QoS performance. As with all other calls to the NMC-RX system,
requests are processed through the database to protect the integrity of
the ERX elements and to secure access to corresponding network
operations. The NMC-RX architecture can also provide the ability for
subscribers to support configuration control for their service offerings.
Examples include setting QoS filters, bandwidth allocation, and VPN
policies. This ability allows service providers to offer subscribers
real-time control and feedback of their outsourced network services.

Polling Service
The Polling Service is a separate application that allows the service
provider to obtain information about the health of ERX elements. The
Polling Service operates by contacting each of the designated elements
and polling them for status information. It returns the state of the
element and its interfaces and displays the information graphically.
Service provider operators can use this function as an early warning
detection of element problems or to monitor problem interfaces. The
Polling Service is also architected to support advanced, targeted polling
of elements or interfaces so that the service provider can more
accurately pinpoint element interfaces for monitoring.

ConfigSync Service
The ConfigSync Service provides device discovery services. When you
create a new device through the NMC-RX application, the
ConfigSync Service goes out to the device and obtains information
about it.

Streamlined One of the most critical functions for service providers is the ability to
Provisioning quickly provision new elements and new services. Performing this
function cost effectively becomes critical when mass market B-RAS
services are offered to subscribers. The ERX system offers a number of
ways to automate provisioning, which can be viewed in two stages:
• Initial provisioning – This stage encompasses such tasks as
configuration of the hardware, physical interfaces, and protocols.
This stage also includes mapping customers to configurations in
 NMC-RX Overview 4-17
ERX Edge Routers

order to implement customer-based management. The NMC-RX

application provides a number of time-saving tools to help
streamline this process while also eliminating configuration mistakes.
• Subscriber-level provisioning – This stage is for mass market
applications, such as xDSL termination and service delivery. The
ERX system automates provisioning to drive cost-effective network
rollout. Both RADIUS and SSC can be used to auto provision
subscribers as they enter the network by assigning different levels or
types of service with no intervention by the network operator.

NMC-RX The NMC-RX application allows an operator to completely configure

Features a network of ERX edge routers. The GUI-based approach gives
operators a familiar windows-based navigation set, as shown in
Figure 4-2.

Intuitive Workshop Approach

There are two main work areas in the NMC-RX: the network-level
workshop and the device-level workshop. These work spaces allow the
operator to manage both network-wide configurations and also specific
elements.
4-18 CHAPTER 4
Element and Network Management

Network Workshop
Both physical and logical
interfaces are easily configured.

Configuration parameters
are stored in the database
and displayed graphically.
Device Workshop

Figure 4-2 Network-level and Device-level Workshops

Network Workshop At the network workshop level, an operator can

perform the following functions:
• Create and configure new groups
• View or reconfigure existing groups
• Organize groups into a hierarchy
• Create new devices
• Create new customers
• Create new users (if you are an administrator)
• Access the Device Workshop
• Create server sets to ease the provisioning of RADIUS, accounting,
and authentication servers
The power of the network level is that operators can group elements
together in meaningful ways. For example, all ERX systems in
Massachusetts and New York could be grouped and managed as
Northeast US, or all elements that run Frame Relay service can be
 NMC-RX Overview 4-19
ERX Edge Routers

grouped for management into an FR network. This feature allows the

operator to manage the network in a way that makes logical sense.
Access to groups and elements is controlled by passwords and security
privileges associated with groups. Only approved operators are allowed
to configure an ERX system. This privilege is controlled by
community lists and access lists of approved IP addresses, which allows
for enforcement of an IP address match before the system can be
configured.

Device Workshop At the device workshop level, an operator can

perform the following functions:
• Configure a device’s objects
• View configurations and statistics
• Delete devices
• List objects configured on the devices
• List customers associated with a device
• Create templates
• Run diagnostics
In addition, the NMC-RX application will autodiscover all installed
components within a given ERX system, allowing operators to ensure
installed configurations and easing initial provisioning tasks.

Streamlined Provisioning via Templates

The NMC-RX application offers a key feature to help operators speed
network provisioning and also reduce the number of errors made
during configuration. The NMC-RX template function allows the
operator to create and store standard configurations and reuse those
configurations when initializing a new element or interface. See
Figure 4-3.
4-20 CHAPTER 4
Element and Network Management

Powerful
templates feature
allows for
“configure once,
replicate many
times” to speed
provisioning of
new users, new
interfaces, or new
ERX systems.

Figure 4-3 Templates Feature

An advanced feature allows the service provider to bundle templates

together to create service templates for a complete configuration. This
allows the service provider to group together items that are configured
to make a service – such as gold service or T1 internet access service.

Statistics Display
As part of the configuration process, the NMC-RX application also
gives the ability to display statistics on a given element. The service
provider can then display real-time statistics that are provided by the
Polling Service on an individual element.

Customer-Driven Management
As service providers strive to offer competitive service delivery, the
network management paradigm is changing from one of element and
service management to one based on customer management. The NMC-RX
application offers advanced capabilities that allow the operator to
associate customers and customer sites with the service-delivering
 NMC-RX Overview 4-21
ERX Edge Routers

elements and then manage the network according to the customer’s

needs. See Figure 4-4.

You can list all

customers on a
specific device, circuit,
or interface.

You can associate

customers with
interfaces, allowing for
powerful tracking
features.

Figure 4-4 Associating Customers and Customer Sites with Services

Operators can use the powerful database of the NMC-RX application

to create and store customer-to-element associations and then pull from
this database to:
• Configure new customer sites according to a service profile
• Find all customers with traffic on a specific element to proactively
warn when downtimes may happen
• Find all customers associated with a given element in case of a
service-related fault to ensure that proper compensation is made to
the right customers
• Easily find and modify the configuration settings of a particular
customer when the customer upgrades or changes service
requirements

OSS Integration
The NMC-RX open architecture makes it capable of easily integrating
with existing OSSs already in place inside service provider networks.
These might include HP OpenView NNM, Quallaby Proviso and
Orchestream Service Activator, or custom-developed accounting and
4-22 CHAPTER 4
Element and Network Management

configuration applications. Northbound CORBA and Java RMI-based

interfaces allow for an open interface to all configuration capabilities in
the NMC-RX application. In addition, the standards-based compliance
of the ERX system allows applications to communicate directly to the
element via SNMP or CLI.

UMC Application Overview

The UMC application suite of service and network management tools

is designed to give service providers a competitive advantage by
enabling them to profit from highly-differentiated content, multimedia,
voice, and data services that attract and retain subscribers and partners.
These standards-based offerings are designed to give providers the tools
they need to take advantage of emerging standards and
technologies—while extending existing networks and applications—to
deliver value-added services across diverse network architectures.
The UMC application management product offerings include:
• Service Selection Center (SSC) with
> UMC Meta Directory option
> Extended Service and Subscriber Management option
• Network Element Managers
• Integration packs for management applications

Service The SSC is a key component of the UMC product portfolio. Designed
Selection to ease key steps in the service life-cycle process, the SSC integrated
Center service management offering includes service creation, subscriber
management, service activation, and accounting capabilities. The SSC
enables service providers to rapidly create and deploy new services to
hundreds of thousands of subscribers over a variety of broadband access
technologies, such as DSL, cable, Ethernet, and fixed wireless.
Working with the ERX edge router, the SSC lets users activate service
offerings as they need them and provisions the network to deliver those
services; service activation becomes a fully-automated, real-time
process.
 UMC Application Overview 4-23
ERX Edge Routers

The SSC includes three integral functionalities that address the critical
phases of the service life cycle. These functionalities include:
• Intelligent Service Creation – builds innovative new services
• Intelligent Service Activation – delivers services on an on-demand
basis to subscribers
• Intelligent Service Accounting – tracks, collates, and rates service
usage to enable rich and creative tariff models

Intelligent Service Creation

The traditional approach to creating new services is to hard code
services, such as firewalls or VPNs, into network elements. However,
this approach limits service offerings, which are somewhat inflexible,
and may result in performance sacrifices. The SSC provides far more
flexibility, plus the opportunity to be more creative in putting together
service offerings.
Using service templates, providers can transform edge device features
such as policy routing, filtering, rate limiting, traffic shaping, and
multicasting into service building blocks. They can then combine those
blocks with content servers to define a wide range of access, content,
and bundled services (See Figure 2.) These service definitions are
stored in a logically centralized directory, along with subscriber
information. They can be activated at any time by a subscriber’s mouse
click on a Service Selection Portal (SSP) page.
In addition, creative tariff models may be defined in association with
new services. Such tariff models may be based on a combination of flat
fees, pay-per-time, pay-per-byte, discounts, and other criteria.
With the SSC, providers can quickly define service parameters,
efficiently create services, and economically deliver the services to
subscribers. By delivering content and applications with the most
appropriate bandwidth, latency, and quality of service, subscribers’
service is optimized. The SSC also provides the ability to use multiple
differentiated tariff models, which helps to promote a steady service
revenue stream and reduces demands on customer care resources.
4-24 CHAPTER 4
Element and Network Management

Dynamic, On-Demand Service Activation

When a specific service is activated for a user, the SSC retrieves policy
and provisioning information from the directory for that service. It
then uses the information to quickly and automatically update the
ERX system configuration. The SSC manages network resources to
control QoS levels that provide an optimal experience for subscribers.
It invokes the policy rules and parameters that characterize a service
and ensures proper mapping to network elements. Modeled on the
IETF policy framework, this carrier-grade, directory-driven service
activation engine acts as the decision point for service requests coming
from users and interfaces directly with network elements to enforce
policies. In addition, service and policy usage data collection is initiated
to track service sessions.

Web-Based Customizable Portal

Reducing the cost of operations and building closer bonds with
subscribers are essential for any service provider’s success. Enabling
subscribers to activate services instantaneously when they want to use
them is key to achieving this goal.
The Intelligent Service Activation function of the SSC includes a
customizable Web-based portal, the SSP, which can be tailored to
providers’ presentation needs and customized to each individual
subscriber. Dynamically generated from information stored in the
subscriber profile, the SSP Web pages give subscribers instant access to
personalized services, without the need to interact with customer
representatives. Proprietary client software is not required; the
subscriber can use any Web browser.
Using the SSC gives subscribers more control over their service choices
and helps providers build closer bonds with subscribers and with retail
partners, while letting providers retain control of their network.

Integration with OSS and Billing Applications

The Intelligent Service Accounting function of the SSC tracks the
service activity for each user and each service, collects usage
information and rates it (enforcing the appropriate tariff model), and
passes that information to the appropriate billing system.
Because service provides have made a significant investment in back
office systems, it is important to note that the SSC supports open
interfaces and mediation mechanisms to facilitate system integration
 UMC Application Overview 4-25
ERX Edge Routers

with diverse OSS applications, including customer care, order entry,

provisioning, billing, security, and sales support systems. The UMC
application allows providers to migrate toward next generation IP
networking, while maintaining compatibility with legacy OSS
applications and repositories. In fact, the entire UMC product family
for service and network management is designed to extend the
functionality of an existing OSS infrastructure.

UMC Meta The UMC Meta Directory option provides the scalability required by
Directory large or rapidly growing subscriber bases. This general purpose, highly
scalable repository complies with X.500-93, X.509, and Lightweight
Directory Access Protocol (LDAP) standards. Based on Siemens’
award-winning DirX Meta Directory, its data management features
include the ability to exchange information from external repositories,
such as databases, and synchronize them bidirectionally. Such
synchronization capability is key to allowing fast integration with
existing OSS systems.
The UMC Meta Directory houses infrequently changing information
such as user profiles, service definition parameters, RADIUS
authentication and authorization information, service policies, and
service portal configurations, while providing a single point of
administration.

Extended Larger subscriber bases also require more sophisticated service and
Service and subscriber management. For this purpose, the UMC application offers
Subscriber the Extended Service and Subscriber Management (ESSM) option.
Management This options is based on our partner TeleKnowledge’s Total-e™
solution, and it includes a number of important functions. For example,
a collection of high-level GUIs guides service provider operators
through the subscriber management and provisioning process.
Easy-to-understand service templates enable operators to easily define
the characteristics of a new service. Other GUIs provide user
registration and subscription guidance. The resulting service and
subscriber profiles are stored and activated on demand.
To ensure that tariff models are followed, a powerful rating function is
integrated with the service definition and user registration functions.
Combining the ESSM option with the SSC and the UMC Meta
Directory results in a highly scalable system, capable of subscriber
management, authentication, authorization, accounting, and rating.
4-26 CHAPTER 4
Element and Network Management

Plus, Unisphere Networks’ standards-based approach makes it easier to

integrate with existing back office OSS and BSS systems.

Integration The UMC integration packs further extend the capabilities of the
Packs UMC application.

Topology Management
Using UMC HP OpenView Integration Pack software, the ERX
system can be managed using the HP OpenView manager-of-managers
network management solution. HP OpenView provides indepth views
of networks, automatically discovers network devices, and provides an
intuitive GUI representing the network topology. A multi-level map
indicates which devices and network segments are healthy and which
areas need attention.
When a flood of events resulting from a major device failure appears in
its Alarm Browser, HP OpenView correlates the events and presents a
summarized view of the failure, as well as offering trend analysis,
thresholding, and data warehousing features that empower proactive
network management. The HP OpenView Integration Pack also
includes the capability to automatically launch the NMC-RX Element
Manager directly from the HP OpenView GUI in a context-sensitive
manner, allowing operators to rapidly access the necessary tools for
configuration and diagnostics.

Fault Management
The UMC Micromuse Netcool Integration Pack includes probes,
rules, tools, and automation definitions that enable Unisphere
Networks network elements to work with Micromuse Netcool®, the
market-leading fault-management solution. Micromuse Netcool
provides real-time monitoring of all elements that compose the
network and of all services that are affected by element outages. Its
distributed architecture enables a network operations center to develop
customized, real-time views of services from diverse management
platforms, devices, and network elements throughout the network.
Micromuse Netcool also associates these events with services and
customers.
The Micromuse Netcool Integration Pack provides an out-of-the-box
configuration that allows Netcool to receive SNMP traps from ERX
systems, to present those events to operators in a user-friendly manner,
 UMC Application Overview 4-27
ERX Edge Routers

and to correlate related events to optimize operator activities.

Micromuse Netcool can also be used to associate these events with
services and customers, and to integrate into other OSS systems to
provide a tightly integrated management suite.

Performance Management
Unisphere Networks has partnered with Quallaby Corporation for
performance management capabilities. Performance management is
essential to effective network management and the delivery of
measurable Service Level Agreements (SLAs). With a strong
performance management solution in place, network operations and
engineering gain meaningful insight into performance, policy,
bandwidth, and QoS. Service Providers can offer proactive service-level
management as well as access to management information needed to
run their businesses. The UMC Performance Management Application
Pack is designed to plug into Quallaby Corporation’s PROVISO®,
providing the collectors and report libraries needed for performance
management, network planning, traffic analysis, troubleshooting efforts
and SLA reporting in networks built with Unisphere Networks
equipment.

Additional Partners
Additional Unisphere Networks partners include Funk Software, for
integration with their award-winning Steel Belted Radius
authentication server, and Orchestream™ Holdings plc, a leading
provider of IP service activation and performance management
software, for VPN management.
4-28 CHAPTER 4
Element and Network Management
Statistics, Accounting,
and Diagnostics

This chapter describes the ERX system’s statistics, accounting, and

diagnostics features.

Topic Page
Statistics and Accounting 5-1
Monitoring and Diagnostics 5-2
Product Upgrades 5-7

Statistics and Accounting

A critical necessity for service providers is the ability to measure traffic
in the network. This information is used for a variety of purposes,
including subscriber billing, traffic planning, and network load
assessment. The most scalable place to measure subscriber traffic is at
the edge of the network.
The ERX system is capable of gathering statistics for each interface, for
each policy, and for each service class without affecting system
performance. This is possible because each of the system’s line modules
has sophisticated hardware support for statistics. Specific intervals for
the collection of statistics can be set. Once gathered, the statistics can be
offloaded to a service provider operations support system (OSS) or
relational database for further processing.
The ERX system provides bulk statistics collection and file transfer to
support the download of statistics on a scheduled interval. This method
gives service providers an option to retrieve statistical information
beyond SNMP polling.
5-2 CHAPTER 5
Statistics, Accounting, and Diagnostics

The ERX system gathers statistics at three levels: layer 2, network

interface, and traffic. Statistics gathered include:
Per layer 2 interface
• Bytes/cells/frames – ingress and egress
• Bytes/cells/frames discarded – ingress and egress
• Ingress errored cells/frames
• Packet discard reason counters – ingress and egress
Per Network interface
• Bytes/packets – ingress and egress
• Ingress bytes/packets forwarded (total across all egresses)
• Ingress errored packets
• Bytes/packets discarded – ingress and egress
Per flow
• Ingress packets marked in/out
• Ingress bytes/packets per DS class after stamping step (DS can be
any QoS class)
• Ingress bytes/packets per DS class forwarded (total across all
egresses)
• Ingress/egress bytes per DS class discarded (total across all egresses)

Monitoring and Diagnostics

The ERX system supports a number of monitoring and diagnostic
functions to help operators and Unisphere Customer Service
troubleshoot the system. Some of these functions are described in the
following sections.

Module Each line module and I/O module has its own EEPROM to store and
Identifier make key information on the module accessible to management. The
information is coded onto the module during the in-circuit test phase
of the manufacturing process. This identifier allows the service provider
to accurately identify and track the ERX systems and modules after
they are installed.
 Monitoring and Diagnostics 5-3
ERX Edge Routers

Information for identifying the module includes:

• ID to identify the board type
• Storage of the module’s MAC address(es), if required by the board
• Serial number that indicates manufacture date
• Part number and revision level
• Return and repair counts

Event Logging The ERX system provides comprehensive information that can be
stored in event logs. This information enables service providers to
troubleshoot system-level and interface-level problems. A number of
features are supported, including filtering capabilities and destination
options.
Information stored in event logs can be filtered in a number of different
ways to help isolate the cause of the problem. Filter options include:
• Event severity level – emergency, alert, critical, error, warning,
notice, information, and debug
• Event instance – instances vary by event category
• Event verbosity level – high, medium, low
Event logs can be directed to up to four destinations and the severity
level can be designated per destination. For example, you could specify
that all severity emergency events be sent to the syslog. Event log
destinations include:
• Nonvolatile storage (NVS) on the SRP
• Console serial port on the SRP
• Syslog daemon
• Buffer on the SRP, which can be viewed with the CLI

Diagnostic The ERX system implements a comprehensive suite of diagnostic tests

Support to help operators identify and troubleshoot product problems. You can
access the diagnostic tests through a local or modem connection to the
DB-9 management port on the SRP I/O module.
When a test is run, it returns results that indicate if it was successful.
Unsuccessful test results include information that indicate the condition
expected and the actual condition that caused the failure.
5-4 CHAPTER 5
Statistics, Accounting, and Diagnostics

The following features are supported:

• Context-sensitive help menus and prompts
• Power-on self-test (POST) that runs on chassis power-up and
module hot insertion
• Standby diagnostics that run while a system is operational: active
and standby (run on redundant boards). Tests do not disrupt
network traffic.
• Event logs that record hardware failures associated with a board as
well as other significant events, such as a reset and a system event log
that contains entries for system failures such as fan failures. Logs are
stored in NVS and are timestamped by the system clock.

Protocol Diagnostic tests can be run to isolate network or system anomalies for
Diagnostics each line module and each protocol. The ERX system supports a
verbose mode to capture the PPP frames of any single link, including a
timestamp that enables a user to troubleshoot the PPP link if LCP
and/or IPCP cannot successfully establish a connection. A trace
function and event log allow retrieval of this information for use
beyond the local console. The system also supports Frame Relay and
ATM diagnostic tools such as LMI and OAM F5 to isolate problems
with these protocols.

Loopback Tests The system supports a number of loopback tests for the CT3 module.
See Table 5-1.

Table 5-1 Loopback Tests for a CT3 Module

Loopback Mode Description

DS3/DS1 Internal Loopback The transmit DS3 or DS1 stream is looped back to the
receiver before the DS3/DS1 framer, blocking any
external incoming traffic. The test is run using a copy of
the transmit data stream.
DS3/DS1 Line Loopback The receive DS3 or DS1 data stream is looped back to
the transmitter before the DS1 framer, blocking any
internal transmit traffic.
DS3/DS1 Payload Loopback The receive DS3 or DS1 data stream is looped back to
the transmitter after the DS3/DS1 framer.
Per DS1/DS0 Loopback Similar to payload loopback, any DS1/DS0 receive
stream can be individually looped back to the
transmitter. This test allows loopback down to the
individual DS0.
 Monitoring and Diagnostics 5-5
ERX Edge Routers

Test Patterns To help service providers troubleshoot line problems, the system
provides powerful test pattern generation and bit error rate test (BERT)
capabilities. All of the standard test patterns (2^23+1, 2^15+1, QRSS,
511, etc.) are supported. Pseudorandom patterns and
user-programmable patterns are also supported. The patterns can be
generated and tested over any DS0 or group of DS0s. Both n x 56K and
n x 64K are supported.

Dump Capability To help Unisphere and service provider operators identify system
problems, the system supports a crash dump capability that allows the
operational software to save the stack trace, the reason for failure, and
the CPU registers. Information can be gathered from both the line
modules and the SRP module. The crash dump information is stored
in NVS on the SRP module and can be copied from the system to a
designated host.

Show A number of show commands are available to examine information

Commands about the system. The following list is a sampling:
• show aaa – displays information on accounting intervals, mapping
between user domains and virtual routers, IP address of DNS and
WINS name servers, and the name of the virtual router for which
duplicate accounting records are saved
• show atm – displays information and statistics about ATM
interfaces
• show boot – displays configuration, system, image, and diagnostic
images used at startup
• show bulkstats – displays information statistics, traps, and counters
• show clns – displays information about connectionless network
service (CLNS) interfaces, neighbors, routing processes, and traffic
• show clock – displays the clock source for the system
• show config – lists all commands required to duplicate the existing
operational configuration
• show controllers – displays information about T1, T3, E1, E3,
CT1, and CE1 controller interfaces
• show dhcp relay – displays IP address of the configured DHCP
server
• show environment – displays the temperature and voltage
information
5-6 CHAPTER 5
Statistics, Accounting, and Diagnostics

• show frame-relay – displays information and statistics about

Frame Relay interfaces
• show hosts – lists all configured hosts
• show interfaces – displays current state of the FastEthernet or
serial interfaces
• show interfaces pos – displays packet over SONET information
• show ip – displays information about IP configurations, including
templates, traffic, routing tables, routes, statistics, route distribution
policy, and access lists
• show ip-mroute – displays information about all or specified
multicast routes
• show ip multicast protocols – displays information about the
multicast protocols enabled on the system
• show ip multicast routing – displays information about the status
of multicast routing
• show isis – displays the IS-IS link state database and information
about SPF calculations and aggregate addresses
• show l2tp – displays information about the L2TP configuration on
the system
• show last-reset – displays the reason for reloading specified by the
user and detailed information in the event of system failure
• show log – displays the system log and log configuration settings
• show mpls – displays status and configuration information about
MPLS
• show ppp interface – displays PPP information
• show ppoe interface – displays PPP over Ethernet interface
information
• show ppoe subinterface – displays PPP over Ethernet interface
information
• show radius – displays information about the RADIUS
authentication and accounting servers
• show radius algorithm – displays the algorithm used by the
RADIUS servers
• show reload – shows the reload status
• show route-map – displays the route maps
• show rtr application – displays RTR application information
• show secrets – displays system passwords and secrets
 Product Upgrades 5-7
ERX Edge Routers

• show snmp – displays information on the state of communication

between the SNMP agent and the SNMP manager, communities,
and traps
• show subscribers – displays authenticated PPP users
• show terminal – displays information about the terminal
configuration of the current terminal line
• show timing – displays system timing settings and operational
status
• show version – displays the operational status, the software version,
and the armed release version for each module
• show virtual-router – displays the virtual routers configured

Product Upgrades
The system is designed for ease of maintenance, including upgrades to
hardware and software. The system supports dynamic configuration
changes to the system software and hardware modules without
disrupting other system operations.
For example, all firmware can be upgraded in the background during
normal service delivery; then individual software objects, such as
routing protocols and line interface modules, can be restarted to reduce
any service disruption. The system can save previous files and images
for each of these objects and revert to those images if problems are
discovered in the new software. The older image can be enabled in two
ways:
• If the system is rebooting with an abnormal rate (as defined by the
configuration), the system automatically reverts to the previous
system image.
• If the system successfully boots, the administrator can still manually
choose to revert to the previous image at any time.
All startup, boot, diagnostic, and operational software can be remotely
upgraded through out-of-band management ports and in-band IP
interfaces to further ease upgrade operations.

System Startup The ERX system receives the operational software image from the SRP
module. This image is then downloaded to each line module as
appropriate. The SRP module can receive the operational image from
the NVS card or through a network download.
5-8 CHAPTER 5
Statistics, Accounting, and Diagnostics

Configuration The ERX system supports system configuration storage in an NVS

Storage software component located on the SRP module. A configuration
image is downloaded to each line module. This functionality supports
the following features:
• Configuration information storage between powercycles
• Fast system startup achieved by storage data in a compact binary
form
• Configuration synchronization among redundant modules,
regardless of the current state of the standby module(s)
Service and Support

This chapter describes the Unisphere Networks service programs

dedicated to providing superior support for service provider operations.

Topic Page
Factory Warranty 6-1
Professional Services 6-2
Preconfiguration Services 6-2
Educational Services 6-2
Technical Assistance Center (TAC) 6-2
Hardware Services 6-3
Contacting Unisphere Networks 6-3

Factory Warranty
Unisphere Networks offers the following product warranties:
• A standard 1 year return-to-factory warranty on all ERX system
hardware components
• A standard 90-day warranty that the ERX software conforms to its
published specification.
Extended warranty options are available through Unisphere Customer
Service.
6-2 CHAPTER 6
Service and Support

Professional Services
Unisphere’s network architects can help design a network to meet
service and uptime requirements and provide optimal interoperability
with other devices in the network.

Preconfiguration Services
Unisphere offers a preshipment service that can soft-configure and test
a node to meet site requirements, dramatically reducing on-site
installation time.

Educational Services
Unisphere’s classroom services provide training for service provider
operators on the configuration, operation, maintenance, and scaling of
the ERX system.

Technical Assistance Center (TAC)

Our trained experts can assist in the diagnosis and correction of any
system-related issues. Access to the TAC is available by phone, e-mail,
or the Web. Customer contacts are provided user accounts and
passwords to access the Unisphere Customer Service Web site.
Using the Unisphere Web site, customers can:
• Manage support cases online
• Download and view Unisphere documentation and release notes
• Check known problems using the online knowledge database
• Download new and patched versions of software
Through e-mail, customers are notified of software changes that may
affect them and are provided pointers to new software versions and
documentation as they become available.
 Hardware Services 6-3
ERX Edge Routers

Hardware Services
The use of hardware services ensures that hardware will be on hand in
case of failure. Unit failure is confirmed by the Unisphere TAC, and
the service provider can receive a field replaceable unit (FRU) by the
next business day.

Contacting Unisphere Networks

As your technology and service partner, Unisphere can be contacted in

the following ways. Be prepared to provide the following information:
• A brief description of the problem
• The severity level of the problem
• The serial number of the affected unit (for hardware failures). The
serial number is a 10-digit number on a label on the unit’s chassis.

Note: To receive the fastest response in the event of a severity 1 issue, contact
Unisphere by telephone.

Telephone • North America – (800) 424-2344

• Outside North America – (978) 848-0685

E-mail • Send e-mail to support@unispherenetworks.com

Web Site • http://www.unispherenetworks.com

6-4 CHAPTER 6
Service and Support
Applications Overview

This chapter details several applications that the ERX system can
support and describes the feature sets that make these applications
successful.

Topic Page
Private Line Aggregation 7-2
XDSL Session Termination 7-4
Virtual Private Networks 7-7
Cable Subscriber Management 7-9
MPLS for Traffic Control 7-12
MPLS for VPNs 7-14
SLA Support 7-16
Non-IP Protocol Applications 7-16
VoIP Transport 7-17
Wholesaling 7-18
End-to-End QoS 7-20
VLAN Implementation 7-22
Fixed Wireless Applications 7-23
7-2 CHAPTER 7
Applications Overview

Private Line Aggregation

A main application for the ERX edge router is for private line
aggregation, the consolidation of multiple high-speed access lines into
one access point. Figure 7-1 shows the application.

Business Users

Edge Core

FT1/fE1 ERX System

ADM
T1/E1
GE
ADM Internet
SONET DACS OC3/STM1 Backbone
Ring POS/ATM
nxT1
ADM T3/E3/E1 OC12/STM4
T3/E3
ATM/FR/PPP POS/ATM

Telco Service Provider

Network Network
Tier 2/3
ISP
Network

Figure 7-1 Private Line Aggregation Application

In this application, the service provider can use a single ERX system to
offer high-speed access (FT1/FE1 through T3/E3) to thousands of
subscribers with a single unit. The individual subscriber lines can be
multiplexed into T3 lines by the Telco provider and fed into the ERX
system. (The system can also accept unchannelized T3 or E3
connections from high-speed users and channelized E1 connections
directly into the unit.) Once the traffic is received, the system then
handles all IP packet processing, including the assignment of QoS and
routing policies. The packets are then routed into the backbone
network.
The system supports a number of access and uplink methods; the most
common pairings are listed in Table 7-1.
 Private Line Aggregation 7-3
ERX Edge Routers

Table 7-1 Common Access/Uplink Pairings

Access Uplink
PPP
Frame Relay ATM or POS

ATM

Remember, however, that any port on the ERX system can be used for
access or uplink. This means that both PPP and Frame Relay (FR)
ports can be used as uplink ports as well. This configuration can
accommodate subscribers who have two sites connected to the same
ERX system over FR or PPP links, or can provide an uplink for a FR
service.
By using the ERX system for private line aggregation, a service
provider can overcome a number of limitations presented by older
products, such as density constraints, performance limitations, and lack
of carrier-class reliability. In addition, by using the system, the service
provider gains the ability to offer a number of new IP services to the
subscriber base.
The ERX system offers a number of key features that deliver critical
benefits to service providers who offer private line aggregation. The
features are listed in Table 7-2.

Table 7-2 Product Features and Benefits for Private Line Aggregation

ERX System Feature Service Provider Benefit

10x density improvement over older
products with support for 4,000 FT1s and
1,000 T1s per chassis
Wire-speed packet processing on all
interfaces with ERX ASIC technology
Carrier-class reliability with
NEBS-compliant hardware design,
hot-swappable modules, and redundancy
and modular sofware architecture
Sophisticated frame-processing
capabilities distributed down to each line
module
Alleviates space constraints in COs and
POPs and allows service providers to
deliver more high-speed connections in a
smaller footprint, with smaller power draw
Delivers high-performance throughput to
subscribers and supports delivery of QoS
policies
Allows service providers to offer SLAs
with assurance of maximum uptime
Supports deployment of new IP services
such as QoS, detailed accounting, and
VPNs, while maintaining wire-speed
routing
7-4 CHAPTER 7
Applications Overview

Table 7-2 Product Features and Benefits for Private Line Aggregation (continued)

ERX System Feature Service Provider Benefit

Fine-grained, wire-speed IP QoS
capabilities for up to 64,000 subscriber
flows
Detailed statistics gathering for each
subscriber and for each service
Highly scalable and robust routing
protocols: BGP-4, IS-IS, OSPF, and RIP
Allows innovative IP services to be
created for the entire subscriber base,
including:
• Throughput guarantees (maximum
and minimum)
• Preferred traffic treatment (Gold,
Silver, Bronze)
• Customer-specific traffic treatment
• Application-specific traffic treatment
Provides information required for bill
generation and SLA reports
• Allows service providers to run a
combination of routing protocols
across the network
• Allows service providers to scale to
support thousands of router peers and
route tables with hundreds of
thousands of entries to keep pace with
network growth

XDSL Session Termination

The ERX system supports Broadband Remote Access Server (B-RAS)
applications, as shown in Figure 7-2. In this application, the ERX
system handles the aggregated output from the DSLAMs. The
DSLAMs are directly connected to the subscriber premises, handle the
copper termination, and aggregate the traffic into a higher-speed
uplink. The output from the DSLAM is fed into the system via a DS3
or OC3 link.
 XDSL Session Termination 7-5
ERX Edge Routers

Consumer &
Business CLEC
Users (xDSL)

IP/PPP/ATM ERX System

ATM/FR ISP
OC3/STM1
DS3 FR/ATM
OC12/STM4
OC3/STM1 ATM
IP/PPP/FR POS/ATM
GE

DSLAM
IP/PPPoE/ATM
VPN
DHCP RADIUS

IP/PPPoE/FR Access Service

Network Network
Internet
Provider Provider

Figure 7-2 B-RAS Application

The ERX system then handles several functions:

• PPP session termination and authentication checking via PAP or
CHAP
• Coordination with DHCP servers and local IP pools to assign IP
address
• Connection to RADIUS servers or use of domain names to
associate subscriber with user profile information
• Support for RADIUS accounting to gather detailed billing
information
• Application of the user profile to the user traffic flow, which could
include QoS, VPN, and routing profiles
The output of the ERX system is typically a high-speed link, such as
OC3/STM1 or OC12/STM4 to feed a core backbone router. Virtual
routers can also be used to keep the traffic logically separate and direct
packets to different destinations. As shown in Figure 7-2, the packets
can be directed to a CLEC, ISP, corporate VPN, or the Internet.
7-6 CHAPTER 7
Applications Overview

A large number of xDSL protocols are supported, including:

• IP/PPP/ATM
• IP/PPP/Ethernet/ATM
• IP/PPP/FR
• IP/PPP/Ethernet/FR
This protocol support allows service providers to install a central site
router that can terminate signals from a wide variety of CPE xDSL
devices.
By using the ERX system for B-RAS, the service provider can
overcome a number of limitations offered by older products, as well as
offer a number of new services to the subscriber base. The ERX system
offers many features to support this application. These features are listed
in Table 7-3.

Table 7-3 ERX System Features and service provider Benefits for B-RAS

ERX System Feature Service Provider Benefits

100x density improvement over older
products with support for 32,000 IP
interfaces in a single chassis
Wire-speed packet processing on all
interfaces with ERX system ASIC
technology
Carrier-class reliability with
NEBS-compliant hardware design,
hot-swappable modules, and redundancy
and modular sofware architecture
Fine-grained, wire-speed IP QoS
capabilities for up to 64,000 subscriber
flows
Detailed statistics gathering for each
subscriber and for each service, and
support for RADIUS accounting
Provides service providers with a
cost-effective platform from which to roll
out high-consumption but low-cost xDSL
services.
Delivers high-performance throughput to
subscribers and supports delivery of QoS
policies
Allows service providers to offer SLAs
with assurance of maximum uptime
Allows innovative IP services to be
created for the entire subscriber base,
including:
• Throughput guarantees (maximum
and minimum)
• Preferred traffic treatment (Gold,
Silver, Bronze)
• Customer-specific traffic treatment
• Application-specific traffic treatment
Provides information required for bill
generation and SLA reports, and
integrates with current OSSs
 Virtual Private Networks 7-7
ERX Edge Routers

Table 7-3 ERX System Features and service provider Benefits for B-RAS (continued)

ERX System Feature Service Provider Benefits

Highly scalable and robust routing
protocols developed to meet large-scale
service provider needs: BGP-4, IS-IS,
OSPF, and RIP
Ability to support logically separate virtual
routers within a single chassis
Support for PPP, CHAP, PAP, DHCP, and
RADIUS
With the ERX system support for BGP-4
and IS-IS, service providers can offer
xDSL services from a network-peer
platform, rendering two-stage B-RAS
solutions obsolete
Allows service providers to securely route
traffic targeted at different destinations
(such as corporate VPN vs ISP)
Allows service providers to roll out xDSL
services using existing dial OSS
infrastructure, greatly reducing the cost of
offering a new price-competitive service

Virtual Private Networks

VPNs are secure, logically partitioned, private IP networks provisioned

over a common shared IP infrastructure. The ERX system allows
service providers to offer VPNs to telecommuters, branch business sites,
and wholesale partners.

“Big” ISP
“Big” ISP Customer

RAS
Dial Line ERX System
“Local” ISP
“Local” ISP Customer DLSAM OC3/STM1
DS3 FR/ATM
OC12/STM4
ATM/xDSL OC3 ATM
Xconnect ATM

Telecommuter to “Tall” Corp

Access
PPP/xDSL Network
Provider DHCP RADIUS

“Tall” Corp Branch Office Service

Network “Tall” Corp
Provider
FR/T1

Figure 7-3 Delivery of VPNs over a Shared IP Infrastructure

As shown in Figure 7-3, many subscribers are coming into the service
provider network via a variety of access methods and with a variety of
destinations. The ERX system is capable of handling all of the
7-8 CHAPTER 7
Applications Overview

protocols and line rates. For xDSL users, a DSLAM would first
terminate the copper before passing the traffic into the ERX system.
For the dial user, a RAS would first answer the modem call before
handing the data flow to the ERX system.
Subscribers entering the network via dedicated leased lines would
typically be multiplexed into T3 lines and then enter the ERX unit (or
be directly connected to the ERX system in the cases of T3, E3, and
E1).
Once the packet enters the ERX system, any combination of
classification filters can be used to identify the subscriber and the
destination, or, for PPP users, a query can be made to a deployed
RADIUS server.
There are three ways in which the ERX system can initiate the VPN to
securely send traffic to different destinations:
• The ERX system supports layer 2 virtual circuits for either Frame
Relay or ATM. Each incoming subscriber traffic flow can be
mapped to a secure FR/ATM VC for transport to the destination
address.
• The ERX system can support multiple virtual routers with separate,
secure routing tables and IP forwarding processes. These virtual
routers maintain separate routing tables for each router instance.
This keeps traffic completely segmented between subscriber groups
with different destinations.
• The ERX system can append MPLS labels to forward packets over
directed VPN paths that the service provider configures.
The ERX system supports a number of key features that benefit a
service provider who offers the VPN services detailed in Table 7-4.

Table 7-4 ERX System Features and service provider Benefits for VPNs

ERX System Feature Service Provider Benefit

Support for a wide variety of access
protocols: FR, PPP, ATM, and POS
Wire-speed packet processing on all
interfaces with ERX ASIC technology
Gives service providers a single unit that
can deliver a wide range of services to
subscribers, including both legacy and
new IP services
Delivers high-performance throughput to
subscribers and supports delivery of QoS
policies
 Cable Subscriber Management 7-9
ERX Edge Routers

Table 7-4 ERX System Features and service provider Benefits for VPNs (continued)

ERX System Feature Service Provider Benefit

Carrier-class reliability with
NEBS-compliant hardware design,
hot-swappable modules, and redundancy
and modular software architecture
Fine-grained, wire-speed IP QoS
capabilities for up to 64,000 subscriber
flows
Detailed statistics gathering for each
subscriber and for each service
Ability to support logically separate virtual
routers within a single chassis
Allows service providers to offer SLAs
with assurance of maximum uptime
Allows innovative IP services to be
created for the entire subscriber base,
including:
• Throughput guarantees (maximum
and minimum)
• Preferred traffic treatment (Gold,
Silver, Bronze)
• Customer-specific traffic treatment
• Application-specific traffic treatment
Provides information required for bill
generation and SLA reports
Allows service providers to securely route
traffic targeted at different destinations
(such as corporate VPN vs ISP)

Cable Subscriber Management

Multiservice operators (MSOs) offering high-speed, broadband
Internet access services as well as new, advanced IP services to their
subscribers will benefit from the next-generation architecture of the
ERX system. As shown in Figure 7-4, an ERX system can aggregate
traffic from cable modem termination systems (CMTSs) for access to
the Internet backbone when deployed by MSOs in regional or “super”
headend locations. The ERX system simultaneously aggregates data
traffic from existing and future cable networks by supporting both
data-over-cable service interface specifications (DOCSIS) and
non-DOCSIS networks.
7-10 CHAPTER 7
Applications Overview

Consumer & Business CLEC

Users (Cable Modem)

ATM
IP/Ethernet Ethernet ERX System
POS 10/100 Enet OC3/STM1
ISP
Gigabit Enet OC12/STM4
IP/ATM OC3 ATM POS/ATM
OC3 POS Gig Eth

CMTS
IP/PPPoE
VPN
DHCP SSC
RADIUS

IP/L2TP Cable Hub Super Headend

Cable Service Provider Internet

HFC Network

Figure 7-4 Cable Subscribe Management Application

The ERX system handles the following functions:

• Support for both PPP-based as well as IP-based session termination
and authentication
• Coordination with DHCP servers and local IP pools to assign IP
address
• Connection to RADIUS services or use of domain names to
associate subscriber with user profile information
• Support for RADIUS and IP accounting to gather detailed billing
information
• Application of the user profile to the user traffic flow, which could
include QoS, VPN, and routing profiles
The aggregation of the CMTS traffic to the ERX system is typically
across a high-speed link, such as Gigabit Ethernet or OC3/STM1. The
output of the ERX system is typically a high-speed link, such as
OC3/STM1 or OC12/STM4, to feed a core backbone router. Virtual
routers can also be used to keep traffic logically separate and create
separate management domains to support an equal access ISP model.
 Cable Subscriber Management 7-11
ERX Edge Routers

The ERX system supports the following cable protocols:

• ATM 1483
• ATM 1577
• PPPoE
• L2TP
The cable operator can support multiple service areas with a single
ERX platform while leveraging lower-cost L2 CMTS products using
the ERX system. This ability reduces the complexity of the network
and overall cost, and increases the operational efficiency of rolling out
new networks and new services. See Table 7-5.

Table 7-5 ERX System Features and Service Provider Benefits for Cable Subscriber
Management

ERX System Feature Service Provider Benefit

Support for both DOCSIS and
non-DOCSIS cable networks
10x density of competing subscriber
management platforms with support for
32,000 simultaneous IP sessions in a
single chassis
Integrates advanced subscriber
management with next-generation routing over alternative subscriber management
Scalable L3 performance and wire-speed
forwarding
Carrier-class reliability with
NEBS-compliant hardware design,
hot-swappable modules, and redundancy
and modular software architecture
Fine-grained, wire-speed IP QoS
capabilities for up to 64,000 subscriber
flows
Preserves existing investment in
cable-modem equipment and supports
integration of both standards-based and
proprietary equipment into a common
network
Allows cable operators to cost effectively
support multiple service areas from a
single service platform
Reduced cost and space requirements
platforms that require an adjunct router
Cable operators can utilize low-cost L2
CMTSs at the hub and centralize routing
and service delivery to increase
operational efficiencies
Allows cable operators to offer SLAs with
assurance of maximum uptime
Allows innovative IP services to be
created for the entire subscriber base,
including:
• Throughput guarantees (maximum
and minimum)
• Preferred traffic treatment (Gold,
Silver, Bronze)
• Customer-specific traffic treatment
• Application-specific traffic treatment
7-12 CHAPTER 7
Applications Overview

Table 7-5 ERX System Features and Service Provider Benefits for Cable Subscriber
Management (continued)

ERX System Feature Service Provider Benefit

Detailed statistics gathering for each
subscriber and for each service and
support for RADIUS and IP-based
accounting
Highly scalable and robust routing
protocols developed to meet large-scale
service provider needs: BGP-4, IS-IS,
OSPF, and RIP
Ability to support logically separate virtual
routers within a single chassis
Support for PPP, PPPoE, CHAP, PAP,
DHCP, and RADIUS
Access-agnostic network termination
Provides information required for bill
generation and SLA reports, and
integrates with current OSSs
With the ERX system support for BGP-4
and IS-IS, service providers can offer
broadband services from a network-peer
platform, rendering two-stage B-RAS
solutions obsolete
Allows cable operators to securely route
traffic targeted at different destinations to
support an equal access model
Allows cable operators to roll out
on-demand IP services using existing
OSS infrastructure, greatly reducing the
cost of adding new services while
introducing new revenue streams
The ERX system provides a consistent
subscriber management and service
delivery platform for all service
applications, including cable, xDSL,
wireless, and circuit aggregation

MPLS for Traffic Control

The ERX system supports the emerging Multiprotocol Label
Switching (MPLS) standards to allow service providers to use this
protocol tool for traffic engineering or VPN creation.
One of the uses for MPLS is to improve the IP traffic–engineering
capabilities of the network by classifying and forwarding IP traffic into
MPLS label-switched paths. MPLS allows service providers to control
the path that the routed packets take, and can be used to optimize
network resources and/or improve performance for a subset of network
users. The traffic engineering can be coordinated with the core
backbone network to achieve end-to-end traffic guarantees. A future
promise for MPLS is to permit real-time upgrades of service quality
based on congestion feedback. For example, if a given path were
congested, all traffic would be diverted to another path.
 MPLS for Traffic Control 7-13
ERX Edge Routers

ERX System ERX System

Gold Path
“Gold” user
“Gold” destination

Best Effort Internet

“Best-Effort” user
Path

Core Router “Best-Effort” destination

Figure 7-5 Unisphere MPLS Use for Traffic Engineering

In Figure 7-5, the ERX system is used to classify the incoming

subscriber traffic and apply the appropriate MPLS label for “Gold path”
or “best effort path.” Depending on the applied label, the path taken
through the network will vary. The core routers will use the label, not
the underlying IP header information, to make forwarding decisions. In
this way, the traffic can be engineered to travel over a certain
predictable path. The MPLS paths are preconfigured as part of the
network configuration, and each path can be engineered with varied
bandwidth or latency guarantees.
The ERX platform’s unique hardware and software architecture
supports full-performance, flexible QoS assignment. Any of the
following classifications can be used to map the incoming flows into
MPLS paths:
• Layer 3/layer 4 Flow: Use the packet information from
Layer 3/layer 4 to assign the label-switched path (LSP)
• IP network prefix: Use the network source address to assign the LSP
• IP destination address: Use the IP address to forward the packet into
the associated LSP
The ERX system supports a number of key features that allow service
providers to implement MPLS in their network. See Table 7-6.
7-14 CHAPTER 7
Applications Overview

Table 7-6 ERX System Features and Service Provider Benefits for MPLS for Traffic
Engineering

ERX System Feature Service Provider Benefit

MPLS labeling combined with fine-grained •
IP QoS classification
Wire-speed packet processing on all
interfaces with ERX system ASIC
technology
Ability to support logically separate virtual
routers within a single chassis
Detailed statistics gathering for each
subscriber and for each service
Allows incoming packets to be
mapped to MPLS paths with a wide
range of classification options
• Enables an edge device to classify
and mark packets for proper handling
by network core
Enables wire-speed packet processing to
deliver reliable QoS performance
Allows service providers to securely route
traffic targeted at different destinations
(corporate VPN vs the Internet)
Provides statistical information critical to
network engineering design, build-out,
and ongoing modifications

MPLS for VPNs

Another use for MPLS is to create IP-based VPNs: secure, logically
partitioned private IP networks provisioned over a common, shared IP
infrastructure. MPLS can provide the scaling, address management,
QoS, security, reliability, and standards compliance required for VPN
building. In this application, MPLS is used to map incoming traffic,
based on the fields in the IP header or the source IP interface, onto
specific MPLS-labeled paths across the backbone network. By mapping
users to specific paths, service providers can isolate traffic between
VPNs, providing the secure, reliable, and predictable behavior necessary
to support VPN services. If the network needs to be re-engineered to
maintain VPN support, the paths are moved.
In effect, the MPLS paths create “tunnels” through the network. The
routers need to examine only the MPLS label to determine the packet
path. This feature allows MPLS to alleviate the overlapping IP address
problems often found in the creation of VPNs.
 MPLS for VPNs 7-15
ERX Edge Routers

ERX System ERX System

Corp A Path
Corp A Access
Network Corp A
Provider Corp B Path

Core Router

Corp B Service
Corp B
Network
Provider

Figure 7-6 Unisphere MPLS Use for VPNs

As shown in Figure 7-6, the ERX system classifies the incoming packet
and applies the appropriate MPLS VPN label at the network’s edge,
where the subscriber packet first enters the service provider network.
The traffic between the Corp A users and the Corp B users can be
transported on separate paths through the network, guaranteeing secure
operations and predictable performance. In addition, the MPLS label
also optionally reserves bits to be used for QoS settings. These can be
used to apply QoS parameters to the VPN path.
The ERX system supports a number of key features that allow service
providers to implement MPLS in their network. See Table 7-7.

Table 7-7 ERX System Features and Service Provider Benefits for MPLS for VPNs

ERX System Feature Service Provider Benefit

MPLS labeling combined with fine-grained •
IP QoS classification
Wire-speed packet processing on all
interfaces with ERX ASIC technology
Ability to support logically separate virtual
routers within a single chassis
Detailed statistics gathering for each
subscriber and for each service
Allows incoming packets to be
mapped to MPLS paths with a wide
range of classification options
• Enables the edge device to classify
and mark packets for proper handling
by network core
Enables wire-speed packet processing to
deliver reliable QoS performance
Allows service providers to securely route
traffic targeted at different destinations
(such as Corporate A vs Corporate B)
Provides statistical information critical to
network engineering design, build-out,
and ongoing modifications
7-16 CHAPTER 7
Applications Overview

SLA Support
As service level agreements (SLAs) increasingly become a standard
request from subscribers, service providers must be able to offer 100
percent uptime guarantees, with money-back penalties in cases of
failure or noncompliance. In addition, the service provider must be able
to demonstrate service quality to the subscriber in terms of reports and
real-time access. The ERX system supports a number of key features
that allow service providers to confidently offer SLAs to their
subscribers. See Table 7-8.

Table 7-8 ERX System Features and Service Provider Benefits for SLAs

ERX System Feature Service Provider Benefit

Midplane architecture and 100% • Allows for continuous operation even in failure
redundancy on all active cards conditions
• No cables to change means no technician
intervention to maintain operation
Hot-swap capability on all active In case of failure, new modules can be inserted
line modules quickly without disrupting overall system operation.
Passive midplane and adapter Minimizes need to replace these components;
modules therefore, minimal need to move cables
Modular software design Upgrades on individual software components can
be performed with minimal impact on subscriber
traffic.
Fine-grained statistics gathering Allow statistics to be shared with subscribers to
for each subscriber and for each show service- level performance
service
CNM-architectured NMS Allows service providers to share information with
subscribers in real-time
Sophisticated QoS policy control Guarantees that subscribers’ QoS settings are
maintained

Non-IP Protocol Applications

Although the ERX system is optimized for IP traffic handling, there are
two strategies to handle non-IP based packets:
• Apply MPLS labels to establish “tunneled” paths through the
network. This allows non-IP protocols to be carried via MPLS. The
MPLS label can be assigned to the packet based on the ingress or
egress interface.
• Use the ERX system to offload the IP traffic from older
performance-limited routing products. This allows the service
 VoIP Transport 7-17
ERX Edge Routers

provider to implement competitive, new IP-based policies to

capture IP subscribers, while still meeting the needs of existing
non-IP protocol customers.

VoIP Transport
The ERX system supports sophisticated QoS functionality that allows
service providers to deliver tiered service levels to their subscribers.
Tiered services offer different plans for different types of subscribers
(Gold, Silver, Bronze) or plans that differentiate different traffic types
(voice vs data). Figure 7-7 shows how separate data and voice services
can be delivered with a single ERX system. The ERX system can
distinguish different applications as they enter the service provider edge
network. Voice traffic can be treated as a priority, with corporate data
and consumer data taking second and third place.

Voice call

Consumer
data
To backbone

Corporate
data
ERX System

Traffic is prioritized:
• Voice
• Corporate Data
• Consumer Data

Figure 7-7 ERX System Guarantees Voice over IP (VoIP) Traffic Delivery

As packets enter the ERX system, they can be classified by any field in
the IP header. This allows traffic to be separated by application. As
shown in Figure 7-7, the traffic that enters the network can be classified
by the ERX system, and different traffic types are given different
treatment.

Note: The ERX system can be configured to honor packet classifications based on
DS fields or MPLS labels if these are already set by CPE devices.

Once the packet is classified as voice over IP (VoIP), priority treatment

can be guaranteed through the ERX system. For example, a specified
7-18 CHAPTER 7
Applications Overview

latency can be guaranteed for VoIP packets classified as premium traffic,

and a guarantee on uplink bandwidth can be made. As traffic leaves the
ERX system, it can be stamped with a DS byte, or an MPLS label can
be added. This indicates to the core network that the packet should
receive priority treatment.
The ERX system supports a number of key features that are critical for
priority traffic handling, as listed in Table 7-9.

Table 7-9 ERX System Features and Service Provider Benefits for VoIP

ERX System Feature Service Provider Benefit

Wire-speed packet
processing
Support for 64,000
simultaneous queues
QoS resource guarantees
Classification based on IP
header fields or DS byte
Virtual router support
Packet marking (DS or
MPLS)
Support for both strict-priority Supports guaranteed latency through the ERX system
and rate-based scheduling
Weighted scheduling
Allows QoS guarantees to be established. Without
wire-speed processing, no QoS can be supported,
since packets are queued before classification; this
eliminates preferential treatment for priority packets.
All user flows can receive individual, protected queues
to guarantee QoS settings.
System resources and uplink bandwidth can be
dedicated to varied service classes, reserving and
protecting them for premium services.
Allows service providers to classify traffic based on
application or to honor DS bits set by CPE devices
Allows service providers to dedicate a separate logical
router for higher-priority traffic
Allows service providers to establish a premium policy
at the edge of the network and properly mark the
packet for treatment by the core device
Supports tiered service offerings

Wholesaling
Many service providers lease portions of their facilities to other carriers;
this practice is known as wholesaling. Strategies vary by service
providers. Some offer “dark fiber” itself; others offer equipment; still
others offer services that can be resold. The ERX system can offer
wholesaling strategies where facilities-based service providers want to
lease POP capacity to downstream carriers. As shown in Figure 7-8, a
facilities-based service provider can use the ERX system to offer
wholesale services to carrier partners.
 Wholesaling 7-19
ERX Edge Routers

Facilities Provider Carrier Subscriber

ISP A
DiffServ

ERX System

MPLS Path
ISP B

ATM PVC

ISP C

Figure 7-8 ERX System Supports Wholesaling Applications

The services can be delivered over a number of line speeds, including

nxT1, DS3, E3, OC3/STM1, and OC12/STM4, and a number of
protocols, including PPP, FR, ATM, or POS.
With its support for virtual routers, the ERX system can allocate a
completely logically separate router for each carrier subscriber. Each
router can have its own route table information, as well as its own
protocols. For the facilities-based provider, this means a single ERX
system can support a variety of routers and route policies.
The ERX system can also support varied QoS policies for each carrier
subscriber. This feature allows all providers to deliver QoS policies to
their enterprise subscribers. Three options are shown in Figure 7-8:
ISP A is using DiffServ to vary packet treatment; ISP B is using MPLS;
and ISP C is using ATM PVC transport. The facilities-based provider
can differentiate the packets and mark them with the appropriate QoS
setting so that the rest of the network can process them accordingly.
The ERX system also supports policy control so that the facilities-based
provider can protect itself from poor route distribution from its peers or
subscribers.
The ERX system supports a number of key features that are critical for
wholesaling applications as in Table 7-10.
7-20 CHAPTER 7
Applications Overview

Table 7-10 ERX System Features and Service Provider Benefits for Wholesaling

ERX System Feature Service Provider Benefit

High-capacity physical and logical Allows one ERX system to be shared cost
density with support for thousands effectively between multiple carrier subscribers
of interfaces in a single unit
Carrier-class reliability Allows SLAs to be offered to carrier subscribers
and also passed onto their enterprise customers
IP QoS capabilities Packets can be marked with DS or MPLS or
dedicated to an ATM PVC to support end-to-end
QoS policies for any carrier subscriber QoS
implementation.
Virtual router support Allows service providers to target different
destinations for incoming subscribers, such as ISP
A vs ISP B
Support for a variety of line • Supports all carrier subscriber environments
speeds (DS0-OC12) and with a single unit
protocols (PPP/FR/ATM/POS) • Allows partners to sell a variety of services
and/or remain compatible with existing
infrastructures

End-to-End QoS
For a service provider to offer differentiated service levels, the entire
network must be able to support and enforce QoS policies. End-to-end
QoS can be supported in a multivendor environment with
standards-based adherence. Figure 7-9 shows how QoS can be
implemented over an entire network.
 End-to-End QoS 7-21
ERX Edge Routers

Edge LAN Edge WAN Core Edge WAN Edge LAN

ERX System ERX System

FT1, DS3
FT1, DS3
OC3, DS3

POS

ATM
ERX System ERX System

Fine QoS QoS GW ToS QoS QoS GW Fine QoS

Figure 7-9 End-to-End QoS Implemented over Entire Network

Each section of the network is responsible for a different QoS

granularity. At the CPE, QoS is assigned on an individual and/or
application basis, with focus on delivering the most important traffic
into the network over the typically bandwidth-constrained, expensive
WAN pipes.
At the edge of the network, QoS policies are assigned by the service
provider via the ERX system. These policies enforce QoS profiles for
groups of subscribers relative to each other or for groups of applications
relative to each other. Subscribers with premium QoS service plans
receive more system resources or uplink bandwidth, or both. At the
edge, oversubscription is typical, so subscribers will be in contention
for resources. With QoS classification, the premium customers will
receive premium treatment relative to other subscribers. Without QoS
capabilities, all customers receive resource allocation in direct relation
to how much traffic they send, not how much they deserve. The ERX
system also tags the packets for proper treatment by the core.
In the core of the network, the routers and switches are concerned
with maximum speed. Millions of customer flows are processed per
second. QoS service is handled in terms of service classes, such as DS
byte settings, or MPLS paths, or ATM traffic type. The core handles
the service class, making sure that premium classes receive premium
treatment.
7-22 CHAPTER 7
Applications Overview

As traffic is handed back to the edge and CPE device, QoS policies can
be applied again at the subscriber and individual user levels. The
resulting coordination between the different elements allows for
end-to-end QoS to be delivered to the subscriber.
The ERX system supports a number of key features that are critical for
end-to-end QoS delivery. These features are listed in Table 7-11.

Table 7-11 ERX System Features and Service Provider Benefits for End-to-End QoS

ERX System Feature Service Provider Benefit

Standards-based compliance Allows for multivendor QoS implementation using
with DiffServ and MPLS best-of-breed products
Wire-speed packet Allows QoS guarantees to be established. Without
processing wire-speed processing, no QoS can be supported,
since packets are queued before classification; this
eliminates preferential treatment for priority traffic.
Support for 64,000 Allows all user flows to receive individual, protected
simultaneous queues queues to guarantee QoS settings
QoS resource guarantees System resources and uplink bandwidth can be
dedicated to varied service classes, reserving and
protecting them for premium treatment traffic.
Classification based on IP Allows service providers to classify traffic based on
header fields source or destination address to assign QoS profiles
and direct traffic to varied destinations
Virtual router support Allows service providers to dedicate a separate,
secure, logical router to different service providers’
traffic
Packet marking (DS or Allows service providers to establish a QoS policy at
MPLS) the edge of the network and properly mark the packet
for treatment by the core

VLAN Implementation

The Unisphere ERX system offers a significant advantage to service

providers who use its powerful virtual LAN (VLAN, IEEE 802.1q)
capabilities. VLANs offer service providers the ability to logically
segregate subscribers and their traffic on a shared interface, such as
Gigabit Ethernet or Fast Ethernet.
VLANs are used in the access network as well as in the core network.
The most common scenario in the access network is “fiber to the curb”
(FTTC). In this scenario, Ethernet runs all the way from the edge
router (B-RAS) to the subscriber. Typically, an Ethernet switch,
installed in the basement of a multitenant unit (MTU), tags the
 Fixed Wireless Applications 7-23
ERX Edge Routers

Ethernet frames of each customer before passing them onto the edge
router. On the downlink, the Ethernet switch directs the tagged
Ethernet frames to the port that corresponds with the VLAN ID.
Ethernet frames and broadcast packets remain in the same VLAN and
cannot be seen by other VLANs.
On the Ethernet uplink facing the core network, VLANs are
commonly used to logically segregate the traffic destined for services or
service providers. VLANs are typically deployed in a hosted service
environment. The access service provider (ASP) can maintain a single
and shared infrastructure for a variety of wholesale customers and
applications without compromising SLA.
Figure 7-10 shows the ERX system in a VLAN application.

Access

Gigabit Ethernet
IP Edge
IP Core ASP A
ERX
VLAN 1 VLAN 5
ASP B
IP/ETH VLAN 6
PPPoE
VLAN 7
Ethernet VLAN 2 ISP B
Switch
(VLAN tagged)

Policies
RADIUS
(COPS, LDAP)
DHCP

Figure 7-10 VLAN Application with the ERX System

Fixed Wireless Applications

Fixed wireless applications refer to the operation of wireless devices in
homes and offices, and in particular, equipment connected to the
Internet via specialized modems. Common examples of wireless
equipment in use today include cordless phones (not to be confused
with cell phones), satellite television, and wireless LANs.
The ERX product family is the first fixed-wireless local loop (WLL)
subscriber-access platform to deliver the performance, density, and
scalability for comprehensive IP service delivery in large-scale fixed-
wireless deployments. The ERX platform combines subscriber-access
functions with Tier-1-class routing and innovative IP QoS to enable
7-24 CHAPTER 7
Applications Overview

service providers to offer and deliver new, competitive IP services to

their fixed-wireless subscribers.
Deployed by carriers in the central office or by service providers at a
POP, the ERX transparently aggregates data traffic from multiple base
stations (BSs) to vendor-specific fixed-wireless implementations.
Point-to-multipoint and WLL BS implementations based on
multi-channel multipoint distribution system (MMDS), local
multipoint distribution system (LMDS) and wireless LAN (WLAN) can
all be terminated using industry standard remote-access protocols such
as PPP and RADIUS. Direct connections from BSs or ATM, Frame
Relay, or Ethernet aggregation switches (over SDH rings) are
supported with E3/T3, OC-3/STM-1, OC-12/STM-4, and Fast
Ethernet/Gigabit Ethernet (FE/GE) links. The output (egress) of the
ERX platform is typically a high-speed link, such as OC-3/STM-1,
OC-12/STM-4 and GE, to feed a core backbone.
In contrast to other products, the ERX system is a complete
subscriber-access platform, providing both subscriber-access services as
well as service profiles and IP-network routing. The ERX terminates
the connection, manages the subscriber, applies IP services and routes,
or forwards the traffic to the core. The ERX system handles all critical,
fixed-wireless IP-edge functions as well as new and advanced features,
including:
• PPP session termination and authentication via PAP or CHAP
• IP address assignment via DHCP, RADIUS, or local IP address
pools
• Accounting data support via RADIUS to gather detailed billing
information and bulk statistics via FTP
• Association of the subscriber with the service profile information
via RADIUS server, domain name, or sophisticated packet
classification
• Routing of session packets into the network via ATM, Frame Relay,
IP- or PPP-based tunnels, or POS to the destination defined in the
service profile.
Index

A configuration
command line interface for 4-9
AAL5 layer (ATM) 3-20 preconfiguration services 6-2
access and uplink methods 7-2 system configuration storage 5-8
access lists 3-31 CT3 modules
accounting 5-1 to 5-8 line rates supported 3-22
aggregation. See edge aggregation applications loopback tests 5-4
architecture of ERX system 2-2 customer support 6-2
ASIC technology 1-7, 2-4
chip sets 2-4
ATM interfaces 3-18 to 3-21
D
ATM MIBs 4-6 data flow 2-3
availability 1-8 dedicated system resources 3-2
density, port 1-7
B DHCP (Dynamic Host Configuration Protocol)
local server 3-64, 3-65, 3-66
bandwidth, tiered options for 1-9 diagnostics 5-2 to 5-5
BGP multicasting 3-44 DiffServ standards 1-18
BGP-4 support 3-33 dimensions of ERX chassis 2-8
Border Gateway Protocol (BGP-4) 3-33 Distance Vector Multicast Routing Protocol
B-RAS applications 3-59 to 3-61, 7-4 to 7-7 (DVRMP) 3-43
Broadband Remote Access Server. See B-RAS distributed software architecture 3-2
bundle distribution lists 3-32
MFR 3-18 documentation set, Unisphere xiii
MLPPP 3-14 CD xiv
CD, using the xiv
C comments on xv
DSLAM aggregation 1-12, 7-4 to 7-7
CD, documentation CD xiv DVRMP (Distance Vector Multicast Routing
using the xiv Protocol) 3-43
channelized E1 modules 2-14 dynamic interfaces 3-57
channelized OC12/STM4 modules 2-17
channelized OC3/STM-1 modules 2-15
channelized T1 modules 2-14 E
channelized T3 modules 2-15 E1 modules 2-14
chassis, ERX system 1-2 line rates 3-22
chip sets, ASIC 2-4 E3 modules 2-14
Cisco HDLC 3-21 line rates 3-22
classification of packets 3-7 edge aggregation applications 1-5, 1-11
CLI (command line interface) 4-9 to 4-10 private line aggregation 1-11, 7-2 to 7-4
external scripting 4-10 xDSL session termination 1-12, 7-4 to 7-7
security 4-13 EdgeControl management application
command line interface. See CLI security 4-14
components of ERX system 1-4 educational services 6-2
EEPROMs 5-2
 2
Index

egress forwarding ASIC 2-4 H

electrical input 2-8
e-mail support 6-3 hardware assist 2-5
end-to-end QoS 7-20 to 7-22 hardware of ERX system 1-9, 2-1 to 2-21
enduring IP address 3-64 chassis 2-7
Enterprise MIB 4-8 failure replacement services 6-3
ERX system power system 2-8
applications supported 7-1 to 7-22 SRP module architecture 2-9 to 2-12
chassis 1-2, 2-7 system modules architecture 2-9 to 2-21
components of 1-4 upgrades 5-7
hardware 1-9, 2-1 to 2-21 HDLC parameters 3-24
interface types 1-6 HSSI module 2-18
international standards compliance 1-18 HTTP local server 3-65
network management 1-10, 4-1 to 4-14
product description 1-1 I
scripting language 4-10
ICMP (Internet Control Message Protocol) 3-9
software 1-9, 3-1 to 3-61
IEEE 802.1q 1-16, 3-69, 7-22
startup 5-7
strengths of 1-6 IETF standards support 1-18
IGMP (Internet Group Management
upgrades 5-7
Protocol) 3-42
ERX-1400 model 1-2
airflow design 2-8 ingress forwarding ASIC 2-4
Intermediate System to Intermediate System
fan tray assembly 2-8
(IS-IS) 3-34
specifications 2-7
ERX-700 model 1-3 international standards compliance 1-18
Internet Group Management Protocol
airflow design 2-8
(IGMP) 3-42
fan tray assembly 2-8
specifications 2-7 IP addresses
enduring 3-64
Ethernet modules 2-17
token 3-64
ETSI standards 1-18
event logging 5-3 IP MIBs 4-7
IP multicasting 3-41
external scripts (command line interface) 4-10
IP protocol
profile 3-11
F IP protocol support 3-9 to 3-21
fabric board (SRP modules) 2-11 IP over SONET 3-24
functions of 2-11 IP/ATM 3-18 to 3-21
factory warranty 6-1 IP/FR 3-14 to 3-17
fan tray assembly 2-8 IP/MFR 3-18
fans IP/MLPPP 3-14
redundancy 2-8 IP/PPP 3-11 to 3-13
Field Programmable Gate Arrays (FPGAs) 2-4 QoS 1-9, 2-3
field replacement units (FRUs) 6-3 stack architecture 3-10
filtering event log data 5-3 IPSec tunnel server module 2-18
filters for packet classification 3-7 IS-IS protocol support 3-34
fixed wireless 1-17, 7-23
FPGAs (Field Programmable Gate Arrays) 2-4 L
Frame Relay (FR) interfaces 3-14 to 3-17
L2F (Layer Two Forwarding) 3-68
Frame Relay MIBs 4-6
FRUs (field replacement units) 6-3 L2TP (Layer Two Tunneling Protocol) 3-67
layer 2 interface statistics 5-2
 3
ERX Edge Routers

Layer Two Forwarding (L2F) 3-68 models, ERX system 1-2

Layer Two Tunneling Protocol (L2TP) 3-67 modularity 1-9, 3-2
LCP (Link Control Protocol) 3-14 module identifiers 5-2
Line Build Outs 2-19, 2-20 monitoring 5-2 to 5-5
line build outs 2-19 command line interface for 4-9
line modules MP. See MLPPP
capacity of ERX chassis 1-2 MPLS labeling 1-18, 3-37, 7-12 to 7-15
channelized E1 2-14 for VPNs 7-14 to 7-15
channelized OC12/STM4 2-17 Multilink Frame Relay (MFR) interfaces 3-18
channelized OC3/STM-1 2-15 Multilink Frame Relay. See MFR
channelized T1 2-14 Multilink PPP protocol support 3-14
channelized T3 2-15 Multilink PPP. See MLPPP
Ethernet 2-17 multiprocessor architecture 2-2
FPGAs and RISC processors 2-4 Multiprotocol Label Switching (MPLS) 1-18,
future models 2-21 3-37, 7-12 to 7-15
HSSI 2-18
identifiers (EEPROMs) 5-2 N
IPSec tunnel server module 2-18
line rates supported 3-22 NEBS standards 1-18
protocols supported 1-6 network interface statistics 5-2
ranges 2-19 network management 1-10, 4-1 to 4-14
redundancy 2-6 command line interface (CLI) 4-9 to 4-10
redundancy features 2-6 security 4-12
TSM 2-18 SNMP protocol support 4-4 to 4-7
Tunnel-Service 2-18 network statistics. See statistics
unchannelized E3 2-14 non-IP packet handling 7-16
unchannelized OC12/STM4 2-16 non-PPP equal access
unchannelized OC3/STM1 2-15 overview 3-64 to 3-67
unchannelized T3 2-14 NVS software component 5-8
X.21/V.35 2-18
line rates 3-22 to 3-24 O
LLC layer (ATM) 3-20
LMI (local management interface) 3-17 OC12/STM4 modules 2-16, 2-17
Local management interface (LMI) 3-17 OC3/STM-1 modules 2-15
logging 5-3 operational software image 5-7
loopback tests 5-4 OSPF protocol support 3-36
lower-speed line modules, redundancy 2-6
P
M packet classification 3-7
management, network. See network management packet policies 3-5 to 3-9
manuals, Unisphere xiii packet QoS settings 1-9, 2-3
comments on xv end-to-end QoS 7-20 to 7-22
on CD xiv wholesaling 7-19
MFR packets, non-IP 7-16
bundle 3-18 passive midplane design 2-6
overview 3-18 performance
MLP. See MLPPP line rates 3-22 to 3-24
MLPPP 3-14 to ?? reliability and availability 1-8
bundle 3-14 SLAs (service level agreements) 7-16
 4
ERX Edge Routers

system design and 2-3 RISC processors 1-7, 2-4

See also traffic flow route maps 3-31
PIM (Protocol Independent Multicast) 3-42 routing 3-28 to 3-34
policies architecture 3-29
packet 3-5 to 3-9 BGP-4 support 3-33
SLAs (service level agreements) 7-16 IS-IS protocol 3-34
policy-based QoS 1-9, 2-3 MPLS labeling 1-18, 3-37, 7-12 to 7-15
end-to-end QoS 7-20 to 7-22 OSPF protocol support 3-36
wholesaling 7-19 RIP support 3-37
port density 1-7 route control 3-31
ports, access/uplink capability 7-3 speed of 2-3
power system 2-8 routing switches, in general 1-5
PPP (Point-to-Point Protocol)
network control protocol 3-14 S
PPP Multilink. See MLPPP
PPP protocol support 3-11 to 3-13 scripting language of ERX system 4-10
preconfiguration services 6-2 scripts (command line interface) 4-10
pricing, tiered options for 1-9 security
prioritizing traffic 1-9 network management architecture 4-12
by application 7-17 to 7-18 VPNs and 7-8
private line aggregation 1-11, 7-2 to 7-4 service classes 1-9, 2-3
processor board (SRP modules) 2-11 end-to-end QoS 7-20 to 7-22
product upgrades 5-7 wholesaling 7-19
professional services 6-2 service level agreements (SLA) 7-16
Protocol Independent Multicast (PIM) 3-42 SHOW commands 4-9
protocols diagnostics 5-5
diagnostics 5-4 SLA support 7-16
ERX interface types with 1-6 slots available in ERX chassis 1-2, 2-7
xDSL, supported 1-13, 7-6 SMDS
components 3-28
Q overview 3-26
requirements and restrictions 3-28
QoS 1-9, 2-3, 3-44 to 3-54 SNMP protocol support 4-4 to 4-7
end-to-end QoS 7-20 to 7-22 security 4-13
wholesaling 7-19 traps 4-5
Quality of Service (QoS) 3-44 to 3-54 software 1-9, 3-1 to 3-61
architecture 3-2
R ATM features 3-19
B-RAS applications 3-59 to 3-61
ranges ERX system features 3-3
line modules 2-19 Frame Relay features 3-15
redistribute routes 3-32 IP features 3-9
Redstone Enterprise MIB 4-8 line rates 3-22 to 3-24
redundancy features (hardware) 2-6 NVS software component 5-8
fans 2-8 routing support 3-28 to 3-34
line access modules 2-6 SONET features 3-24
reliability 1-8 traffic and. See traffic flow
replacement hardware availability 6-3 update services 6-2
resources, dedicated 3-2 upgrades 5-7
RIP protocol support 3-37 SONET interface 3-24
 5
ERX Edge Routers

SRP modules troubleshooting

diagnostic test control 5-4 command line interface for 4-9
key functions and specifications 2-9 to 2-12 monitoring and diagnostics 5-2 to 5-5
NVS software component 5-8 TSM modules 2-18
redundancy scheme 2-6 tunnel server modules 2-18
routing architecture 3-29 Tunnel-Service modules 2-18
slots available for 2-7, 2-9
system startup 2-12 U
SSC (Service Selection Center) 3-65, 3-66
stability of software design 1-9 UMC application overview 4-22 to 4-27
standards support 1-18 unchannelized E3 modules 2-14
startup of ERX system 2-12, 5-7 unchannelized OC12/STM4 modules 2-16
statistics 5-1 to 5-8 unchannelized OC3/STM-1 modules 2-15
PPP layer 3-13 unchannelized T3 modules 2-14
SONET architecture 3-25 unchannelized T3/E3 modules
Switched Multimegabit Data Service. See SMDS line rates supported 3-22
switching fabric of SRP modules 2-11 Unisphere documentation set xiii
functions of 2-11 CD xiv
system CD, using the xiv
components 1-4 comments on xv
design (hardware) 2-3 Unisphere, contacting 6-3
system modules architecture 2-9 to 2-21 updating software 6-2
SRP modules 2-9 to 2-12 upgrades 5-7
See also line modules uplink methods 7-2
system resources 3-2 UT3 modules
system startup 2-12, 5-7 line rates supported 3-22

T V
T1 modules 2-14 virtual private networks. See VPNs
T3 modules 2-14, 2-15 virtual routers 3-32
TAC (Technical Assistance Center) 6-2 VLANs 1-16, 3-69, 7-22
Technical Assistance Center (TAC) 6-2 interface modes 3-70
technical support 6-2 voice traffic 7-17 to 7-18
telephone support 6-3 VoIP traffic 7-17 to 7-18
test patterns 5-5 VPNs (virtual private networks) 1-10, 7-7 to 7-9
tiered bandwidth and pricing options 1-9, 1-10 MPLS for 7-14 to 7-15
token IP address 3-64
traffic flow 3-5 to 3-9 W
MPLS for. See MPLS labeling
non-IP packet handling 7-16 warranty 6-1
packet classification 3-7 Web access to ERX system 3-65
prioritizing 1-9 Web site support 6-3
statistics. See statistics weights of ERX chassis 2-8
VoIP transport 7-17 to 7-18 wholesaling 7-18
transport protocols wireless 1-17, 7-23
diagnostics 5-4 wire-speed routing 2-3
ERX interface types with 1-6
xDSL, supported 1-13, 7-6
traps, SNMP 4-5
 6
ERX Edge Routers

X
X.21/V.35 module 2-18
xDSL
protocols 1-13, 7-6
session termination 1-12, 7-4 to 7-7