Shasta 5000 Broadband Service Node Concepts Guide, Release 4.0

Part No.
214659-B September 2003 600 Technology Park Billerica, Massachusetts 01821
Shasta 5000 Broadband Service Node Concepts Guide, Release 4.0
Copyright 2002 Nortel Networks

All rights reserved. September 2003. The information in this document is subject to change without notice. The statements, configurations, technical data, and recommendations in this document are believed to be accurate and reliable, but are presented without express or implied warranty. Users must take full responsibility for their applications of any products specified in this document. The information in this document is proprietary to Nortel Networks Inc. The software described in this document is furnished under a license agreement and may only be used in accordance with the terms of that license. The software license agreement is included in this document.
Trademarks
Nortel Networks, the Nortel Networks logo, the Globemark, Unified Networks, Contivity, Shasta, and other Nortel Networks trademarked product names are trademarks of Nortel Networks. Microsoft, Windows, and Windows NT are trademarks of Microsoft Corporation. Adobe and Acrobat Reader are trademarks of Adobe Systems Incorporated. Sun, Sun Microsystems, Java, Solaris, iPlanet, all trademarks and logos that contain Sun, Solaris, or Java, are trademarks or registered trademarks of Sun Microsystems, Inc. Solid Embedded Engine is a trademark of Solid. HP and OpenView are registered trademarks of Hewlett-Packard Company. LINUX is a registered trademark of Linus Torvalds. Pentium is a registered trademark of Intel Corporation. Red Hat is a registered trademark of Red Hat, Inc. UNIX is a registered trademark of X/Open Company Limited. The asterisk after a name denotes a trademarked item.
214659-B
Restricted Rights Legend

Use, duplication, or disclosure by the United States Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013. Notwithstanding any other license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the United States Government regarding its use, reproduction, and disclosure are as set forth in the Commercial Computer Software-Restricted Rights clause at FAR 52.227-19.
Statement of Conditions
In the interest of improving internal design, operational function, and/or reliability, Nortel Networks Inc. reserves the right to make changes to the products described in this document without notice. Nortel Networks Inc. does not assume any liability that may occur due to the use or application of the product(s) or circuit layout(s) described herein. Portions of the code in this software product may be Copyright 1988, Regents of the University of California. All rights reserved. Redistribution and use in source and binary forms of such portions are permitted, provided that the above copyright notice and this paragraph are duplicated in all such forms and that any documentation, advertising materials, and other materials related to such distribution and use acknowledge that such portions of the software were developed by the University of California, Berkeley. The name of the University may not be used to endorse or promote products derived from such portions of the software without specific prior written permission. SUCH PORTIONS OF THE SOFTWARE ARE PROVIDED AS IS AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. In addition, the program and information contained herein are licensed only pursuant to a license agreement that contains restrictions on use and disclosure (that may incorporate by reference certain limitations and notices imposed by third parties).
Nortel Networks Inc. Software License Agreement

This Software License Agreement (License Agreement) is between you, the end-user (Customer) and Nortel Networks Corporation and its subsidiaries and affiliates (Nortel Networks). PLEASE READ THE FOLLOWING CAREFULLY. YOU MUST ACCEPT THESE LICENSE TERMS IN ORDER TO DOWNLOAD AND/OR USE THE SOFTWARE. USE OF THE SOFTWARE CONSTITUTES YOUR ACCEPTANCE OF THIS LICENSE AGREEMENT. If you do not accept these terms and conditions, return the Software, unused and in the original shipping container, within 30 days of purchase to obtain a credit for the full purchase price. Software is owned or licensed by Nortel Networks, its parent or one of its subsidiaries or affiliates, and is copyrighted and licensed, not sold. Software consists of machine-readable instructions, its components, data, audio-visual content (such as images, text, recordings or pictures) and related licensed materials including all whole or partial copies. Nortel Networks grants you a license to use the Software only in the country where you acquired the Software. You obtain no rights other than those granted to you under this License Agreement. You are responsible for the selection of the Software and for the installation of, use of, and results obtained from the Software. 1.Licensed Use of Software. Nortel Networks grants Customer a nonexclusive license to use a copy of the Software on only one machine at any one time or to the extent of the activation or authorized usage level, whichever is applicable. To the extent Software is furnished for use with designated hardware or Customer furnished equipment (CFE), Customer is granted a nonexclusive license to use Software only on such hardware or CFE, as applicable. Software contains trade secrets and Customer agrees to treat Software as confidential information using the same care and discretion Customer uses with its own similar information that it does not wish to disclose, publish or disseminate. Customer will ensure that anyone who uses the Software does so only in
Shasta 5000 Broadband Service Node Concepts Guide
4
compliance with the terms of this Agreement. Customer shall not a) use, copy, modify, transfer or distribute the Software except as expressly authorized; b) reverse assemble, reverse compile, reverse engineer or otherwise translate the Software; c) create derivative works or modifications unless expressly authorized; or d) sublicense, rent or lease the Software. Licensors of intellectual property to Nortel Networks are beneficiaries of this provision. Upon termination or breach of the license by Customer or in the event designated hardware or CFE is no longer in use, Customer will promptly return the Software to Nortel Networks or certify its destruction. Nortel Networks may audit by remote polling or other reasonable means to determine Customers Software activation or usage levels. If suppliers of third party software included in Software require Nortel Networks to include additional or different terms, Customer agrees to abide by such terms provided by Nortel Networks with respect to such third party software. 2.Warranty. Except as may be otherwise expressly agreed to in writing between Nortel Networks and Customer, Software is provided AS IS without any warranties (conditions) of any kind. NORTEL NETWORKS DISCLAIMS ALL WARRANTIES (CONDITIONS) FOR THE SOFTWARE, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE AND ANY WARRANTY OF NON-INFRINGEMENT. Nortel Networks is not obligated to provide support of any kind for the Software. Some jurisdictions do not allow exclusion of implied warranties, and, in such event, the above exclusions may not apply. 3.Limitation of Remedies. IN NO EVENT SHALL NORTEL NETWORKS OR ITS AGENTS OR SUPPLIERS BE LIABLE FOR ANY OF THE FOLLOWING: a) DAMAGES BASED ON ANY THIRD PARTY CLAIM; b) LOSS OF, OR DAMAGE TO, CUSTOMERS RECORDS, FILES OR DATA; OR c) DIRECT, INDIRECT, SPECIAL, INCIDENTAL, PUNITIVE, OR CONSEQUENTIAL DAMAGES (INCLUDING LOST PROFITS OR SAVINGS), WHETHER IN CONTRACT, TORT OR OTHERWISE (INCLUDING NEGLIGENCE) ARISING OUT OF YOUR USE OF THE SOFTWARE, EVEN IF NORTEL NETWORKS, ITS AGENTS OR SUPPLIERS HAVE BEEN ADVISED OF THEIR POSSIBILITY. The forgoing limitations of remedies also apply to any developer and/or supplier of the Software. Such developer and/or supplier is an intended beneficiary of this Section. Some jurisdictions do not allow these limitations or exclusions and, in such event, they may not apply. 4.General a. If Customer is the United States Government, the following paragraph shall apply: All Nortel Networks Software available under this License Agreement is commercial computer software and commercial computer software documentation and, in the event Software is licensed for or on behalf of the United States Government, the respective rights to the software and software documentation are governed by Nortel Networks standard commercial license in accordance with U.S. Federal Regulations at 48 C.F.R. Sections 12.212 (for non-DoD entities) and 48 C.F.R. 227.7202 (for DoD entities). Customer may terminate the license at any time. Nortel Networks may terminate the license if Customer fails to comply with the terms and conditions of this license. In either event, upon termination, Customer must either return the Software to Nortel Networks or certify its destruction. Customer is responsible for payment of any taxes, including personal property taxes, resulting from Customers use of the Software. Customer agrees to comply with all applicable laws including all applicable export and import laws and regulations. Neither party may bring an action, regardless of form, more than two years after the cause of the action arose. The terms and conditions of this License Agreement form the complete and exclusive agreement between Customer and Nortel Networks. This License Agreement is governed by the laws of the country in which Customer acquires the Software. If the Software is acquired in the United States, then this License Agreement is governed by the laws of the state of New York.
b.
c.
d. e. f.
214659-B
Contents
Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Before you begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 New in this Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Text conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Printed Technical Manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 How to get help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Chapter 1 Emergence of the BSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Emergence of the broadband network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Bringing high-speed connectivity to the mass market . . . . . . . . . . . . . . . . . . . . . . . . . 25 The edge and the access layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 The Broadband Remote Access Server (B-RAS) . . . . . . . . . . . . . . . . . . . . . . . . . 26 Meeting the need for an intelligent access aggregator . . . . . . . . . . . . . . . . . . . . . . . . 28
Chapter 2 BSN: overview and features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

About the Broadband Service Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Shasta 5000 BSN services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Using firewalls for security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Shasta 5000 Broadband Service Node Concepts Guide
Contents Using firewalls for service differentiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Anti-spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Denial-of-service and the Shasta 5000 BSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Signature Recognition and Logging of Malformed Packets . . . . . . . . . . . . . . 41 Syn Flood Detection and Prevention through TCP Proxies and Splicing . . . . 42 Flow Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Authentication, Authorization, and Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Network Address Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Group NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Activity logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Content filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Cable deployment security considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Virtual Private Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Virtual Private Routed Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 MPLS and VRF-VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Virtual Leased Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Virtual Private Dial Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 About traffic management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Traffic policing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Traffic shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Policy-based forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 DiffServ marking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Application of traffic management and QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Personal Content Portals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Fully qualified domain names and realms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Realms and global roaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Roaming (and consistency with dial ISP models) . . . . . . . . . . . . . . . . . . . . . . . . . 66 Vanity domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 IP Demux and Ethernet access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Wholesaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Web steering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
214659-B
Contents
Chapter 3 Access technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

1483 (1490) Routed and 1483 (1490) Bridged . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 1483 Routed (1490 Routed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 1483 Bridged (1490 Bridged) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 About PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 PPPoE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 PPPoA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 MLPPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 MLPPP Auth bundles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 MLPPP No Auth bundles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 IP Demux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 L2TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Voluntary tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Compulsory tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Contivity VPN Client termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 ATMP foreign agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Control of VPRN dynamic routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 BGP configuration for VPRN subscribers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Chapter 4 Routing protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Routing on the access and trunk sides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Access side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Trunk side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 About routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Supported routing protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Routing Information Protocol (RIP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Open Shortest Path First (OSPF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Border Gateway Protocol (BGP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Intermediate System-Intermediate System (IS-IS) . . . . . . . . . . . . . . . . . . . . . . . 102
Contents
Chapter 5 Content technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Personal Content Portals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 How it works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Personal Content Portal SCS specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Content filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Offering content filtering as a value-added service . . . . . . . . . . . . . . . . . . . . . . . 110 Creating categories and customizing content-filtering offerings . . . . . . . . . . . . . 110 Authenticating subscribers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Filter service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Web steering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Proxy server high availability (failure handling) . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Adding or removing IP farm members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 IP farm sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Chapter 6 DSL aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

About DSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 About PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 PPPoA for direct host (PC) connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 DSL PPP sessions and L2TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Bridging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Problems inherent to bridging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Subscriber bridging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Bridge groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 The Shasta 5000 BSN and half bridging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Configuration of Independent bridged subnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Configuration of half bridging with static IP addressing . . . . . . . . . . . . . . . . . . . . . . . 131 Configuration of bridged PPPoE subscribers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Chapter 7 Virtual Private Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

VPNs supported by the Shasta 5000 BSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Virtual Private Routed Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 About Virtual Private Routed Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 214659-B
Contents DiffServ marking and VPRNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Dynamic VPRNs with intelligent meshing . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 IPsec tunnel support and VPRN scalability . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Factors affecting scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Security considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Example VPRN deployment constraints test . . . . . . . . . . . . . . . . . . . . . . . . 148 Test 1: Hard limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Test 2: Non-mesh tunnel test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Test 3: Routes and route sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Outcome and resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Virtual Private Routed Networks without Internet access . . . . . . . . . . . . . . . . . . 150 Virtual Private Routed Networks with Internet access . . . . . . . . . . . . . . . . . . . . . 151 MPLS and VRF-VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 VRF-VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Label Switched Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Label and packet header formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 MPLS signaling protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 E-LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 VRFs and sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Distribution of VPN routing information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Route target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Route target profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Route distinguisher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 MPLS forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Virtual Leased Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Virtual local area networks (VLANs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Contivity CES Server Farm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Virtual Private Data Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 How dynamic subscribers gain VPRN access . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Chapter 8 Cable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Cable modem deployments and the BSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
10
Contents About cable systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Cable modem infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Standardized cable system interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Cable headend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Cable modem environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Cable deployment access methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Bridged PPPoE client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Outsourced service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Multiple ISP contexts service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Layer 3 tunnel client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 IP Demux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Bridged CMTS with all subscribers belonging to a single ISP . . . . . . . . . . . 180 Bridged CMTS with subscribers belonging to different ISPs . . . . . . . . . . . . . 181 Routed CMTS with all subscribers belonging to a single ISP . . . . . . . . . . . . 183 Routed CMTS with subscribers belonging to different ISPs . . . . . . . . . . . . . 184 DHCP architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Chapter 9 Wholesaling and the Shasta 5000 BSN . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

About wholesaling and the Shasta 5000 BSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 L2TP tunneling based on the FQDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Outsource service using compulsory tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . 195 L2TP tunneling configuration and FQDN selection example . . . . . . . . . . . . . . . . 196 ISP context membership selection based on FQDN . . . . . . . . . . . . . . . . . . . . . . . . . 201 Using the Shasta 5000 BSN to operate multiple ISP routing contexts . . . . . . . . 201 Context selection based on FQDN example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 ISP membership based on DHCP service selection . . . . . . . . . . . . . . . . . . . . . . . . . 207 ISP membership based on IP Demux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Bulk connection configuration for domain groups . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Advanced wholesaling and vanity domain support . . . . . . . . . . . . . . . . . . . . . . . . . . 210 About wholesaling and vanity domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Vanity domain configuration using L2TP tunneling: examples . . . . . . . . . . . . . . 211 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 Vanity domain configuration using ISP context membership: examples . . . . . . . 212 214659-B
Contents
11
Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Advanced wholesaling using FQDN with realm support . . . . . . . . . . . . . . . . . . . . . . 213 Realms and dial ISP deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 Realms and dial with broadband RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 Realms and ISP equality for vanity domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 How the realm feature works on the Shasta 5000 BSN . . . . . . . . . . . . . . . . . . . 215 Activating the realm feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Authentication formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Authentication service process using service provider FQDN . . . . . . . . . . . 217 Authentication service process using service provider FQDN with defaulted domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Authentication service process using basic FQDN . . . . . . . . . . . . . . . . . . . . 218 Authentication service for unqualified user . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Example subscriber selection and steering using the realm feature . . . . . . . . . . 219
Chapter 10 Retailing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

Retailing the Shasta 5000 BSN services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Consolidating dial and DSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 Dial retail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 DSL retail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
List of Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
12
Contents
214659-B
13
List of Figures
Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 Figure 8 Figure 9 Figure 10 Figure 11 Figure 12 Figure 13 Figure 14 Figure 15 Figure 16 Figure 17 Figure 18 Figure 19 Figure 20 Figure 21 Figure 22 Figure 23 Figure 24 Figure 25 Figure 26 Figure 27 Figure 28 Universal aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Shasta 5000 BSN with per-subscriber firewall policies . . . . . . . . . . . . . . . 35 IP-VPN applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 VPRNs with and without Internet access . . . . . . . . . . . . . . . . . . . . . . . . . 55 Virtual Leased Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Personal Content Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Small business access using RFC-1483 Routed . . . . . . . . . . . . . . . . . . . 76 Dynamic RFC-1483 Bridged CPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Extending the PPP session across the subscribers Ethernet segment: PPPoE 81 PPP over L2TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Contivity VPN Client termination with a split tunnel configuration . . . . . . 91 Basic ATMP network configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Delivering customized content to subscribers . . . . . . . . . . . . . . . . . . . . 105 Personal Content Portal process flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Web steering service hashing function . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Single, direct host connectivity using PPPoA . . . . . . . . . . . . . . . . . . . . . 121 L2TP tunnels between multiple LACs and LNSs . . . . . . . . . . . . . . . . . . 124 Subscriber network with bridge and router . . . . . . . . . . . . . . . . . . . . . . . 126 Bridge groups and the Shasta 5000 BSN . . . . . . . . . . . . . . . . . . . . . . . . 128 Half bridging and the BSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Independent bridged subnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 CPE-based VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Network-based VPRN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Intelligent (partial) mesh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Full mesh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Subscriber service card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 VPRN alone (without Internet access) . . . . . . . . . . . . . . . . . . . . . . . . . . 151 VPRN plus Internet access support . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Shasta 5000 Broadband Service Node Concepts Guide
14 Figures Figure 29 Figure 30 Figure 31 Figure 32 Figure 33 Figure 34 Figure 35 Figure 36 Figure 37 Figure 38 Figure 39 Figure 40 Figure 41 Figure 42 Virtual Leased Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Contivity Server Farm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Integrated remote access scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Cable modem infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 PPPoE service selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Managed ISP contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Layer 3 client service selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 DHCP architecture with service selection . . . . . . . . . . . . . . . . . . . . . . . . 188 PPP sessions backhauled via L2TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 ISP service selection using L2TP tunneling and FQDN . . . . . . . . . . . . . 198 ISP context membership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Context selection based on FQDN example . . . . . . . . . . . . . . . . . . . . . . 203 ISP context membership assignment through DHCP . . . . . . . . . . . . . . . 208 ISP service selection using realm and domain FQDN-based example . 220
214659-B
15
List of Tables
Table 1 Table 2 Table 3 Table 4 Table 5 Table 6 Table 7 Table 8 Table 9 Table 10 Table 11 A typical security rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 DDOS attack definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 SCS: Mapping a public address to a private address . . . . . . . . . . . . . . . . 47 MLPPP End Point Descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Subscriber tunnels supported per resource . . . . . . . . . . . . . . . . . . . . . . 147 VPRN mesh tunnels supported per resource . . . . . . . . . . . . . . . . . . . . . 147 VPRN and Internet firewall policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 VPRN-only firewall policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Component description for ISP L2TP tunneling and FQDN example . . . 199 Components for context selection based on FQDN example . . . . . . . . . 204 Components for ISP service selection using realm and domain FQDN-based example 221
16
Tables
214659-B
17
Preface
This guide describes the networking environment for which the Nortel Networks* Shasta* 5000 Broadband Service Node (BSN) is designed, gives an overview of the technology and the tasks required for implementation, then explains the specific features used by the BSN to perform those tasks. This preface includes the following topics: Before you begin on page 17 New in this Document on page 17 Text conventions on page 19 Related publications on page 20 How to get help on page 22
Before you begin

This guide is intended for users provisioning a Shasta 5000 Broadband Service Node network using the SCS client. Prior knowledge of SCS software is not required. This guide assumes that you have the following background: Experience with window systems or graphical user interfaces (GUIs). Understanding of the transmission and management protocols used on your network. Basic understanding of the technology deployed with the Shasta BSN.
New in this Document

The following changes have been made to this document for this release:
18
Preface
This document has been updated to include concepts for the following features: MPLS MLPPP Flow Mirroring Contivity Client VPNs DDoS service References to Manufacturer Discontinued products have been removed.
214659-B
Preface
19
Text conventions
This guide uses the following text conventions: italic text separator ( > ) Indicates new terms, book titles, and Web addresses. Shows menu paths. Example: File > SCS Configuration identifies the SCS Configuration option in the File menu. Indicate that you choose the text to enter based on the description inside the brackets. Do not type the brackets when entering the command. Example: If the command syntax is ping <ip_address>, you enter
ping 192.32.10.12 bold Courier text
angle brackets (< >)
Indicates command names and options and text that you need to enter. Example: Use the debug portal command. Example: Enter show interface. Indicate required elements in syntax descriptions where there is more than one option. You must choose only one of the options. Do not type the braces when entering the command. Example: If the command syntax is
add loghost [server=]<addr> [[facility=]{local0,local1,local2,local3 , local4,local5,local6,local7}], you can
braces ({})
enter either
add loghost server=10.11.12.10 facility=local2 or add loghost server=10.11.12.10 facility=local3.
brackets ([ ])
Indicate optional elements in syntax descriptions. Do not type the brackets when entering the command. Example: If the command syntax is
add user [name=]<username> [epwd=<epwd>] [priv={U,SU,SSU}], you can enter add user name=james epwd=pword priv=u. Or you can enter add user james, leaving out the terms
shown in brackets.
20
Preface
italic text
plain Courier text
Indicates new terms or book titles Indicates command syntax and system output, for example, prompts and system messages. Example: Set Trap Monitor Filters Separates choices for command keywords and arguments. Enter only one of the choices. Do not type the vertical line when entering the command. Example: If the command syntax is
check sub [sub]=<subid>|sub=<subname> [isp]=<ispname>, you can enter check sub sub=345 isp=blue or check sub sub=james isp=blue.
vertical line ( | )
In command syntax the asterisk indicates that you can enter multiple instances of the preceding parameter.
Related publications
For more information about using SCS, refer to the following publications: Shasta 5000 Broadband Service Node, Concept Guide, Release 4.0 (part number 214659-B) Shasta 5000 Broadband Service Node Hardware Installation and Maintenance, Release 4.0 (part number 214660-B) Shasta 5000 Broadband Service Node Software Installation and Migration, Release 4.0 (part number 214661-B) Shasta 5000 Broadband Service Node Service Creation System (SCS), Release Notes, Release 4.0 (part number 214676-B Shasta 5000 Broadband Service Node IP Services Operating System (iSOS), Release Notes, Release 4.0 (part number 214677-B) Shasta 5000 Broadband Service Node, Getting Started with the Service Creation System (SCS), Release 4.0 (part number 214663-B) Shasta 5000 Broadband Service Node, SNMP Configuration Guide, Release 4.0 (part number 214667-B) Shasta 5000 Broadband Service Node, Provisioning Subscribers, Release 4.0 (part number 214664-B)
214659-B
Preface
21
Shasta 5000 Broadband Service Node, Provisioning Service Policies, Release 4.0 (part number 214665-B) Shasta 5000 Broadband Service Node, Provisioning VPNs, VLANs, and Tunnels, Release 4.0 (part number 214666-B) Shasta 5000 Broadband Service Node Command Line Interface Guide-Administration, Release 4.0 (part number 214668-B) Shasta 5000 Broadband Service Node Command Line Interface Guide -Protocols, Release 4.0 (part number 214669-B) Shasta 5000 Broadband Service Node CORBA API Applications Installation Guide (part number 214672-A) Shasta 5000 Broadband Service Node Service Creation System CORBA API Applications Guide (part number 214673-A) Shasta 5000 Broadband Service Node Personal Content Portals Installation Guide, Release 4.0 (part number 214671-A) Shasta 5000 Broadband Service Node Personal Content Portals Implementation Guide, Release 4.0 (part number 214671-A) Shasta 5000 Broadband Service Node, Troubleshooting Guide, Release 4.0 (part number 214670-B)
Printed Technical Manuals

You can print selected technical manuals and release notes free, directly from the Internet. Go to the http://nortelnetworks.com/documentation URL. Find the product for which you need documentation. Then locate the specific category and model or version for your hardware or software product. Use Adobe Acrobat Reader to open the manuals and release notes, search for the sections you need, and print them on most standard printers. Go to the Adobe Systems URL at www.adobe.com to download a free copy of Acrobat Reader. You can purchase printed books and documentation sets from Vervante. To order printed documentation, go to Vervante at the www.vervante.com/nortel URL.
22
Preface
How to get help

If you purchased a service contract for your Nortel Networks product from a distributor or authorized reseller, contact the technical support staff for that distributor or reseller for assistance. If you purchased a Nortel Networks service program, contact one of the following Nortel Networks Technical Solutions Centers:
Technical Solutions Center Europe, Middle East & Africa (EMEA) Sydney, Australia Tokyo, Japan Billerica, MA Santa Clara, CA Telephone 00800-8008-9009 61-2-8870-8800 0120-382-533 800-4NORTEL (800-466-7835) 800-4NORTEL (800-466-7835)
214659-B
23
Chapter 1 Emergence of the BSN

This chapter describes the networking environment in which the Nortel Networks Shasta 5000 Broadband Service Node (BSN) emerged in response to the requirements of service providers desiring to better meet the needs of the new mass market user and the corporate enterprise user. As networking use increased and evolved in complexity with the needs of telecommuters and a mobile work force, corporate enterprises sought to outsource some of their networking infrastructure and management requirements to constrain overhead and costs. The mass market user whose needs were addressed by a service provider, such as an Internet service provider (ISP), sought broadband access to the network at affordable cost. Existing subscriber aggregation technologies satisfied neither of these requirements. Rather, a new technology was in demand. This chapter explores the background against which the Shasta 5000 BSN emerged. It includes these sections: Emergence of the broadband network next Bringing high-speed connectivity to the mass market on page 25 Meeting the need for an intelligent access aggregator on page 28
Emergence of the broadband network

The early networking industry emerged to serve MIS and IS organizations within large companies. These organizations perceived the network as infrastructure to be integrated within the corporation. With rapid Internet growth, a new network user outside the corporation emergedthe mass market network customer. In response, the networking environment giving access to the Internet burgeoned to encompass service of this new network customer. At the same time, corporations
24
began to perceive the value in outsourcing some of their intranet requirements that is, their private network requirements as well as their Internet service requirements to wholesalers. Additionally, corporations began to support increasingly more telecommuter and traveler employees. Customers comprising the mass market include residential users and home business users. Corporate telecommuters could also be considered as part of this group. These users take a different view of the network from that held historically by corporate enterprises. They see the network as a vehicle for delivering the services they require. They neither expect nor are willing to incorporate networking infrastructure and functionality within systems at their own locations. Despite their differing orientations toward the network, both categories of users the large corporation and the mass marketshare a common goal; they want rapid access to services at the network core. With the development of the Internet, powerful routers and switches running advanced protocols over high-speed linesprotocols such as IP over ATM, frame relay, and Packet-Over-SONET (POS)have been combined to comprise the backbone at the network core. These configurations enable a core transmission capacity increasing to speeds of 1.544 megabits per second (Mb/s), reaching even10 gigabits per second (Gb/s). Increased core speed advanced the state of the art, but only the large corporation could afford the cost of dedicated linesthat is, lines providing high-speed access to the core that kept apace with core bandwidth. Core speed without equivalent access speed did not improve throughput to the majority of users. Users comprising the mass market could expect at affordable cost dial-up access in the range of 1200 bits per second (b/s) to 56 kilobits per second (Kb/s). At most, mass market users could expect access at 128 Kb/s through use of the more expensive ISDN lines. Because no low-cost, high-bandwidth access was available for mass market use, a bandwidth barrier arose between mass market user access at the networks edge and the broadband capacity at the networks core. Regardless, users comprising the mass market required and desired high-speed access as the applications they ran and Internet services they relied on became more sophisticated, consuming more bandwidth. An IP broadband network evolved in response to this mass market user requirement for broadband access.
214659-B
25
The continuing emergence of the broadband network is ideally characterized as an IP Services Network (IPSN) with an optical core and advanced subscriber aggregation and value-added services provided by devices at its edge. The IPSN is intended to bring further intelligence and usability to the broadband network, delivering additional services that the mass market requires. A key component of the IPSN is the broadband service node, which is the subject of this planning guide.
Bringing high-speed connectivity to the mass market

What is broadband technology for the mass market? Simply defined, it is the provision of high-speed connectionstechnology transmitting more than 128 Kb/ sto mass market users at affordable prices. Digital subscriber lines (DSL), cable, and wireless media are technologies that give the subscriber access to the network core with the same amount of bandwidth available to the large corporation through T1 and T3 lines, but at a much lower price. These diverse broadband technologies bring with them new requirements that have come to redefine the technology operating at the network edge. Chief among these requirements are the following abilities: To aggregate connections and give access to subscribers coming into the network across diverse media To apply value-added services to individual subscriber traffic flows
Thus, devices have emerged to address the need for subscriber aggregation and application of value-added services at the networks edge.
The edge and the access layer

The network edge is the area where subscribers wanting services rendered by service providers access the network and its services. The primary activity that occurs at the network edge is physical aggregationthat is, bringing together many subscribers using diverse technologies to gain network access.
26
In networking topology, the access layer of a network is the locus where users seek access to the network; the hardware and software technology that operates within this layer provides that access. The access layer comprises subscriber management services: access, subscription management, and application of value-added services. Because it is here that subscribers seeking access to the Internet and its services first meet the network, this area of the edge is more specifically called the subscriber edge. The subscriber edge is: The single area of the network where a service provider has knowledge of a subscriber and control over that subscribers traffic. The sole and strategic point in the network where the service provider can provision subscriber traffic with special services, similar to the way telcos provision Centrex services within the central office.
Beyond the subscriber edge, traffic flows from multiple subscribers get aggregated over high-speed connections to backbone routers at the core. These routers lack visibility into individual subscriber traffic flows; therefore, they cannot provide individual subscriber services. New classes of devices deployed at the edge that shape the access layer have been developed to participate in the process of physically aggregating subscribers seeking access to the network. Among these devices are digital subscriber access line multiplexors (DSLAMs) and cable modem termination systems (CMTS).
The Broadband Remote Access Server (B-RAS)

The B-RAS emerged in response to a fundamental requirement resulting from conveyance of broadband service to the mass market: the need to help service providers aggregate and manage their subscribers. The B-RAS is a device akin to a remote access server but designed for broadband customers. First generation B-RAS systems provided subscriber aggregation and connectivity only but not value-added subscriber services.
214659-B
27
The B-RAS was designed to give the subscriber the familiar look and feel of the Packet Switching Telephone Network (PSTN) dial-up access service. As with dial-up access, the B-RAS hid complexity to maximize usability, keeping the process transparent to the user. Though an advance in the right direction, the B-RAS offered minimal capability. The B-RAS platform had limited processing power and software and, thus, limited operational capacity. A B-RAS might be capable of some protocol conversion and some routing, but it lacked the computing power, for instance, to assess the difference between a file transfer and a streaming video. Because it lacked the processing power to examine the individual packet, the B-RAS could not offer a migration path to provisioning of value-added services such as quality of service (QoS) features or firewalling for security or service differentiation. In most cases, any attempt to deploy high-touch services on a B-RAS would degrade performance from 100 percent to 10 or 20 percent of the line rate. Thus, apart from support for subscriber aggregation, the B-RAS did not add any fundamental value to what the service provider could offer its customers. Moreover, the first generation B-RAS terminated the subscribers Point-to-Point Protocol (PPP) session at the Internet service providers (ISP) edge device by way of tunneling technologies such as L2TP. Terminating the PPP session within the ISP involved backhauling to the ISP, possibly to a platform that had no high-touch services, rendering unlikely application of these services even within the ISP. The B-RAS had other limitations, too; it was not designed to provide secure connections, nor was it designed to provide telco quality reliability. It quickly became evident that the device deployed at the subscriber edge had to have the following qualities. It had to: Possess the ability to bring the subscriber into the network in a scalable and reliable way. Encompass the processing power to provision and manage value-added services, called high-touch services. Have the routing capacity to tie the user into the core network.
28
To provide high-touch services, a much more powerful platform than the B-RAS was needed. A new generation of broadband service nodes, built with intelligent processing power in mind, was needed. This fundamental requirement for the new-generation device further defined the subscriber edge as the intelligent subscriber edge. Note: High-touch services are so called because the devices processors must be able to examine (or touch) each packet in order to treat it in a customized manner at wire rate performance.
Meeting the need for an intelligent access aggregator

The first of its kind, a broadband service node device, capable of aggregation and high-touch services, emerged in the form of the Nortel Networks Shasta 5000 BSN. The Shasta 5000 BSN can be deployed to serve mass market users and corporate enterprises, either exclusively or in combination, as explained in the chapters of this guide that address deployment scenarios. The Shasta 5000 BSN enables service providers to seamlessly migrate from basic broadband subscriber aggregation to more profitable high-value services while providing scalable operations. Because high-touch services are provisioned and delivered from the network as opposed to in the customer premises and a single platform supports thousands of subscribers, service providers using the Shasta 5000 BSN can achieve significant economies of scale in enabling high-touch services for the mass market. Typically, a corporate enterprise buys a managed service from a service provider. In this case, the Shasta 5000 BSN is owned by the service provider. In some cases, a service provider may deliver service to the enterprise through a wholesale carrier. As Figure 1 shows, the Shasta 5000 BSN provides universal subscriber aggregation across various access media types and methods.
214659-B
Chapter 1 Emergence of the BSN Figure 1 Universal aggregation

DSL Wholesale Dial ATM Backbone
29
Cable
Shasta 5000 BSN
Wireless
IP Backbone
FR/ATM
10026EA
In addition to providing universal subscriber aggregation services, these are the fundamental requirements of the new-generation broadband service node, which are met by the Shasta 5000 BSN: Ability to secure the broadband access mechanism Because broadband connections are always onwhich means the user does not log on and off regularly and the connection carries a static IP address for the long termthe systems for which they provide connectivity are effectively more visible. Therefore, they are exposed to security risks such as hacker intrusions. Thus, security is a fundamental requirement of the new generation broadband service node. The most optimum and cost-effective way to secure the broadband for mass market use is to provide a network-based firewall and let the network, itself, protect the subscriber. This approach is exactly the security solution that the Shasta 5000 BSN offers in its state-aware firewall. In addition to securing the broadband, the Shasta 5000 BSN firewall feature can also be used to differentiate traffic in order to offer customized services.
30
Ability to provision high-touch servicesservices such as virtual private networks, advanced traffic management, Network Address Translation (NAT), personal content portals, and content filteringand to do so in a scalable manner A truly flexible broadband service node should be able to potentially allow service providers to wholesale different kinds of services at different price points for different customers. The Shasta 5000 BSN enables deployment of all these services in a custom manner.
Ability to scale up the number of subscribers accommodated and offer the service provider the ability to support increasing numbers of subscribers in a modular, cost-effective way This kind of scalability was designed into the Shasta 5000 BSN, not added on.
The next chapter describes the features of the Shasta 5000 BSN.
214659-B
31
Chapter 2 BSN: overview and features
About the Broadband Service Node

Built on a scalable hardware platform, the Shasta 5000 Broadband Service Node (BSN) enables service providers to scale as they extend their subscriber bases and grow from small points of presence (PoPs) to mega-PoPs as their requirements expand. A Shasta 5000 BSN subscriber is any entity that is directly associated with a connection to the Shasta 5000 BSN on a one-to-one basis. A subscriber may represent a network of users behind the subscriber entity or a single user. Commonly, a subscriber terminates its layer 2 connection on the Shasta 5000 BSN and carries layer 3 IP traffic from that point on. Traffic to and from a subscriber IP address passes through a set of services that are private to the subscriber. Capable of accommodating subscribers using diverse access technologies including DSL, dial, wireless, FR-ATM, private line, optical, and cable, the Shasta 5000 BSN provides universal subscriber aggregation. By aggregating tens of thousands of subscribers on a single platform, the Shasta 5000 BSN allows for pricing commensurate with the low cost of new broadband access technologies for the mass market consumer as well as enabling the corporate enterprise to restrain networking infrastructure costs. The Shasta 5000 BSN is made up of these three interoperating components: Shasta 5000 BSN device The Shasta 5000 BSN platform was designed from the outset to scale the complex packet processing needed to apply subscriber policies and to deliver high-touch services to thousands of subscribers at line rate. The platform incorporates more than 100 high-performance CPUs.
32
The Shasta 5000 BSN platforms processing power enables the system to examine packets at wire speed and determine and implement the policy needed for specific traffic flows. The system can aggregate over 64,000 subscribers within a single platform. This capability reduces the need for expensive PoP facilities, such as rack space and power sources. Service Creation System (SCS) The SCS is a flexible, user-friendly provisioning system that allows for central provisioning of retail Internet service providers (ISPs), custom subscriber provisioning, bulk provisioning, and subscriber self-provisioning (also referred to as autoprovisioning) through Personal Content Portal technology. The SCS supports creation of customizable service profiles. The SCS allows service providers to provide customized IP services and central provisioning of tens of thousands of subscribers. Using SCS, the service provider can rapidly create and deliver different kinds of services (such as firewalls, QoS services, and VPNs) and packages of services to different categories of users. IP Services Operating System (iSOS) The Shasta 5000 BSN is built on iSOS, an operating system engineered for IP service creation and deployment. This operating system (iSOS) provides the subscriber awareness and data plane flexibility needed to enable individual customized service for each subscriber. The data plane consists of the particular combination of discrete IP packet processing steps comprising the customers selected services.
Shasta 5000 BSN services

This section describes the main services available through the Shasta 5000 BSN. Services described in this section are used in the deployment scenarios presented in the chapters comprising Part II of this guide. The following primary services are offered by the Shasta 5000 BSN:
214659-B
Contexts on page 33 Security on page 34 Virtual Private Networks on page 50 QoS on page 58
33
Personal Content Portals on page 63 Fully qualified domain names and realms on page 65 Realms and global roaming on page 66 IP Demux and Ethernet access on page 67 Wholesaling on page 68 Web steering on page 71
Contexts
The Shasta 5000 BSN is designed to allow many, distinct ISPs to each have a separate address space of its own. This address space is called a context. A context can be thought of as a virtual router (or an independent routed IP address space). A context services resources owned by the ISP; given ownership of a context, the ISP controls the routing services as well as subscribers. Because each ISP owns a separate virtual context (with a separate address space) in the Shasta 5000 BSN, conflicts or security issues that could arise from shared routing tables do not occur. The Shasta 5000 BSN maintains tight controls on viewing and configuration capabilities as they pertain to contexts. No ISP can ever see another ISPs configuration or subscriber base. Security is maximized while administrative overhead is minimized. ISPs with limited PoP capability find virtual contexts especially useful. A context on a Shasta 5000 BSN offers these smaller ISPs a means of providing additional PoPs without requiring ownership of the platform. The Shasta 5000 BSN has the technical capacity to support 64 routed contexts that can be either statically or dynamically configured utilizing Border Gateway Protocol (BGP), Open Shortest Path First (OSPF), IS-IS (Intermediate System to Intermediate System), or Routing Information Protocol (RIP). With static routes, this capacity can be enhanced to more than several hundred contexts. Note: While the loopback address (127.0.0.1) is pingabled from any ISP, it is only visable when checking interfaces on the Default Isp.
34
Security
With traditional dial-up access, subscribers dial into the network through their ISP, use the services they want (such are Web browsing), then log off, terminating the network connection. This transitory nature of dial-up access gives hackers a limited window of opportunity to exploit any security holes and break into the users system. For this reason, dial-up security incidents are infrequently heard of. Security breaches also occur rarely with dedicated access connections used by large corporations because these connections are protected by expensive firewalls implemented within the corporate network. As mass-market consumers transition from dialup Internet access to broadband technologies such as DSL and cable, they assume that broadband is similar to dial, only faster. One crucial difference that these users often initially overlook is that broadband technologies such as DSL lack security. The static nature of an always-on broadband connection engenders these conditions: Users are permanently connected to the network for the subscription duration. The same IP address is assigned to the users system for the long-term, for the duration of the connection, exposing the system to hacker intrusion.
In regard to use of static IP addresses, broadband connections are more like the traditional dedicated access connections used by large corporations. Traditionally, corporate connections have been protected from hackers by relatively expensive state-aware (or stateful) firewalls within the corporate infrastructure, a security solution that was not appropriate for the mass market. Managed firewalls traditionally used for corporate connections are expensive to maintain, falling within the cost range of $600 to $5000 per month, a cost not commensurate with the low cost of mass-market broadband access. Increasing numbers of businesses and consumer-users of mass-market broadband leverage the Internet to conduct business. Their activity entails the exchange of money or information confidential to the business. Thus, their concerns about security and the requirement for it increases, extending beyond the need to simply protect the user from random hacker intrusion. The emergent awareness of the need for broadband security is one of the central secondary forces driving the requirement for a platform such as the Shasta 5000 BSN.
214659-B
35
Considering the need for securing broadband access, firewalling offers the best solution. Whether the Shasta 5000 BSN customer is a corporate enterprise or a subscriber of a service provider, the Shasta 5000 BSN offers firewalling that is network based, not located on the customer premises. Network-based firewalls effectively prevent unwanted or unauthorized traffic from leaving or entering a customers site. The Shasta 5000 BSN is the first system to offer a network-based firewall that satisfies the stringent requirements of the ICSA certification process. By offering a network-based firewall, the Shasta 5000 BSN realizes the concept of broadband security. The Shasta 5000 BSN enables the service provider to apply security policies across thousands of subscribers through a single interface. Policies can be bulk provisioned and applied to ports, interfaces, or virtual circuits. In addition to network-based, stateful firewalls, the Shasta 5000 BSN integrates ingress anti-spoofing, anti-spoofing, and NAT (Network Address Translation) security services in its IP Services Operating System (iSOS), and it provides RADIUS authentication support, activity logging, encryption, and support for content filtering in conjunction with a third-party product. Figure 2 represents the Shasta 5000 BSN with individual firewalls applied to subscribers providing bidirectional protection on the trunk and access sides of the Shasta 5000 BSN.
Figure 2 Shasta 5000 BSN with per-subscriber firewall policies
Local loop Secure DSLAM Allowed Blocked Subscriber Spoofing Attacks Blocked Internet
10027EA
This section describes the following security features provided by the Shasta 5000 BSN: Firewalls
36
Anti-spoofing Denial-of-service and the Shasta 5000 BSN Authentication, Authorization, and Accounting Network Address Translation
Firewalls
Application of access controlakin to use of simple access listswas the only security provided by first-generation B-RAS devices. By introducing true broadband security principally through managed, stateful firewalls provisioned by the service provider from within the network in a custom manner, the Shasta 5000 BSN far exceeds this capability. In other words, the Shasta 5000 BSN provides a state-aware firewall, not just a packet filter, that is network based and allows the service provider to provide managed firewall service at the point of entry into the network rather than at the customer premises. The purpose of a firewall is to ensure that unauthorized traffic does not enter (or leave) the customer network, regardless of whether the network access method used by the traffic is a DSL line, a cable line, or some other access technology. (A scalable and access-independent firewall service can only be delivered on a platform that aggregates all last-mile access technologies.) Built from the outset to provide this capability as an integral component and not an added feature of its platform, the Shasta 5000 BSN provides firewalls without detriment to overall performance. For instance, throughput tested with a firewall enabled has shown that the firewall can operate at full-port speed with 64-byte packets.
Using firewalls for security

Network-based firewalls work as a form of perimeter defense, allowing passage to acceptable traffic (as defined by the enterprise or the service provider) and denying (by dropping) all other traffic before it enters the network. Firewalls perform this defensive function by monitoring packets and sessions, making decisions based on established rules in order to determine the appropriate action to take. Because the Shasta 5000 BSN supports firewall capabilities across many subscribers, the cost of firewalls is also spread, minimizing it for each subscriber.
214659-B
37
The Shasta 5000 BSNs firewalling capability enables the administrator to implement powerful packet-filtering rules and maintain a per-session security state. There are three types of action: allow, drop, or reject. Maintenance of network-based firewalls is easier and less complex to perform than is maintenance of enterprise and personal firewalls. For instance, using SCS, the service provider can: Specialize individual security policies for groups of customers through use of templates. Security policies can be bulk provisioned and applied to ports, interfaces, or virtual circuits. Create a separate, network-based firewall process for each subscriber through one interface. The Shasta 5000 BSN can support one firewall instance for each subscriber on a platform. Thus, a single Shasta 5000 BSN platform can support up to 32,000 firewall instances simultaneously. From the service providers perspective, network-based firewalls: Provide cost-effective security. Eliminate the need for customer premise equipment (CPE), removing the demand on resources incurred by delivery of equipment to individual customer locations and maintenance of that equipment.
From the subscribers perspective, network-based firewalls: Are commensurate in cost with the price of broadband access. Enable the service provider to custom provision the firewall so as to protect the local loop according to the needs and desires of the subscriber.
A state-aware firewall can recognize and track the following: Application flows that use Static TCP and UDP ports such as Telnet or HTTP Applications that create and use dynamic ports such as FTP, Real Audio, and so forth
38
The Shasta 5000 BSN state-aware firewall achieves optimum performance through use of the following built-in capabilities: Packet-processing capability in each SCS card, which contains processor arrays that apply high-touch services and perform policy operations, including packet filtering and inspection on a per-subscriber basis The Shasta 5000 BSN state-aware packet-filtering firewall goes beyond traditional packet filtering. It eliminates the need for application proxies by implementing a full state-aware packet inspection capability. The Shasta 5000 BSN intercepts packets at the network layer and begins analysis on the protocols. It extracts state-related information from all application layers to be used in making the security decision. Organized packet inspection designed so that only the first packet of a connection examines the full rule set Remaining packets of the same connection pass through an accelerated hash match that does not depend on the number of rules. Advanced memory management techniques such as caching and hash table usage that unifies multiple object instances and efficiently accesses data Each Shasta 5000 BSN contains up to 1 GB of memory. The Shasta 5000 BSN examines incoming and outgoing packets, running them against a security policy, such as that shown in Table 1. Table 1 shows a typical security rule, created using the SCS, for specifying how incoming and outgoing packets per service type are to be treated. The first rule applies to packets from the clients (subscriber) address. Those packets can be sent to any destination server and any application. The second rule drops packets from any session not initiated from the client source address.
Table 1 A typical security rule
Rule number 1 2 Source (client) SubAddr Any Destination (server) Any Any Service (application) Any Any Action Allow Drop
214659-B
39
The Shasta 5000 BSN software is regularly updated to support new protocols. Given that the system is configured with the correct number of cards and traffic is somewhat distributed among subscribers, the Shasta 5000 BSN can perform firewall activities at full line rate on all ports with 64-byte packets.
Using firewalls for service differentiation

These same firewalls provisioned through SCS for security can be used by service providers to segment the market. Segmenting subscriber traffic based on something other than access methods is necessary when DSL access constitutes the entire subscriber base on a single Shasta 5000 BSN platform. (In this case, the service provider must be able to segment subscribers by usage, not by access methodologies, because only one access method is used.) Thus, Shasta 5000 BSN firewall policies tailored for usage patterns provide an effective market segmentation mechanism, allowing the service provider to apply different sets of high-touch services to different DSL user segments. Both wholesale and retail service providers can use this market-segment capability to differentiate security offerings among different groups of subscribers such as residential, small office and home office (SOHO), and small-medium businesses. They can use differentiated tiering with other high-touch services through gold, silver, and bronze service offerings.
Anti-spoofing
Even the most advanced firewalls can be spoofed by the serious hacker. Spoof attacks involve sending to the firewall traffic that looks acceptable but can cause serious damage if allowed to enter the subscribers network. Traffic from spoof attacks appears to have a legitimate source IP address that is acceptable to the firewall packet-checking process. However, typically the IP address has been obtained illegitimately, or hijacked, and used wrongfully. Even the most advanced firewalls have been spoofed by the accomplished hacker. Hijacking occurs when an attacker takes over an existing connection between two computers. When the attacker determines the connection sequence numbers between the two computers, the person can generate traffic that appears to come from either one of the communicating parties.
40
Another threat to security is packet sniffing, or electronic eavesdropping. For most Ethernet LANs, all packets are available to the network interface card (NIC), which listens and responds only to packets specifically addressed to it. An intruder can put the NIC into a mode that can collect every packet that passes on the wire. Sniffer software can also be used to collect data and messages as they are transmitted on the network for analysis later. The Shasta 5000 BSN incorporates advanced anti-spoofing capabilities that are applied on a per-subscriber basis, and can therefore prevent spoof attacks from getting through to the subscribers network. The Shasta 5000 BSN firewall filters traffic going to and coming from the subscriber. The Shasta 5000 BSNs anti-spoofing capability ensures that traffic going toward the subscriber coming from the Internet is not misrepresented as traffic from a host on the subscriber network. This process is accomplished by filtering incoming traffic to ensure that the source address of the traffic to the subscribers link does not match the subscribers address. In the reverse direction, the Shasta 5000 BSNs anti-spoofing capability ensures that traffic coming from the subscriber going toward the Internet is not disguised as traffic from a host somewhere else in the Internet. This assurance is accomplished by filtering outgoing traffic to ensure that the source address of the traffic from the subscribers link does not match the subscribers address.
Denial-of-service and the Shasta 5000 BSN

Denial of Service is characterized as a rogue attack on a network device by hogging the resources on the device thereby preventing, presumably legitimate users access to the said device. The distributed version of the attack refers to the simultaneous traffic generated by multiple machines to a single device on the network. This attack may be coordinated through a master program or through a specified time built into the programs used in the attack. There are several versions of Denial of Service attacks: flooding a network with garbage data, preventing normal traffic exchange disrupting connections between machines, preventing access to service/s prevent a particular user from accessing a service/network entity
214659-B
41
Both the Distributed Denial of Service (DDOS) attacks and its singular source of attack versions focus on disrupting network service and preventing the occurrence of said disruptions in BSN-serviced network will greatly improve reliability of the network and also provide a new service for the Shasta BSN. The BSN already provides anti-spoofing and firewall services. DDOS protection enhances the reliability of the networks supported by the Shasta BSN.
Signature Recognition and Logging of Malformed Packets

This section identifies the types of attacks that are detected. It is important to note that the Shasta 5000 BSN is able to block some of these attacks types via additional functionality (Anti-spoofing, dropping directed broadcasts, rate limiting etc). However the user receives no indication as such in most instances. Hence where possible when such an attack is detected the system must be capable of raising an event/alarm to the end user. Some common DOS/DDOS attacks are listed in table below.
Table 2 DDOS attack definitions
Attack Name/Tool Bonk/Boink/ Jolt/Jolt2/ TearDrop Nestea NewTear Type of Attack DOS Description IP Fragmentation attack
DOS DOS
A variation of the IP fragmentation code and exploits the off-by-one IP header. Similar to the TearDrop attack. An improvement on TearDrop on erroneous UDP packets still using the IP fragmentation bug exploited by TearDrop. The modified teardrop attack works by sending pairs of deliberately constructed IP fragments that are reassembled into an invalid UDP datagram. Overlapping offsets cause the second packet to overwrite data in the middle of the UDP header contained in the first packet in such a way that the datagrams are left incomplete. The land attack aka latierra (latierra is a later version of land) will send a spoofed packet with the SYN flag set from a host, on an open port (such as 113 or 139), setting as source the SAME host and port (i.e.: 10.0.0.1:139 to 10.0.0.1:139). This will cause the target machine to lock up. Uses a ping system utility to create an IP packet that exceeds the maximum 65,536 bytes of data allowed by the IP specification. The oversize packet is then sent to an unsuspecting system. Systems may crash, hang, or reboot when they receive such a maliciously crafted packet. This attack is not new, and all OS vendors have fixes in place to handle the oversize packets.
Land/ Latierra
DOS
Ping of Death
DOS
42
Chapter 2 BSN: overview and features Table 2 DDOS attack definitions
Attack Name/Tool Smurf/ Fraggle
Type of Attack DDOS
Description An ICMP echo (ping) traffic surge directed at IP broadcast addresses, with a spoofed source address. This potentially causes the routing device delivering the traffic to take the ICMP echo request and return an echo reply, multiplying the traffic by the number of hosts responding. On a multi-access broadcast network, there could potentially be hundreds of machines to reply to each packet." Fraggle is the UDP version of Smurf. A root shell attack combination (SYN flood, ICMP flood, UDP flood and Smurf etc) with Stacheldraht the most sophisticated using encrypted communication between the master and the client machines used for attack. We concluded the detection of such complicated attacks is the job of intrusion detection device, not feasible for BSN.
Trinoo/TFN/ DDOS TFN2K/ Stacheldraht
Syn Flood Detection and Prevention through TCP Proxies and Splicing
The DDOS feature focuses on detecting and stopping SYN flood attacks by handling the delayed binding of SYN requests. Users are allowed to set up a number of SYNs that can be in the connection queue and also the time-out period for these connections. The SYNs will be acknowledged using the TCP Proxy and Splicing APIs. The detection of denial-of-service attacks' signature is the second component of the DDoS service. It also includes keeping statistics of the recognized attacks and dropping the packets recognized as part of the attack. This feature is not configurable and is always on.
SYN Flood Prevention/TCP Control Flags Monitor

The DDOS feature will focus on detecting and stopping SYN flood attacks by handling the delayed binding of SYN requests. Users are allowed to set up a number of SYNs that can be in the connection queue and also the time-out period for these connections. The SYNs are acknowledged using the TCP Proxy and Splicing APIs.
214659-B
43
IP Fragmentation
The denial of service attacks (Bonk, Boink, Jolt, Jolt2, TearDrop, NewTear and Nestea) are variations of exploits relying on the IP protocol stack mishandling the IP fragmentation and reassembly code. The DDOS feature counts the number of instances when the IP fragments processed have the signature of the listed attacks above. The reassembly code will also be verified for the fixes necessary for the prevention of the attacks. The simplest version of these attacks is implemented by simply sending 2 specially fragmented IP datagrams. The first is the 0 offset fragment with a payload of size N, with the MF bit on (data content is irrelevant). The second is the last fragment (MF == 0) with a positive offset < N and with a payload of < N. The reason why it cripples systems is that the reassembly will end up copying too much data and overwriting the buffer for the packet that is being reassembled.
ICMP and UDP Echo Broadcast

Currently the BSN does not forward direct broadcast to its local interfaces. Therefore the subscribers are already protected from Smurf/Fraggle based attacks. The DDoS feature will further prevent the BSN from forwarding any broadcasting ICMP (echo) and UDP (echo, daytime, qotd, chargen) traffic. Because the BSN has no foreknowledge of the remote node's network mask, we only stop the aforementioned broadcasting traffic if it is destined to standard A/B/C class broadcasting addresses. Statistics will be kept for this attack.
Delayed Binding
A set of functions will implement delayed binding. The user of this library will configure what kind of TCP options should be supported. By default only a safe subset will be used. Connections to clients as well as servers are setup (passive and active open).
Support for TCP Proxies

A set of functions to terminate a TCP connection, temporarily buffer and acknowledge packets, modify data in packets and transmit (and retransmit) packets to the server.
44
Support for TCP Splicing

A set of functions to support splicing of two TCP connections. These functions will set up a splice and after that the header manipulation functions will be used to pass packets from one connection to the others. It is again emphasized that TCP Splicing will not be implemented as a service. A service may call these functions. After an initial setup, this library is simply used to manipulate packets. The is also support for the transition from proxy phase to splicing phase.
Flow Mirroring
Flow Mirroring service is a policy based service used to provide a copy of IP traffic, originating from or destined for a specified subscriber, to external servers. The replicated IP traffic is sent to external servers by means of a predefined, configurable IP address and/or interface specified in the rules based policy. The external servers that would make use of the Bicast service at this time are Lawful Interception (LI) and Intrusion Detection (ID) servers. These servers perform security analysis on the replicated frames. Per result of this analysis, other security related BSN services such as a state-aware firewall might be reconfigured to block intruders. The replica IP frames can be forwarded over either Layer 3 IP address or Layer 2 connection. The choice of the forwarding method to use depends upon the level of required security and the ease of reachability. IP Address Based Forwarding - The IP address based forwarding approach is more robust to implement and LI and ID servers can be located anywhere on the network. It is assumed that the ID and LI servers are reachable through IP forwarding and have a FIB entry in the ISP or Subscriber domain. The connection through which the IP packet is to be forwarded should be readily available by looking up the destination address in the FIB. The next hop address would be entered to the FIB either through static or by dynamic routing. If the configured forwarding address is not reachable, is not found in the FIB or the interface is down, the mirrored frame will be dropped. This approach will allow for both broadcast (Ethernet) and point to point (ATM VC) media to reach the servers. The main drawback of this forwarding approach is that the IP and MAC address of the LI and ID servers has to be known making it less secure.
214659-B
45
Layer 2 Connection Based Forwarding - Compared to the IP address based forwarding, the Layer 2 approach doesn't require any routing and the ID and LI servers could listen in promiscuous mode. This forwarding approach is more secure as the servers are not visible on the network and operate on stealth mode. However, it would also limit the servers to listen only on broadcast medium such as Ethernet. A connection over which the IP frames are forwarded has to be provisioned and configured as a trunk connection.
Authentication, Authorization, and Accounting

Service providers verify the identity of users requesting access to their networks. Information used for this identification process is commonly stored in an Authentication, Authorization, and Accounting (AAA) server, such as a RADUIS server. This information can include user names and passwords, SecureID tokens, and biometric devices such as fingerprint scanners. The Shasta 5000 BSN supports several forms of authentication, depending on the access method and protocol used, including the following: For Point-to-Point Protocol (PPP) end-user authentication, the Shasta 5000 BSN supports PAP and CHAP password authentication. For Personal Content Portal and PPP authentication, the Shasta 5000 BSN supports PAP and CHAP password authentication as well as SecureID cards.
The Shasta 5000 BSN provides a single point of integration with existing back-office systems. The Shasta 5000 BSN uses back-office systems in the following ways for the technologies it supports: In PPPoE, PPPoA, and Layer 2 Tunneling Protocol (L2TP), the Shasta 5000 BSN acts as a RADIUS client. In 1483 bridged and routed environments, the Shasta 5000 BSN does not use RADIUS. Instead, to authenticate users, subscriber sessions are redirected to a Personal Content Portal server on the service provider premises. Through the users HTTP connection, the Shasta 5000 BSN directs authentication to a Web page in which the user can enter user ID and password or SecureID card values. The Personal Content Portal server signals to the Shasta 5000 BSN successful authentication, if it occurs.
46
For Virtual Private Networks (VPN) authentication, previously shared keys are used for Internet Key Exchange (IKE) authentication. IKE is defined in the Internet Protocol Security (IPsec) document, an IETF standard that provides encryption, host authentication, and data integrity for TCP IP. (For information about IPsec, see IPsec on page 89.)
Many ISPs might use extended RADIUS servers to provide authorization, authentication, and accounting, as well as to perform additional functions such as modem reservation for certain customers. The Shasta 5000 BSN makes extensive use of the RADIUS server to enable easy integration into existing back-office operations. In cases for which the ISP uses the Shasta 5000 BSN to aggregate both dial and broadband technologies, the Shasta 5000 BSN can leverage the optimized back-office infrastructure built around dial access for broadband access also.
Network Address Translation

Network Address Translation (NAT) permits subscribers to maintain private address spaces to allow for address management or security. It is used to conserve IP addresses. Private addresses are translated to globally recognized IP addresses at the Shasta 5000 BSN. Thus, NAT offers the following benefits: Provides a means of protecting private network IP addresses from the public Internet It performs this service by translating a publicly available IP address into a private network IP address. Reduces network costs by lowering the number of public IP addresses required for a subscriber network Helps to expand a network while protecting the current IP-based account scheme for that network Enables extranet services as well as interconnection between sites with overlapping address space
The Shasta 5000 BSN supports a many-to-one translation, allowing up to 254 private IP addresses to be assigned to a single publicly visible IP address. It supports port source and destination NAT for subscribers, along with Group NAT.
214659-B
47
Table 3 shows how to use SCS to configure NAT to map a public address to a single private address. Many private addresses could be mapped to the same single public IP address. The SCS maintains the address assignments for each individual subscriber, not template subscribers. That is, each subscriber must be mapped individually. In the example shown in Table 3, the source address_privateAddr is resolved at run time when the service is applied to a specific subscriber.
Table 3 SCS: Mapping a public address to a private address
SrcAddr _privateAddr Any DstAddr Any Any Service Any Any Action Map to publicAddr None
Group NAT
Group NAT provides the following: A way of hiding a group of subscribers with private IP addresses behind a group of public addresses. Easily scalable to large number of subscribers. No fuss creating policies explicitly. The same public address or range can be shared across multiple subscribers (m x n NAPT). Achieving Source NAT for Template and Dynamic subscribers. IPDemux subs. Subscribers that uses Address Pool for address allocation, e.g. PPP/ PPPoE subs. Subs with RADIUS or DHCP allocated addresses (e.g. not using BSN's Address Pool) are not supported with Group NAT. Partition groups of public and private IP address pools into Access Groups. Provides the ability to allocate each pool of address space to specific contexts for better address management. Each VPN or ISP context can be configured with its own group of public or private IP addresses.
48
For each Group NAT object, up to 32 consecutive IP addresses can be configured as the public address(es) to share among all subscribers associated to that Group NAT object.
Activity logging
Activity logs track activity within and at the edge of a network to determine if rejected traffic represents a threat or forms a pattern. Such information can later be used to enhance security features of the network or track illegitimate users. The Shasta 5000 BSN provides a GUI for the creation and definition of activity logs. With this service, the SCS provides a log manager that displays logged events per subscriber and per service. All events including acceptance and rejection of packets can be recorded in a log based on actions specified within the SCS. Logged events are time stamped when they are generated.
Encryption
Encryption can be applied at the network endpoints to provide security necessary for VPNs. The encryption and decryption processes entailed in the Shasta 5000 BSN encryption feature require that compatible algorithms be used at all end devices. IPsec is supported for secure network connections between the Shasta 5000 BSN devices offering end-to-end tunnels independent of any interior topology or networking technology. Encryption support for the Shasta 5000 BSN employs the following: TripleDES and 56-bit DES (3DES/DES) through the use of dedicated hardware coprocessors for encryption (up to four per SSC line card) for optimum performance Internet Key Exchange (IKE)-based keying through preshared keys
214659-B
49
Content filtering
Content filtering provides a way to control Internet content coming into any environment, whether residential or business. It is performed through predetermined filters used to block URLs that meet predefined criteria or categories for a particular environment or circumstance. Content filtering is administered through a proxy in which Web requests for a service providers customer are sent to that proxy. The proxy checks those requests against a list of denied URLs. Incoming content meeting the customers predetermined criteria is blocked. The Shasta 5000 BSN supports the use of proxy services for content filtering through its Web steering redirection capability. These servers then filter the incoming traffic on behalf of the customer.
Cable deployment security considerations

Because cable is essentially a shared medium, security must be applied to it to protect the subscriber connection. In the following ways, security is provided for cable connections: The Data Over Cable System Interface Specification (DOCSIS) must be implemented between the cable modems and the Cable Modem Termination System (CMTS). DOCSIS provides for baseline privacy using Private/Public key encryption on the communications channel. Filters or access lists must be applied at the CMTS or cable head end to prevent broadcast traffic from being seen by other subscribers on the same segment. All traffic needs to be forced to a specific port. This port, then, becomes the connection to the Shasta 5000 BSN.
50
Tunneling
Virtual Private Networks (VPNs), discussed in Virtual Private Networks on page 50, are implemented using a tunneling mechanism, for instance, an IP tunnel such as IPsec, which connects the VPN endpoints. A tunnel provides the path that encapsulated packets follow in IP-VPNs. Part of the encapsulation process performed by a tunnel endpoint includes adding a new address to the packet: this address is the one corresponding to the other end of the tunnel. For an IP-VPN, an IP tunnel can be thought of as a sort of link that can be concatenated with another link and bound to a bridge forwarding table or bound to an IP forwarding table, depending on the type of VPN. An IP tunnel overlays the IP backbone; traffic sent through the tunnel is opaque to the underlying IP backbone. Thus, in effect, the IP backbone is used as link layer technology, and the tunnel forms a link. An IP-VPN device may terminate multiple IP tunnels and forward packets between these tunnels and other network interfaces in different ways. The Layer 2 Tunneling Protocol (L2TP), which is the most commonly used method of building a VPN for on-net applications, is used to create secure connections between a subscribers entry to the network at the L2TP Access Concentrator (LAC), a device such as the Shasta 5000 BSN, and the L2TP Network Server (LNS) device, which could be a Shasta 5000 BSN or a third-party platform located at the service provider premises.
Virtual Private Networks

By emulating a private network over a shared infrastructure, such as the Internet (or private IP backbones), a Virtual Private Network (VPN) allows for private communication to occur over a public channel. VPNs use public networks for basic transport. As do existing private networks, VPNs provide dedicated or dial connectivity between two or more customer sites, mobile users, telecommuters, or business partners. VPNs offer the same level of security, performance, availability, and functionality offered by dedicated private networks.
214659-B
51
VPNs offer the following benefits: VPNs provide corporations the ability to cost-effectively extend the corporate network to remote sites, telecommuters, and mobile workers; they reduce costs within the corporation and for corporations in their communications with business partners. Once deployed, VPNs provide the infrastructure to support additional services such as hosted applications and voice services with little incremental network cost. VPNs are the building blocks of next-generation enterprise WANs.
While the idea of using a public IP network for private communications is not new, it is only recently that the mechanisms, standards, and technologies have come together to meet the QoS, reliability, security, and cost-effectiveness requirements to bring into being the VPNand, especially, the IP-VPN. A VPN that runs over an IP intrastructurethat is, that uses IPis referred to formally as an IP-VPN. A network-based VPN is a VPN that is operated and managed by the service provider. The VPN is implemented on the network, not on the CPE equipment. Supporting VPNs in the network allows for highly efficient and cost-effective solutions, with common equipment and operations expenses amortized across large numbers of customers. VPNs are implemented using a tunneling mechanism, such as an IP tunnel, which connects the VPN endpoints. For details on tunnels, see Tunneling on page 50. VPN technology is primarily used for the following types of connectivity: Dedicated core Intranet connectivity between corporate headquarters, regional offices, and branch offices Intranet VPNs enable site-to-site connectivity, adding incremental or new capacity to existing leased lines, ATM, or frame relay-based networks. Only the link between the branch office and the provider is tariffed on a monthly basis. Individual virtual circuits are no longer required for connections to multiple sites. Savings are even greater for international connectivity, where the costs for leased lines, ATM, or frame relay connections may be substantial.
52
A VPN increases geographic coverage including low-cost international access, and it offers improved scalability for adding new users. Other cost savings come from eliminating most training expenses and software and hardware upgrades. Remote access to provide extended intranet connectivity for SOHO use, telecommuters, and mobile workers
VPN-based remote access services minimize the need for private equipment and associated management. They satisfy enterprise requirements for mobile and telecommunications applications, including e-mail, file sharing, and database access. When VPNs are used for remote dial access, users dial into a service providers point-of-presence (PoP) using a local access number. Their connections are then tunneled back to the corporate gateway. In this capacity, VPNs eliminate the need for the businesses to buy and manage their own modem pools. Figure 3 shows some uses of VPNs.
Figure 3 IP-VPN applications
Application Hosting Customer Service Management
Service Provider Infrastructure Business Partners or Suppliers Internet
Corporate Headquarters
Virtual Private Network
Regional or Branch Offices
Customers SOHO 1 Telecommuters Mobile Users

10028EA
214659-B
53
As mentioned previously, for the Shasta 5000 BSN, VPNs are secured through IPsec with or without DES56/3DES encryption and authentication. For an overview of IPsec, see IPsec on page 89. Secure VPNs make these assurances: A message sent across the VPN has not been modified. Users of the VPN are authenticated (you know who you are communicating with). Only authorized persons receive messages.
VPNs support multiple service and deployment options. In choosing which type of VPN to deploy, it is critical that the service provider understand what portions of the network the customer wants to outsource. The BSN supports the following kinds of VPNs: Virtual Private Routed Networks (VPRNs) both with and without Internet access. See Virtual Private Routed Networks on page 54. Multi-protocol Label Switching (MPLS). See MPLS and VRF-VPNs on page 56. Virtual Leased Lines (VLLs). See Virtual Leased Lines on page 56. Virtual local area networks (.VLANs)
For additional description of VPN types and scenarios that illustrate them, see Chapter 7, Virtual Private Networks, on page 135. The VPN capabilities on the BSN offer the service provider a means of providing many private networks over a shared infrastructurefor instance, up to 1000 VPRNs, depending on how resources are used. The service provider can map individual subscribers and routed or bridged customer site subscribers into unique
54
VPNs. The BSNs highly scalable, policy-based service provisioning and management system, the SCS, allows service providers to differentiate their VPN service offerings by enabling customer management, service level agreement, real-time monitoring, and service accounting. Note: The Nortel Networks comprehensive VPN solutions offerings include the Shasta 5000 BSN as well as the Contivity* Extranet Switch portfolio of CPE-based solutions and the CVX-1800 dial access-based solutions. The Contivity Extranet Switch, or a third-party extranet access switch, allows the corporate network to take advantage of the infrastructure built around the remote access system, including firewalling, filtering, tunneling, and bandwidth and policy management. This section includes the following topics: Virtual Private Routed Networks on page 54 MPLS and VRF-VPNs on page 56 Virtual Leased Lines on page 56
Virtual Private Routed Networks

A Virtual Private Routed Network (VPRN) is the emulation of a multisite wide area routed core network using IP facilities. A VPRN allows a customer to outsource the core routing to the service provider. A VPRN (a layer 3 VPN) can be used as an Intranet to tie together the headquarters site, branch offices, and remote offices of a small to medium enterprise. VPRNs may also be deployed in support of corporate Extranets that connect suppliers and distributors to the corporation. A VPRN has the following features: It is comprised of a mesh of IP tunnels between endpoints as well as routing capabilities used to forward traffic to the appropriate destination site. The Shasta 5000 BSN Version 2.5 supports intelligent (partial) meshing in which a connection between two hubs in the VPRN is brought up only when a subscriber logs onto the network to use that tunnel connection. To edge devices, the VPRN appears as an IP cloud. The service providers edge router appears as a neighbor.
214659-B
55
A VPN eliminates the need for dedicated leased lines, frame relay, or ATM connections. It is secured through IPsec, relies on Internet Key Exchange (IKE) for key exchange, and exchanges topology updates via triggered Routing Information Protocol (RIP).
VRPNs can provide Internet access or not. VPRNs with and without Internet access are discussed in Chapter 7, Virtual Private Networks. The Shasta 5000 BSN deployment in Figure 4 shows two VPRNs: one without Internet access, illustrated by the solid lines; and one with Internet access, illustrated by the dashed lines.
Figure 4 VPRNs with and without Internet access
RADIUS Server
RADIUS Server
NAT NAT ISP NAT
NAT NAT
Headquarters
IP Backbone
Headquarters ISP
Internet NAT ISP

10111EA
For VPRNs, the service provider network performs layer 3 customer routing. The service provider edge router contains separate routing tables for each customer, thus providing address isolation. The CPE device requires no changes. The service provider edge routers are interconnected by a tunneling technology. For the Version 2.5 of the Shasta 5000 BSN, IPsec is used as the tunneling technology.
56
The Shasta 5000 BSN VPRN capability can be deployed as a managed router core only, referred to in this guide as a VPRN without Internet access (in other documents also referred to as a virtual transport network), or in combination with Internet access to offer a fully outsourced network, referred to in this guide as a VPRN with Internet access (in other documents also referred to as a virtual service network). Note: VPRNs supported by the BSN integrate with subscriber side Virtual Private Dial Networks (VPDNs), allowing service providers to offer an integrated IP VPN solution for both fixed sites and mobile users.
MPLS and VRF-VPNs

Prior to the introduction of Multi-protocol Label Switching (MPLS), networks in general relied on conventional IP forwarding. This process required that for each packet, each hop perform a forwarding table lookup to determine the appropriate next-hop for the destination address. The table lookup is based on a longest match principle. MPLS is a standards based protocol that combines the benefits of layer 2 switching with layer 3 routing.
Virtual Leased Lines

The Virtual Leased Line (VLL) provides a simple form of a VPN, especially useful for site-to-site connections. It provides a point-to-point service that emulates leased lines across an IP backbone, connecting pairs of sites by IP tunnels. Traffic carried across the VLL is opaque. The IP tunnel operates as an overlay across the IP backbone, and the traffic sent through the tunnel is protocol independent. The VLL is entirely independent of any forwarding action, routing, or bridging that might occur at an endpoint. VLLs can be deployed to connect both CPE and network-based platforms, replacing the need for frame relay, ATM, or private line connections.
214659-B
57
VLL connectivity extends the network reach, based on IP, to sites that could not previously be connected cost-effectively. However, VLLs have limited scalability for applications that require a large number of sites with any-to-any traffic patterns. Although VLLs rely on IPsec, they do not include automatic key exchange or topology discovery. VLLs are like a series of concatenated lines, as Figure 5 shows. In this figure, two VLLs originate from separate branch offices into the enterprise headquarters. IPsec tunnels with DES/3DES encryption are used on the trunk side links to carry the traffic across the IP backbone.
Figure 5 Virtual Leased Line
ATM Frame Relay DSL Cable Wireless Virtual Leased Lines ATM Frame Relay DSL Cable Wireless
IP Backbone Branch Remote Office Access Access
IPSec: DES/3DES
Branch Remote Office

10029EA
Virtual Private Dial Networks

The Virtual Private Dial Network (VPDN) connects remote users to a corporate network. VPDNs offer an alternative tunneling architecture for secure corporate access. VPDNs enable service providers to cost effectively meet their enterprise user needs for mobile and telecommuting applications through a variety of access methods, such as dial, Integrated Services Digital Network (ISDN), DSL, wireless, and cable.
58
The Shasta 5000 BSN can be deployed to support network-based Layer 2 Tunnel (L2TP), L2TP Access Concentrator (LAC), and L2TP Network Server (LNS) functionality as well as off-network Internet Protocol Security (IPsec)-based networks. L2TP interworking with Contivity and the CVX-1800 offers service providers the flexibility to deploy L2TP-based VPDNs.
QoS
The Shasta 5000 BSN delivers QoS through its advanced classification software coupled with QoS policies and use of a dynamic data plane per subscriber. Using the dynamic data plane, the Shasta 5000 BSN creates a virtual network edge for each subscriber, thus enabling the delivery of subscriber-specific on-demand policies. To deliver advanced capabilities, the Shasta 5000 BSN first classifies applications through its state-aware application recognition engine; then it applies the requisite level of QoS through queueing and scheduling mechanisms. The ability to differentiate one application from another is key to the Shasta 5000 BSNs ability to deliver the requisite level of QoS. The Shasta 5000 BSN offers the following QoS features that allow the ISP to differentiate applications: About traffic management, including traffic policing and traffic shaping Policy-based forwarding DiffServ marking Mapping of layer 3 QoS to layer 2 QoS where applicable
About traffic management

Traffic management allows service providers to offer service guarantees to subscribers in the form of Service Level Agreements (SLAs) made possible through the ability to prioritize applications and subscribers. It also helps the provider to optimize backbone utilization.
214659-B
59
Traffic management processes provided by the Shasta 5000 BSN, which provide for control over bandwidth, latency, and jitter, include the following: Setting the traffic priority Policing traffic entering the providers network, based on prioritization Traffic shaping, in which the subscriber controls the amount of traffic accepted from the network
For a service provider to be able to offer SLAs to subscribers, networking devices between the traffic source and destination must be capable of identifying the types of traffic and influencing the course of traffic. In an environment that supports both cell-based ATM and packet transmission, traffic management capabilities at the interface of the ATM layer and packet layer must interwork. Note: The traffic management capabilities of the Shasta 5000 BSN integrate with the Nortel Networks CPE and physical aggregation platforms as well as core offerings in the router and ATM switching space.
Traffic policing
The Shasta 5000 BSN supports Assured Forwarding (AF) class-based traffic policing. Traffic policing gives the service provider the ability to define the type and amount of traffic a subscriber can send. The service provider can limit a subscriber to a specified amount of bandwidth, charge the subscriber for excess usage, and define types of traffic categories and their bandwidth thresholds. Application of rules determines how excess traffic is handled for certain categories. Committed rate, committed burst size, peak rate, and peak burst size thresholds are set with corresponding actions. Colors are used to designate action categories: red, yellow, and green. For each of these categories, actions vary from dropping the traffic, placing it in the appropriate queue, or marking the IP precedence. Rates and actions are associated with each CoS queue.
60
Traffic shaping
Traffic shaping is a feature that enables management of traffic sent in the direction of the subscribers network. Traffic shaping allows service providers to offer high priority and rate guarantees to specific mission critical applications such as real-time applications, while giving lower priority to applications such as e-mail and File Transfer Protocol (FTP) traffic. The Shasta 5000 BSN identifies IP flows and shapes them to an absolute bandwidth and/or a relative (percentage) of bandwidth under times of congestion. Different flows receive different bandwidth allocations. In addition to application-level traffic shaping, the Shasta 5000 BSN also implements aggregate traffic shaping at the layer 2 (L2) levelthat is, it offers ATM constant bit rate (CBR) virtual circuit (VC) shaping. There are two types of shapers: Rule-based shapers This type of shaper provides for granularity at the flow level. It includes queues for each IP flow. AF class-based shapers This type of shaper provides for granularity at the CoS queue level. It includes eight queues, one for each CoS.
Policy-based forwarding
Policy-based forwarding provides the capability to steer traffic from a subscriber interface to a particular trunk interface as opposed to the default routing. This forwarding can be used for the following purposes: To override the routing tables on a per-subscriber basis Policy-based forwarding is used to bypass normal route lookup of ingress traffic and determine the next hop based in policy rule match. To forward specific traffic types to specific trunks To send all traffic for a subscriber out a specific trunk
214659-B
61
DiffServ marking
DiffServ marking enables application of layer 3 (L3) QoS on the Shasta 5000 BSN, allowing you to provide differentiated services appropriately for different classes of traffic on both the ingress and the egress directions. The Shasta 5000 BSN supports rule-based marking of IP traffic with Assured Forwarding (AF) per-hop behavior group, as defined by the IETF DiffServ architecture. DiffServ enables the service provider to offer subscribers different levels of assured L3 QoS and bill for it. For instance, a subscriber might have a requirement for voice and data traffic. The subscriber would specify that the voice traffic be provisioned with a higher priority than the data traffic. Using the Shasta 5000 BSNs DiffServ capability, the service provider could accommodate the request, guarantee voice a higher level of service, and charge for it. The Shasta 5000 BSN implements class-based Weighted Fair Queuing (WFQ) for queuing, as well as class-based Weighted Random Early Detection (WRED) selective discard with three configurable levels of drop precedence and a configurable averaging function or interval. The Shasta 5000 BSN includes a capability that allows for mapping of these AF classes into ATM QoS.
Application of traffic management and QoS

The Shasta 5000 BSN applies the following traffic management and QoS features at the ingress (traffic exiting the Shasta 5000 BSN, going toward the network core): Policing, including metering, marking (DiffServ), and tagging Mapping the various Assured Forwarding (AF) classes from DiffServ into different ATM virtual circuits (VCs) Weighted Random Early Detection (WRED)
The Shasta 5000 BSN applies the following traffic management and QoS features at the egress (traffic entering the Shasta 5000 BSN coming from the network core): Selective Discard (SE) Hierarchical WFQ (application based)
62
Shaping (aggregate) L3/L2 mapping
Subscriber traffic coming into the network undergoes the following traffic management and QoS processing: 1 After subscriber traffic passes through an anti-spoofing policy, which discards any traffic sourced from the subscriber with an IP network address different from that officially assigned, it enters the traffic management process. The DiffServ ToS byte is set to mark (or re-mark) traffic to distinguish different traffic types from one anotherfor instance, ftp, smtp, and H.323. This process allows the network service provider to price different service classes depending on how it treats the subscribers traffic. When the DiffServ ToS byte is set, routers within the network core use the information to queue and/or discard the traffic in different ways. 3 The policing function is used to set drop priorities. This function protects the network core from traffic in excess of the subscribers contracted rate. It uses DiffServ markings in conjunction with bandwidth limits to set these priorities. Drop priorities set at the edge are acted upon by routers and switches in the network core. The combination of DiffServ marking and traffic policing allow for protection of real-time traffic, such as voice and video, and enable the service provider to offer SLAs. 4 If the service provider implements VPNs, the traffic enters a VPN steering function. This process directs the data to a VPN or to the default ISP forwarder. In the former case, two sets of firewall policies are appliedone relating to the subscriber and the other assigned to the VPN. For ISP forwarding, only the subscriber firewall policy is applied. 5 Based on the DiffServ marking, if the ISP deploys an ATM-based backbone, it may assign each CoS to a different VC within the trunk group. If the
214659-B
63
backbone connection is POS or FE/GE, the different CoSs may be queued differently. This process separates the traffic types across the backbone and offers strong QoS guarantees in support of subscriber SLAs. For example, AF4 traffic may be carried across an ATM VBR-rt PVC while AF1 could be sent via a GFR PVC. Subscriber traffic coming into the Shasta 5000 BSN from the network core undergoes the following traffic management and QoS processing: 1 2 Traffic passes through the subscriber firewall policy. Traffic enters the shaping function responsible for protecting the access link. The traffic is assigned a weight and flow bandwidth depending on the source, destination, and traffic type. 3 Traffic passes through an anti-spoofing policy, which protects the subscribers network. To protect against external entities masquerading as the subscriber, the anti-spoofing policy usually discards any traffic with a source network address equal to the subscribers own network.
Personal Content Portals

The Shasta 5000 BSN Personal Content Portal technology gives the service provider or corporate enterprise the ability to link access service offerings with specific Web content. It allows the service provider or corporation to steer the subscriber to a specific portal, matching content to identified subscribers. When this technology is configured, the Shasta 5000 BSN intercepts subscriber HTTP requests issued from the desktop and redirects them from their intended sites to preconfigured Web locations, referred to as Personal Content Portals. Instead of viewing the initially targeted HTML page, subscribers must navigate specific HTML pages at the Personal Content Portal Web site. Using the Personal Content Portal technology, captive Web sessions can be configured to occur on startup or at configurable intervals.
64
Software at the Personal Content Portal location instructs the Shasta 5000 BSN hijacking the HTTP request to switch from captive to noncaptive (free reign) mode to allow subscribers to view the intended Web site, as appropriate, through a message signaling process. The subscriber can be forced back to the Personal Content Portal mode by the following events: Issuance of a command from the Personal Content Portal to the Shasta 5000 BSN to revert the user to captive mode Expiration of a timer, available for ISP configuration, that forces subscribers to revisit the Personal Content Portal Web location
Figure 6 shows how the Personal Content Portal technology works.

Figure 6 Personal Content Portal
Shasta 5000 BNC Captive Mode Switch http Requests
Hijacked http Requests
Captive Portal Web Site
Intended Web Site

10066EA
The Shasta 5000 BSN Personal Content Portal technology can be used for many purposes. The following are just a few possible uses of Personal Content Portals: Subscriber steering for self-provisioning
214659-B
65
The Personal Content Portal enables the service provider to steer customers to a portal for self-provisioning of services and tiered offerings. The selfprovisioning allows for faster time to market while still giving the service provider some level of customer controlfor instance, over their security options. Self-provisioning (or autoprovisioning) is an essential means of deployment of services to mass market customers. For instance, it allows service providers to deploy DSL services with the same speed and ease of provisioning intrinsic to delivery of Internet dial access services. Subscriber steering for Web content purveyance The Personal Content Portal allows the service provider to give the subscriber access to specific kinds of services and capabilities when that user logs in to the network. Subscriber steering for login security processing When there are requirements for login security of bridged users or account configuration for bridged and PPP subscribers, the Shasta 5000 BSN can direct user HTTP traffic to a Personal Content Portal at the ISP site. This Personal Content Portal can be configured to provide users with customized Web-based screens that allow user login, provisioning of new services, or changes to existing services. The Personal Content Portal can also provide an interface into back-end authentication, accounting, and billing servers to propagate collected information.
Fully qualified domain names and realms

A fully qualified domain name (FQDN) specifies the user name and the name of the domain to which that user belongs expressed traditionally as user@domain. A new prototype for an FQDN has emerged that encompasses in its syntax the concept of the realm. Specification of the realm in the FQDN is handled differently by various platforms. In the Shasta 5000 BSN, the realm name adds a dimension to an FQDN. It is not just a reinterpretation of or replacement for the domain name. Addition of a realm name to the FQDN results in the following syntax prototype, as used by the Shasta 5000 BSN:
66
realm/user@domain Here is an example: AOA/bob_user@bellnorth.net
Realms and global roaming

The Shasta 5000 BSN approach to adding realms to FQDNs, as explored in the previous section, Fully qualified domain names and realms on page 65, differs from the approach taken by most B-RAS platforms. Most other platforms treat specification of the realm simply as a replacement for the @domain portion of the FQDN. To use realms in support of the concept of roaming and to meet Shasta 5000 BSN wholesaler requirements for support of global roaming and other features, the Shasta 5000 BSN implementation treats realms as separate entities, adding a dimension to the FQDN. This section contains the following subsections describing how the Shasta 5000 BSN implements and treats realms: Roaming (and consistency with dial ISP models) Vanity domains
Roaming (and consistency with dial ISP models)

For the Shasta 5000 BSN dial ISP implementations, the realm/user@domain FQDN format is used to add a third dimension to the FQDN in support of roaming. Roaming allows the user (the subscriber) to dial into a guest ISP while traveling. It also allows subscribers to use their specified home domain for remote RADIUS authentication and tunneling in order to get to their home ISP (that is, their original ISP) through several other cooperating ISPs. Increasingly, hotels, airports, and other public points of presence will develop broadband infrastructure. These developments will bring forth the requirement for broadband roaming and realm support. Businesses will want to participate in global roaming programs provided by ISPs to give their travelers access to their home ISPs.
214659-B
67
Vanity domains
A vanity domain is a private domain name assigned to and privately owned by an organization. When members of a vanity domain log in to their broadband service, they want to use their own domain names instead of those provided in the service providers domain. However, they want to obtain the same types of services the service provider offers other customers with conventional login names. The Shasta 5000 BSN provides support for thousands of vanity domains, all usable without the user having to enter information already provided to RADIUS. The Shasta 5000 BSN creates a fair and true opportunity for ISPs in regard to vanity domains because use of them is not limited to the Shasta 5000 BSN wholesaler ISP and its ISP retail arm. Each ISP can apply as many vanity domains as are required. For details and an example illustrating use of vanity domains, see Advanced wholesaling and vanity domain support on page 210.
IP Demux and Ethernet access

The Shasta 5000 BSN supports a feature called IP Demux, most commonly used in the cable industry but also used elsewhere. IP Demux affords the user ISP membership based on IP addresses, typically assigned via DHCP servers. IP Demux involves a virtual concept known as a container. A container is a range of supported IP addresses that the service provider can arbitrarily group by subnet into a logical connection, binding the IP address to a certain subscriber or subscriber template. (Different IP address ranges are allocated to different ISPs.) Once matched to a subscriber template, a subscriber can be provided a specific set of services personalized for him or her. Subscribers can become members of containers either by static assignment or dynamic assignment. The IP Demux feature differentiates between users arriving on Ethernet ports. IP Demux allows for: Identification and binding of multiple subscribers behind one access connection. Individualized set of services that could include membership in a VPN. Static or preconfigured subscribers with their own IP address or multiple IP address ranges with a list of services.
68
When a new IP address is detected, subscribers are automatically created based on a template with a set of services.
Wholesaling
In the context of the Shasta 5000 BSN, wholesalers can be thought of in the following ways: They are providers who own and manage the Shasta 5000 BSN platform and offer advanced services to ISPs and content providers, who, in turn, purvey these differentiated services to subscribers. They provide local points of presence (PoPs) to ISPs, not just backhauling. They offer ISPs the opportunity to use broadband bandwidth to enable application of broadband content so that an ISP can offer a variety of Internet experiences to its subscriber base. They effectively sell space, called a context, and services pertaining to use of that space to ISPs. See Contexts on page 33 for a description of contexts. The only wholesaling capacity available through first generation broadband aggregation devices was the ability to terminate the PPP session at the ISP edge device via tunneling technologies such as L2TP. This process commonly entailed backhauling to a platform with no high-touch services. Thus, wholesalers sold only broadband access to ISPs. When it became available, the Shasta 5000 BSN changed the state of wholesaling. Now, the PPP session could be terminated on the Shasta 5000 BSN, allowing the ISP or content provider to have access to the customer and be able to provide high touch services, such as firewalls, QoS, VPNs, and Personal Content Portals. These features enabled wholesalers to sell comprehensive network services to their ISP clients. The Shasta 5000 BSN broadband service owner-wholesaler could now offer not only broadband access but services that enabled local content for the ISP. This meant that the ISP clients of wholesalers could differentiate themselves from one another by tailoring their own offerings to suit their target subscriber base.
214659-B
69
The wholesaler could also tier services. Wholesale tiering enables the wholesaler to offer the full value of the Shasta 5000 BSN solution to the ISP for a certain price. Some ISPs might prefer a simpler, bandwidth mode, predating the Shasta 5000 BSN, for a reduced price; these ISPs might already own a Shasta 5000 BSN that offers high-touch services. Wholesale tiering allows the wholesaler to define different marketing strategies for different categories of ISPstypically known as tier 1, tier 2, and tier 3 ISPsin order to accommodate all possible ISP customers. One wholesaler model places ownership and physical control of the Shasta 5000 BSN platform under the auspices of an Incumbent Local Exchange Carrier (ILEC) or a Competitive Local Exchange Carrier (CLEC). These entities then partition the Shasta 5000 BSN into multiple contexts, or virtual routers, for client ISPs. In turn, ISPs configure their own DSL or dial subscribers and effectively control their own virtual partition (context). The opportunity to purchase a context from a wholesaler eliminates the need for these ISPs to deploy their own dedicated physical systems for subscriber termination, thus lowering the entry barrier for entities wanting to become ISPs servicing smaller market segments. A variation on the business of wholesaling is the case in which an ISP is the wholesaler. For this model, the physical Shasta 5000 BSN platform is controlled by the ISP. The ISP wholesaler could sell contexts and services to ISPs equivalent in size or smaller to itself, as well as manage their own context and the Shasta 5000 BSN platform operation. Alternatively, the ISP wholesaler could own all physical infrastructure, virtual circuits, or connections on the access side (toward the subscriber) and the trunk side (toward the ISP), own all tunnels, and control all subsequent template definitions. Typically, there is only one address space under this model under the control of the ISP wholesaler. Thus, the ISP wholesaler is responsible for operation of the entire system as well as configuration of its own subscribers. In summary, the Shasta 5000 BSN wholesaler-owner can offer the following key features to the ISP: Local points of presence (PoP) for every ISP client who owns a context within the Shasta 5000 BSN Network access universality
70
Shasta 5000 BSN wholesaler-owners can incorporate any type of network access technologyfor instance, dial, DSL, ATM, frame relay, wireless, or cable modem. This ability allows ISPs to focus on content and use one wholesaler to support all access methods they want to make available to their subscribers. Service selection model flexibility for each ISP Because every ISP has its own business model, it is important for a wholesaler to be able to offer an ISP various, possible solutions. The wholesaler must be able to provide the ISP with services differentiating that ISPs subscriber offerings from what is offered by other ISPs. Some ISPs want to offer only simple tunnels, whereas others want to make available to their subscribers complex capabilities. Some ISPs will require multiple PoPs distributed throughout the wholesaler territory, while other ISPs may require only a backhaul type solution to a single site. Customer ownership, management, and protection, as well as equal opportunity for the subscriber base The Shasta 5000 BSN owned by the wholesaler can support many ISPs, each with its own context. Thus, competitor ISPs might be clients of the same wholesaler. To provide the ISP with protection, tight controls are maintained on viewing and configuration capabilities. No ISP can ever see another ISPs configuration or subscriber base. In fact, it is possible to configure the wholesaler operational center so that ISP subscriber configurations are not visible to the wholesaler. Network management access, provisioning and viewing capabilities, and resources for its subscriber base provide the ISP with a sense of customer ownership. To provide these capabilities, ISPs can set their own security and traffic management policies and run their own routing instance into various backbones. All subscriber provisioning is done by the ISP, freeing the wholesaler from this responsibility and protecting the ISPs privacy.
214659-B
71
Web steering
Web steering enables you to forward HTTP traffic to Web caching proxies. Use of it eliminates the need for an additional layer 4 switch used to steer content. The Shasta 5000 BSNs implementation of Web steering performs network address translation (NAT) for all Web steering. Use of NAT provides additional protection when the Web cache is not colocated with the Shasta 5000 BSN. For the Shasta 5000 BSN Web steering support, you can specify an IP farm of multiple IP addresses (up to 255 addresses). The Shasta 5000 BSN monitors for cache server availability and temporarily drops an IP address destination from the list of available servers. Destination IP address-based hashing is used to choose the destined proxy server toward which to steer the traffic. Because of NAT support, the Web cache can be located anywhere in the network, in any PoP. It is not restricted to directly connected networks. There is no routing software required on the Web cache. An application of Web steering is tiered wholesaling of ISP services. The first tier ISP wholesaler may terminate all users and, based on which second tier ISP the user belongs to, forward all the user traffic out the trunk connected to the second tier ISP.
72
214659-B
73
Chapter 3 Access technologies

This chapter describes the access technologies, also referred to as aggregation technologies or encapsulations, that allow subscribers to gain access to the Shasta 5000 Broadband Service Node and the Internet. Subscribers accessing the network core via the Shasta 5000 BSN come into the Shasta 5000 BSN across various physical media and protocols comprising the access technologies. An access technology is terminated at the Shasta 5000 BSN on the line card appropriate to it. (This chapter also identifies the line cards that terminate the various access technologies.) No longer limited to dial-up access for individual subscribers or expensive connections for large corporations, current access technologies enable service providers to offer enhanced IP services with interactive content and differentiated services at reasonable cost. Because they are less costly to deploy than were previous access and aggregation technologies, new technologies give a wider range of users, both corporate enterprise and ISP subscribers, access to the ISP core and the Internet. Each level of access exists as a balance for service providers to offer their subscribers between cost, speed, and availability of facilities. Depending on the physical media and its bandwidth and speed, IP service access is categorized as follows: Broadband Broadband access media include xDSL, cable, and fixed wireless. They encompass speeds ranging from 144 Kb/s to well over 1.54 Mb/s. Narrowband Narrowband access media include dial-up and ISDN service. The maximum speed these technologies reach is 128 K. For instance, dial-up over copper pair reaches a speed range of 8 Mb/s to 32 Kb/s.
74
An access technology enables the subscriber to connect to the Shasta 5000 BSN in order to gain access to the ISP core or corporate enterprise to obtain services, to participate in an intranet, or to gain access to the Internet. A connection is a layer 2 entity that carries traffic from a single host or a network of hosts. An access technology is used on what is referred to as the access side of the Shasta 5000 BSNthat is, between the subscriber and the Shasta 5000 BSNas opposed to the trunk side technology, which establishes a subscriber connection from the Shasta 5000 BSN to an ISP or enterprise. Connections that enable subscribers to access the Shasta 5000 BSN can be static or dynamic. For instance, static connections include asynchronous transfer mode (ATM) virtual connections, T1 links, frame relay DLCI connections, and virtual LAN (VLAN) tag connections. Dynamic connections include Point-to-Point Protocol (PPP) over L2TP tunnels on the L2TP Network Server (LNS) and PPP sessions over a Point-to-Point Protocol over Ethernet (PPPoE) tunnel. (Connections occur on both the access and the trunk sides of the Shasta 5000 BSN.) Access connections terminate the subscribers layer 2 connection on the Shasta 5000 BSN. The subscriber session is then carried from the trunk side as IP traffic in a layer 3 session from the Shasta 5000 BSN to its destination at an ISP or corporate platform. This chapter describes the following access technologies: 1483 (1490) Routed and 1483 (1490) Bridged next PPP on page 77 IP Demux on page 84 L2TP on page 86 IPsec on page 89 ATMP foreign agent on page 92
1483 (1490) Routed and 1483 (1490) Bridged

This section gives a brief introduction to the 1483 Routed and 1483 Bridged protocols used with ATM and the 1490 Routed and 1490 Bridged protocols used with frame relay. Use of the bridged access method is required if your subscribers are connected to the DHCP server via the Shasta 5000 BSN.
214659-B
75
Both 1483 Routed and 1483 Bridged are terminated at the Shasta 5000 BSN on the ATM line cards (ALC). The Shasta 5000 BSN supports the following ALC line cards: OC-12, OC-3, DS-3, and E-3. Both 1490 Routed and 1490 Bridged are terminated at the Shasta 5000 BSN on a Channelized T3 (CT3) or Channelized OC-3 (COC3) line card. This section includes the following sections: 1483 Routed (1490 Routed) on page 75 1483 Bridged (1490 Bridged) on page 76
1483 Routed (1490 Routed)

Different from the needs of the single user on a directly-connected host, small businesses often require a fully routed connection across an access link. For this purpose, RFC-1483 Routed encapsulation [IP/1483/ATM] with VC Mux or LLC/ SNAP is commonly used for ATM connections and RFC-1490 LLC encapsulation is needed when several protocols are carried over the same VC. Routed encapsulation [IP/1490/FM] is commonly used for frame relay connections. For instance, these access methods offer a small business the ability to easily transition to DSL from use of a dedicated T1 line running a dynamic routing protocol between its router and its ISPs router. Some small businesses might implement dynamic routing (using RIPv2, OSPF, or BGP) across the DSL link if they are dual-homed to multiple ISPs. Figure 7 shows how dedicated RFC-1483 Routed is used to give a small business enterprise access to the Internet. In this figure, 1483 Routed is used from the subscriber to the Shasta 5000 BSN. IP over LLC/SNAP is used to route the traffic on the trunk side from the Shasta 5000 BSN into the ISP (core) backbone. Notice that, unlike for RFC-1483 Bridged, an external modem is not required.
76
Chapter 3 Access technologies Figure 7 Small business access using RFC-1483 Routed
ISP Core
IP LLC/SNAP 100BASE-T
IP 1483R ATM AAL5 ADSL
IP 1483R ATM AAL5 OC3
Subscriber 1483 Routed
ISP Routing
10031EA
1483 Bridged (1490 Bridged)

The first protocol architecture deployed in the bridging space was based on RFC 1483 Bridged. From the subscriber perspective, RFC 1483 Bridged can be dedicated or dynamic. The 1483 Bridged protocol for ATM is required if the subscriber is connected to the DHCP server via the Shasta 5000 BSN. The RFC 1490 Bridged protocol for frame relay is required if the subscriber is connected to the DHCP server via the Shasta 5000 BSN. RFC 1483 Bridged describes a method by which multiprotocol traffic may be bridged across the ATM and ADSL local loop between a host and a LAN switch or router. Because it provides for no address resolution mechanisms, the protocol relies on permanent virtual circuits (PVCs). Dedicated 1483 Bridged is used with an ATM connection (and DSLAM) from the subscriber to the Shasta 5000 BSN; it is so called (dedicated) because the system, which is always on (once connected), has a statically assigned IP address. Dynamic 1483 Bridged is used when a subscriber is connected to the Shasta 5000 BSN through a PPPoE session. The subscriber client is dynamically assigned an IP address when he or she logs in to the network using the PPPoE client shim. The subscriber may log in and log out on a short-term basis, with a new IP address assigned for each session. The session is set up when the client logs in and torn down when the client logs out.
214659-B
77
Figure 8 illustrates use of the dynamic RFC-1483 Bridged on the subscriber (access) side and ISP routing on the trunk side from the Shasta 5000 BSN to the ISP (core) backbone. Notice that an external modem is used.
Figure 8 Dynamic RFC-1483 Bridged CPE
PSTN Gateway ISP Core ADSL Modem DSLAM
Portal Server
IP 1483B ATM AAL5 ADSL
IP 1483B ATM AAL5 OC3
Subscriber 1483 Bridged
ISP Routing
10032EA
PPP
This section describes the Point-to-Point Protocol (PPP) and introduces its use over Ethernet and ATM. It includes the following sections: About PPP next PPPoE on page 80 PPPoA on page 82
About PPP
Originally developed for connecting serial dial-up sessions, the Point-to-Point Protocol (PPP) architecture, fully described in RFC 1661, offers a standard method of encapsulation for transport of higher-layer multiprotocol datagrams over a link such as a leased line or an access link connecting two points.
78
PPP has a signaling protocol used to negotiate all options required by the peers, which includes these phases: Link Control Protocol (LCP) negotiation The LCP is responsible for setting up, configuring, and testing the link. Authentication Network Control Protocol (NCP) A number of NCPs are used to establish and configure different layer 3 protocols (for example, IP, IPX, NETBUI). (The NCP supported by the Shasta 5000 BSN is IPCP for IP.) IP datagrams are encapsulated for delivery across the network by the addition of a protocol header at the beginning of each datagram. The header is used to identify the datagram that is encapsulated within the information field. Protocol ID x0021 identifies the packet as an IP datagram. Other values in the protocol header identify Link Control data and Network Control data packets. A CRC trailer is added to verify successful transmission across the link. PPP provides full-duplex operation. PPP options allow for additional configuration parameters and management functions. PPP is implemented at layer 2. It requires that devices at both ends of the connection be PPP-capable. Among the features PPP provides are the following: Simple security using PAP and CHAP protocols A mechanism for closing down the connection, when a session is completed A flexible means of authenticating users Per-session authentication Optional layer 3 address auto-configuration via DHCP Establishment of multiple concurrent sessions (either via separate ATM VCs or multiplexing via PPPoE) Transparency to layer 3 protocols (dominantly IP) Per-session encryption and compression Per-session billing through interaction with RADIUS Note: RFC1483 Bridged offers only a subset of these capabilities in their most basic deployment.
214659-B
79
PPP provides a flexible means of authenticating users. Based on the users fully qualified domain name (FQDN), the Shasta 5000 BSN can forward the users authentication request to the appropriate ISP RADIUS server. On successful authentication, a user can be allocated to the ISP and have IP policies applied via a service profile. Where there are requirements for login security of bridged users (user ID and password to ensure authorized access to IP services), or account configuration for bridged and PPP subscribers, the Shasta 5000 BSN can direct user HTTP traffic to a portal server at the ISP site. The personal network portal can be configured to provide users with customized Web-based screens that allow user login, provisioning of new services, or changes to existing services, as well as providing an interface into back-end authentication, accounting, and billing servers to propagate collected information. The Shasta 5000 BSN provides support for Multilink PPP (MLPPP), including support for dial-up networks with PPP sessions coming in from multiple L2TP tunnels. MLPPP allows multiple PPP sessions to be terminated and bonded into a single IP session, which increases throughput. The Shasta 5000 BSN can terminate up to eight PPP sessions in one bundle. These PPP sessions can be PPP over L2TP, PPP over HDLC (using a CT3 line card), and PPPoA. The bonding process followed is defined by RFC 1990. MLPPP provides inverse multiplexing functionality at layer 2. MLPPP provides redundancy by spreading PPP sessions across multiple, physical links. PPP is terminated at the Shasta 5000 BSN on the ATM line card (ALC), Fast Ethernet line card /Gigabit Ethernet line card (FELC/GELC), Channelized OC-3 (COC3), or the Channelized T3 line card (CT3). The Shasta 5000 BSN supports the following ALC line cards: OC-12, OC-3, DS-3, and E-3. Here are the supported communication sequences for the for PPP access methods and the line cards that terminate them: PPP/L2TP/IP/1483/ALC PPP/L2TP/IP/FELC or GELC PPP/High-Level Data Link Control (HDLC)/CT3 or COC3
80
PPPoE
PPP over Ethernet (PPPoE) provides the ability to connect a network of hosts over a bridging access device to a Remote Access Concentrator (RAC). Each host has its own PPP session, allowing for billing, access control, and type of service to be done on a per-user basis. A single host may have multiple PPPoE sessions, each with its own IP address. PPPoE requires that each PPP session learn the Ethernet address of its peer. For this purpose, a discovery protocol is used. PPPoE is used in DSL and cable because most of the DSL and cable modems are bridge devices. During the discovery phase, PPPoE service selection is made available to the client. This feature consists of support that sends a list of ISPs to the PPPoE client so that the client can choose which ISP to use. With its authentication and authorization processes, its accounting, auto-configuration, and dynamic destination capabilities, PPPoE allows for emulation of the Internet dial model. PPPoE enables a PC to access multiple destinations at the same time, depending on the operating system used. As defined in RFC 2516, PPPoE requires that a lightweight client layer, called a shim, be installed between the subscribers PC PPP stackthe dial up client within MS Windows, for instanceand the Ethernet driver. The client shim places a small encapsulation header between the PPP header and the Ethernet MAC layer. In most cases, the subscribers ISP provides the shim on CD-ROM when the user subscribes to the ISP service. However, every operating system has a PPP client, so no new client software is required for PPP. The PPPoE process works in the following way: The PC encapsulates the PPP session within the shim and sends it over the local Ethernet segment to the modem. The modem replaces the Ethernet link and physical layers with the RFC 1483 Bridged encapsulation over ATM AAL5 and the ADSL physical layer, forwarding the traffic to the DSLAM. The DSLAM terminates the ADSL physical layer, mapping multiple subscriber connections into an upstream ATM trunk. The upstream ATM trunk is an OC3 or DS3 trunk that connects to a regional ATM network before arriving at a Shasta 5000 BSN located in a layer 3 PoP.
214659-B
81
The Shasta 5000 BSN removes the PPPoE shim and routes the traffic onto the subscribers ISP backbone, after the subscriber is authenticated. The Shasta 5000 BSN may also divert traffic to a PSTM gateway or a personal network portal.
Depending on how it is used, PPPoE is terminated at the Shasta 5000 BSN on the following line cards: FELC/CELC, ALC, Channelized OC-3 (COC3), or the Channelized T3 line card (CT3). The Shasta 5000 BSN supports the following ALC line cards: OC-12, OC-3, DS-3, and E-3. The following list identifies the supported communication sequences of the PPPoE access method and the line cards that terminate those sequences: PPPoE/FELC or GELC PPPoE/1483B/ACL PPPoE/VLAN/FELC or GELC
Figure 9 depicts a deployment that uses PPPoE as the subscriber access method. The example assumes that the intra-PoP interconnection is Fast Ethernet (FE); ATM could also be used. If an ATM uplink is used, the provider will deploy RFC 1483 Routed encapsulation.
Figure 9 Extending the PPP session across the subscribers Ethernet segment: PPPoE
RADIUS Server Portal Server ADSL Modem DSLAM PSTN Gateway ISP Core
PPPoE Client
IP PPP PPPoE LLC/SNAP 100BASE-T
IP PPP PPPoE/1483B ATM AAL5 ADSL
IP PPP PPPoE/1483B ATM AAL5 OC3
Subscriber PPP Within PPPoE
ISP Routing
10071EA
82
PPPoA
PPP over AAL5 (PPPoA) protocol defines a framing mechanism for PPP using AAL5. PPPoA allows use of facilities defined for PPP including LCP and NCP, authentication, and compression. PPP facilities require a point-to-point connection. The following list of tasks describes the PPPoA process: PPP treats the underlying AAL5 layer as a bit synchronous PPP link. The PPP link corresponds to an ATM AAL5 virtual connection (VC). The AAL5 layer provides control signals to the PPP layer. It indicates when the VC link is connected (up) and when it is disconnected (down). The LCP uses these signals as an indicator specifying whether the link is up or down. The virtual connection is a point-to-point, full-duplex connection that supports either permanent virtual circuits (PVCs) or switched virtual circuits (SVCs). No multipoint connections are supported.
A PPP-compatible customer premises equipment (CPE) system will encapsulate the PPP session based on RFC-1483 for transport across the ADSL loop and DSLAM. PPPoA is terminated at the Shasta 5000 BSN on the ALC line card (PPPoA/ ATM). The Shasta 5000 BSN supports the following ALC line cards: OC-12, OC-3, DS-3, and E-3.
MLPPP
MLPPP is a method of splitting, recombining, and sequencing datagram packets across multiple logical data links, thereby increasing the potential for multiple, simultaneous channels between a Shasta BSN and a destination device. MLPPP enables an Internet Service Provider (ISP) to work with multiple PPP sessions that can be terminated and bound into a single IP session. You can establish MLPPP bundles for authenticated (Auth) subscribers and for unauthenticated (No Auth) subscribers.
214659-B
83
MLPPP Auth bundles

For an Auth bundle, the Subscriber Manager creates the bundle automatically, after you establish the connections and configure the subscriber.
MLPPP No Auth bundles

For a No Auth bundle, you create an MLPPP connection (a super connection) on a specific slot, and ensure that the links that make up the bundle share the exact End Point Descriptor (EPD) value and class. The following table shows the choices for EDP class.
Table 4 MLPPP End Point Descriptors
EDP Class Local IP MAC Value An alphanumeric string An IP address A drop-down list provides for selection of Ethernet management interfaces: mgmt-eth0 mgmt-eth1 mgmt-eth2 mgmt-eth3 Blank
None
An access connection must have one of the following encapsulation types to join an MLPPP bundle: PPP/ATM PPP-HDLC PPP-FR ppp_llcsnap ppp_l2tp ppp_hdlc pppoe_data
84
After the first connection joins an MLPPP bundle, any subsequent connections that need to join must have the same EPD class and descriptor as the first connection. SCS compares these two fields, and if they are not the same, they are changed automatically and saved in the database to match the first connection's EPD values.
IP Demux
IP Demux is an access method that allows for the identification and binding of multiple subscribers behind one access connection. It is used if multiple subscriber traffic is sent over a single access connection. It offers an individualized set of services that could include membership in a virtual private network (VPN). IPDemux can be used for static or preconfigured subscribers with their own IP addresses or multiple IP address ranges with a list of services. Subscribers can be automatically created when a new IP address is detected, using a template with a set of services. This section describes these aspects of the IP Demux feature. Prior to Release 2.0, the Shasta 5000 BSN was only able to apply service policies at the subscriber PVC level, but it had little control over subscribers at the IP address level. To support deployment scenarios such as cable modem solutions, it became necessary for the Shasta 5000 BSN to support multiple subscribers behind a single access connectiontypically a Fast Ethernet (FE) connection between the Shasta 5000 BSN and the cable modem headend. For this to be possible, the Shasta 5000 BSN needed to be able to identify its subscribers based on their IP addresses and allow subscribers their own, individualized service policies. By providing the Shasta 5000 BSN with the ability to differentiate multiple subscribers behind one access connection, the IP Demux feature met this requirement. The IP Demux feature includes these components: Container
214659-B
85
The main component, or concept, underlying the IP Demux feature is the container. The IP Demux container subscriber is a logical access connection to the Shasta 5000 BSN that defines an IP subnet. A container can contain multiple subscribers. It can be dynamically created or preconfigured. Each individual subscriber or group of subscribers belonging to a container can have their own set of service policies. Subscriber template A subscriber template is a special type of subscriber that provides a set of predefined parameters specifying selected services for all automatically created (autocreated) dynamic subscribers within the same container of the Shasta 5000 BSN. You must have a subscriber template in order to create an IP Demux subscriber container. Dynamic subscriber Dynamic subscribers, also called dynamic child subscribers, are automatically created whenever the Shasta 5000 BSN detects a new IP address. New IP addresses can be detected through DHCP services. They are also detected if the subscriber device has a preconfigured IP address but that address is not yet registered with the Shasta 5000 BSN. When these subscribers send out their first packets, the Shasta 5000 BSN verifies that the IP address of the sender is valid within the range of the container. If the address is valid, the Shasta 5000 dynamically creates the subscriber. Static subscriber Static subscribers, also called static child subscribers, are preconfigured subscribers that have their own IP addresses. A static subscriber could also be preconfigured with multiple IP address ranges with a list of services. Individual services or policy profiles can be tailored to each subscriber or range of subscribers. Depending on the communication process used, IP Demux is terminated at the Shasta 5000 BSN on one of the following line cards: FELC or GELC/CT3/ALC/ COC3. The Shasta 5000 BSN supports the following ALC line cards: OC-12, OC-3, DS-3, and E-3. The following communication sequences are supported for the IP Demux access method: IP Demux/FELC or GELC IP Demux/VLAN/FELC or GELC
86
IP Demux/1493 (Routed or Bridged)/ALC IP Demux/1490 (Routed or Bridged)/CT3 or COC3
L2TP
Layer 2 Tunneling Protocol (L2TP), which is based on RFC 2661, is a tunneling protocol that is used to tunnel a PPP session. It is used for aggregation of PPP subscribers to a common point and for virtual private network (VPN) access to corporate networks. L2TP or PPP/L2TP is used largely for dial support for telecommuters, after the connection has been terminated at the RAS or Shasta 5000 BSN. L2TP/IP is sometimes used to provide a secure connection from the subscriber to the Shasta 5000 BSN. For dial support using modems, subscribers can dial into a Remote Access Server (RAS). The subscriber session is terminated on the RAS and connected through an L2TP tunnel to a Shasta 5000 BSN, for instance. From the Shasta 5000 BSN, the subscriber is connected to the target ISP backbone or corporate backbone. PPP over L2TP (PPP/L2TP) is used most commonly for telecommuters dialing into the network. If the subscriber dials into a DSLAM, PPPoA is used from the subscriber to the Shasta 5000 BSN. If the subscriber is bridged, PPPoE is used from the subscriber to the Shasta 5000 BSN. Figure 10 shows the process when PPPoE is used.
214659-B
Chapter 3 Access technologies Figure 10 PPP over L2TP

ADSL Modem PoP DSLAM Corporate Site
87
LAC IP PPP PPPoE LLC/SNAP 100BASE-T IP PPP PPPoE/1483 ATM AAL5 ADSL IP PPP PPPoE/1483 ATM AAL5 OC3 IP PPP L2TP IP 1483R ATM AAL5 DS3 L2TP
LNS
PPPoE
10145EA
In either case, the ATM or Ethernet connection is terminated at the Shasta 5000 BSN within the access network. Then the subscriber is connected via PPP/L2TP to another Shasta 5000 BSN, or third-party platform, for connection to the target ISP backbone or corporate backbone. Many subscribers may be aggregated at the Shasta 5000 BSN at the access edge and tunnelled, using PPP/L2TP, to various systems, such as another Shasta 5000 BSN or a router, for connection to the target ISP backbone or corporate backbone. Either RADIUS or IPsec can be used with L2TP to further implement authentication and security. L2TP with IPsec can also be used as a tunnelling mechanism from the subscriber to the Shasta 5000 BSN at the access edge. Because connections from the subscriber to the Shasta 5000 BSN are isolated and intrinsically secure, this use of L2TP is rare. L2TP depends on PPP to establish the dial connection to the corporate site and perform the first authentication check using PAP or CHAP. When the PPP connection is established, L2TP begins setting up the tunnel connection. After the PPP sequence completes, L2TP may authenticate the caller again, this time using RADIUS authentication to provide a more secure authentication procedure.
88
Two types of tunnels can be created under L2TP: voluntary and compulsory.
Voluntary tunnels
An L2TP tunnel set must be configured in advance by the network administrator on the Shasta BSN serving as the Local Access Concentrator (LAC), specifying a tunnel password and other parameters. The tunnel set must have at least one L2TP Network Server (LNS). If the LNS is not a Shasta BSN, you need to supply its IP address.
Compulsory tunnels
Compulsory tunneling is initiated by the RADIUS server that authenticates the subscriber. No preconfigured tunnel set to an LNS is needed. Compulsory tunneling allows the administrator to define a wildcard LNS password and enables the same tunnel password to be used for all LNS systems in the network. When a subscriber packet arrives on the LAC Shasta BSN, the LAC sends subscriber identification information to the appropriate RADIUS server. If that subscriber is authenticated for access to the wildcard LNS tunnel, the RADIUS server sends several tunnel parameters to the LAC. The RADIUS server may or may not supply a tunnel password to the LAC. If the tunnel password is not supplied by the RADIUS server, the tunnel password must be already configured on the LAC. When the LAC receives information from the RADIUS server, it uses the password (either the one already configured on the LAC by the network administrator or the password supplied by the RADIUS server) to negotiate with the LNS at the specified tunnel end point. The LAC and the LNS then dynamically create an L2TP tunnel from the LAC to the LNS. Next, the subscribers packet is forwarded to the LNS. However, if the customer has configured a tunnel password as a fourth parameter on the RADIUS server, that tunnel password is sent with the other tunnel parameters to the LAC, and it overrides the wildcard LNS default password configured on the LAC. The parameters supplied by the RADIUS server identify the LNS to which the LAC will dynamically configure an L2TP tunnel for that subscriber.
214659-B
89
Note that the LNS is a wildcard; it is not specified by the network administrator in advance. The customer may have several or many LNS servers configured for use with this LAC. Thus the customer may program the RADIUS server to balance the load among the LNS systems. The following access connections include use of L2TP: PPP/L2TP/IP/FE(GE) PPP/L2TP/IP/1483/ALC L2TP/IP
IPsec
IPsec was designed by the IETF as an end-to-end mechanism for ensuring data security in IP-based communications. It provides for secure transport of data across TCP/IP-based LAN or WAN environments, and it is not specific to any operating system. IPsec supports applications that encrypt all traffic at the IP level and authenticate it, or simply authenticate it. IPsec is based on the evolving Internet protocol suite for data encryption, host authentication, and key exchange expressed in RFC-2401 and other RFC papers. IPsec provides the ability to create IP tunnels. The Shasta 5000 BSN supports use of IPsec tunnels on both the access (subscriber) side and the trunk (service provider) side. For VPNs, IPsec (on the trunk side) provides security, allowing traffic to flow over the common, shared infrastructure in an encrypted, private fashion. It can secure any business communication over the Internet. It includes a wide range of strong encryption standards and a secure key management solution. The overall IPsec architecture includes an Encapsulation Security Payload (ESP) for both data integrity and data encryption. The Internet Key Exchange (IKE) protocol is used with IPsec for negotiation. Although a preshared key is assigned between the customer premises equipment (CPE) and the Shasta 5000 BSN as part of the IKE negotiation, the key is used to seed another auto-generated keya new keyto determine the tunnel setup. This new key is not known between the CE site and the network site allowing for secure tunnel setup. Thus, preshared keys are a secure method for negotiating tunnels.
90
IPsec used as a tunneling mechanism allows service providers to extend their network reach across other Internet service provider (ISP) networks where required without necessitating coordination and agreement for VPN traffic. IPsec can be used with or without DES or 3DES encryption. With encryption and authentication, IPsec enables service providers to offer their customers a level of trust in regard to secure transport of data across outsourced infrastructure and other IP networks. The SCS takes care of the preshared keys when implementing VPRNs. The only time someone must configure keys us when setting up an IPsec tunnel to another device.
Contivity VPN Client termination

Contivity VPN Client termination provides consistent IP services applications to Remote access IPsec subscribers using Contivity Windows Client software 4.60 or later (also known as Extranet Access Client, EAC). Subscribers can connect directly to the Shasta BSN, using Contivity VPN Client termination, over a secure IPsec tunnel. Client computers must be running one of the following operating systems: Windows 95, 98, 2000, NT, XP, or ME
RADIUS support includes: Configuration of VPRN membership for a Contivity VPN Client Vendor specific attributes (VSA), as with PPP subscribers IP address specification Subnet mask specification Maximum transmission unit (MTU) specification
The following figure shows a Contivity VPN Client and a Shasta BSN, with the implementation of a split tunnel configuration.
214659-B
Chapter 3 Access technologies Figure 11 Contivity VPN Client termination with a split tunnel configuration
91
IPsec tunnel termination supports clients like the Contivity VPN client using tunnel mode to connect to the Shasta BSN, which serves as an IPsec gateway device. Contivity VPN Client initiated sessions may be terminated either on the ISP default IP address or on a trunk interface belonging to the Shasta BSN. By default, the ISP default IP address is selected. The client initiates an IKE exchange with the Shasta BSN, which authenticates the group. The specific user is authenticated using legacy (PAP) authentication. Then, using group membership, the Shasta BSN sends the client configuration by way of an authenticated and secure channel that has been provided by the first phase of negotiation. Authentication and encryption key material is then generated for the secure tunnel according to the negotiated configuration. Contivity VPN Client termination includes the following features: Aggressive mode negotiation, using ISAKMP messages Group (tunnel) authentication User authentication via RADIUS VPRN membership through SCS and RADIUS Private IP address assignment from a local address pool on the Shasta 5000 BSN, DHCP server, or the address pool on the RADIUS server Split tunneling
92
Password storage option on the client system RADIUS attribute support (VSA, IP address, subnet mask MTU) RADIUS-based accounting (packets in, packets out, bytes in, bytes out, drops in, drops out) Session timers, idle timers, and keepalive timers between the Shasta BSN and the Contivity VPN client Quote of the Day (QoTD) banner support High availability - SSM or SSP failover High availability - ISP device-level failover (for clients) MODP Diffie-Hellman Groups 1 and 2 Perfect Forward Secrecy (PFS) Payload (ESP) support Encryption: DES; 3DES; Hash: MD5, SHA-1 SCS-based configuration and provisioning CLI-based debugging Consistent IP services applications to remote access IPsec subscribers Tunnel end point selection (IPsec trunk interface termination) UDP NAT traversal: Contivity VPN Clients can be located behind NAT devices Token-based authentication: overcomes the limitations and security risks posed by single-factor authentication, making use of the ACE/Server and SecureID token-based system provided by the RSA Corporation
ATMP foreign agent

The Ascend Tunnel Management Protocol (ATMP) is a UDP-based protocol for managing (opening, maintaining, and closing) logical tunnels through which mobile nodes (MNs) can communicate with hosts on a home network (HN). With ATMP foreign agent (FA) software running on a Shasta BSN, each mobile node (typically a fixed or mobile PC) behaves as though it were attached directly to the home network, with end-to-end throughput determined mainly by the throughput of the ATMP tunnel and the subscriber access connection. The FA is one component of a typical ATMP network configuration, such as the one shown in Figure 12.
214659-B
Chapter 3 Access technologies Figure 12 Basic ATMP network configuration

Host Server Host
93
PPP
Home Network Shasta 5000 BSN IP GRE Tunnel Internet RADIUS Client ATMP HA Ascend MAX TNT
Access WAN Mobile Node (Subscriber)
PPP
ATMP FA
Subscriber Authentication
RADIUS Server
10288EA
In the preceding figure: Home Network (HN) refers to a private network, such as a corporate enterprise network. Mobile Node (MN) refers to a remote host requiring access to a home network over media such as PSTN, or ISDN, a corporate ATM WAN, an Ethernet LAN, or a leased synchronous line.
94
Foreign Agent (FA) refers to a software entity that communicates with an ATMP Home Agent (HA) in a device attached directly or indirectly to the subscribers home network. When RADIUS subscriber authentication succeeds, the ATMP FA opens a GRE (generic routing encapsulation) tunnel to the ATMP HA, enabling the user to communicate with hosts and servers on the home network. RADIUS client refers to a software component that: Sends user authentication requests from the Shasta BSN to a RADIUS server Forwards user responses to any authentication challenge from the RADIUS server Passes connection (GRE tunnel establishment) information through PPP to the ATMP foreign agent (FA) if authentication succeeds RADIUS server refers to server that authenticates any Mobile Node (MN) and authorizes access to the subscribers home network. The RADIUS server maintains user profiles in an authentication database. When authentication succeeds, the RADIUS server passes ATMP connection attribute values through the RADIUS client and PPP to the ATMP FA on the Shasta BSN, which uses them to establish a GRE tunnel to the subscribers home network. Home Agent (HA) refers to a software entity that terminates the home network end of the FA-to-HA GRE tunnel.
Control of VPRN dynamic routes

You can enable or disable BGP, OSPF, and RIP routing for the access side of a VPRN (VPN-only or VPN + Internet). This capability requires a corresponding control feature to protect private routes in a VPN + Internet VPRN. The control feature allows you to block or permit the propagation by the routing protocol of dynamic subscriber routes from the VPRN FIB into the FIB for the ISP.
BGP configuration for VPRN subscribers

The Shasta BSN supports BGP routing on VPRN access connections. Access types include PPP, 1483 routed, 1483 bridged, 1490 routed, 1490 bridged, and IPsec.
214659-B
95
VLAN
The Shasta 5000 BSN provides support for virtual local area network (VLAN) tagging on FE and GE line cards and on a FE port on the CMC card. VLANs (IEEE 802.1q) allow shared media, such as Ethernet, to be used by groups of users. To accomplish this, Ethernet frames are tagged with a VLAN ID, which identifies the group the frame belongs to. The Shasta 5000 BSN identifies frames as from particular subscribers configured on an Ethernet connection through their VLAN tags. Associated with IEEE 802.1q is IEEE 802.1p, which defines a method of setting user priority on Ethernet frames through tagging. The Shasta 5000 BSN is able to map DiffServ code points to IEEE 802.1p user priority levels. Subscribers bound to a VLAN-tagged Ethernet connection have the same options as are provided for 1483 Bridged connection-based subscribers. VLAN subscribers can be configured as follows: Part of a bridge group An independent bridge subnet A PPPoE subscriber A single IP Demux container
DHCP Option 82 identifies the subscriber initiating the DHCP request. It is supported on the Shasta 5000 BSN via the format hostname:slot/port/vlanid. Option 82 is configured in the DHCP profile, just as it is for 1483 Bridged connections.
96
214659-B
97
Chapter 4 Routing protocols

This chapter describes the routing protocols supported by the Shasta 5000 Broadband Service Node. Routing protocols are used to learn the topology and discover the possible routes to the target destination in order to determine the best route to use to send a packet. The chapter includes the following sections: Routing on the access and trunk sides, next About routing on page 99 Supported routing protocols on page 100
Routing on the access and trunk sides

The Shasta 5000 BSN supports routing on the access side (from the Shasta 5000 BSN toward the subscriber) and on the trunk side (from the Shasta 5000 BSN toward the ISP backbone or the corporate enterprise backbone). All routing protocol parameters configurable for the trunk side are also configurable for the access side. The Shasta 5000 BSN supports the following routing protocols: Routing Information Protocol (RIP) Open Shortest Path First (OSPF) Border Gateway Protocol (BGP) Intermediate System-Intermediate System (IS-IS)
For the Shasta 5000 BSN, routing applies to individual subscribers only. That is, routing is not supported as applied to subscriber templates.
98
The number of subscribers running routing should be less than or equal to 500. The maximum number of routes per Shasta 5000 BSN is 110,000 routes across all routing instances (access and trunk). The number increases to 300,000 if the SSM with 512 MB of memory and CMC with 1 GB of memory are used.
Access side
Either static or dynamic routing can be used on the access side, depending on the size of the network behind the subscriber and the individual subscribers need. If the network behind the subscriber is not too extensive, static routing is commonly used on the access side. Dynamic routing eliminates the need to manually specify all of the networks statically reachable through the subscriber. The Shasta 5000 BSN supports reachability for multiple IP subnets behind the Customer Premises Equipments (CPEs) router. The routing protocol used by the Shasta 5000 BSN is the protocol that the subscriber network supports. Routing Information Protocol (RIP) is commonly used on the access side because it is widely supported. For instance, a scenario in which RIP might be used is one in which the Shasta 5000 BSN uses dynamic routing to discover the network topology behind a subscriber host. The subscriber network might include branch sites and a headquarters site. The Shasta 5000 BSN supports OSPF, RIP, and BGP on the access side for both ISP and VPRN subscribers. Intermediate System-Intermediate System (IS-IS) is not supported on the access side. Access side routing is supported on all types of access connections except for IP Demux. Routing can run on IPsec on the access side connection if the peer router supports it.
Trunk side
On the trunk side, the Shasta 5000 BSN uses the routing protocol supported by the ISP core (or enterprise core) in order to discover the topology of the ISP (or enterprise) network and all possible routes to the network. Typically RIP or Open Shortest Path First (OSPF) is used on the trunk side because these protocols are widely used by ISP and enterprise networks.
214659-B
99
About routing
Routing is the process of identifying network topologies and the networks and links that are available in order to deliver packets in the fastest, most direct manner possible versus cost of delivery. This process entails assessment and use of information that describes paths to large numbers of endpoints and allows for decision making around what to do if a link fails. Routing relies on protocols (collectively referred to as routing protocols) that establish shared and consistent routing tables in a networks routers. Routing protocols use these tables to determine the next hop for a packet. Within the Internet, distinctions are made between interior and exterior routing protocols because of the different tasks these types of protocols carry out and impose on the routing system. The following three levels of routingeach using a different type of routing protocolare distinguished: The top level of routing pertains to the Internet backbone, interconnecting multiple self-regulating systems called Autonomous Systems (AS). An AS is a domain of routers and networks that are administrated under a single authorityfor example, a corporate network. Routing between two ASs uses an exterior protocol. These discrete entities (ASs) have separate owners. Thus, there is no trust implicit to the interconnection between the routers of these entities, whereas a high degree of trust exists between mutually cooperating routers within a single AS. The middle level of routing consists of routers within an AS, such as a campus network, and these routers use an interior protocol. Because they belong to the same entity, routers within an AS cooperate. The bottom level of routing is comprised of routing within LANs, such as Ethernet-based LANs.
Gateways mediate between interior and exterior routing. RIP and OSPF are commonly used as interior protocols. Border Gateway Protocol (BGP) is the protocol most commonly used for exterior routing.
100
Supported routing protocols

This section describes the routing protocols supported by the Shasta 5000 BSN. The following routing protocols are supported on the Shasta 5000 BSN: Routing Information Protocol (RIP), next Open Shortest Path First (OSPF) on page 100 Border Gateway Protocol (BGP) on page 101 Intermediate System-Intermediate System (IS-IS) on page 102
Routing Information Protocol (RIP)

The Shasta 5000 BSN supports RIP version 1 and version 2. RIP is a distance-vector, interior routing protocol that uses a hop-count metric, where infinity is defined to be 16. Thus, RIP supports a maximum of 15 hops between destinations. However, the RIP hop count metric is not efficient or economical. RIP entails slow convergence and builds a flat network. When RIP is used, peer routers exchange distance vectors at regular, fixed intervals and a router is declared dead if it does not respond within a set time frame.
Open Shortest Path First (OSPF)

By contrast to distance vector protocols such as RIP, the Open Shortest Path First (OSPF) protocol is a link-state protocol that builds topology maps within an area. The links are described in terms of costs, with packets forwarded on the lowest cost path from source to destination. OSPF can be used for access link routing with area aliasing to support multiple subscribers with the same area ID. It includes provisioning that supports area ID, interface costs, and types of outgoing routes (whole table or default) sent to subscribers. To route packets, OSPF uses the concept of areas within an AS. An OSPF network is composed of multiple areas, one of which is the backbone. All routers in the same area have the same link-state database (LSDB). There are three area types: normal, stub, and not-so-stubby (NSSA).
214659-B
101
OSPF is advantageous over RIP in the following ways: it converges quickly and resists routing loops; its update procedures reduce network traffic.
Border Gateway Protocol (BGP)

The Border Gateway Protocol (BGP) is an exterior routing protocol. BGP is supported on both the access and trunk sides. It is typically used across the Internet backbone to route between organizations and ISPs. BGP routers use TCP to communicate with one another, which ensures reliable packet delivery for the routing protocol. The Shasta 5000 BSN supports both external peering BGP (eBGP) and internal peering BGP (IBGP). eBGP is used between Autonomous Systems (AS). IBGP is used within an AS between border routers. Here are some of the BGP features supported by the Shasta 5000 BSN: Peer groups For ease of configuration and efficient operation, BGP peers with similar outgoing route policy can be configured as peer groups. Route dampening, characterized by attempts to minimize the impact of oscillating and fluctuating networks on the global Internet and large providers Every time a route from an eBGP peer goes down, a certain penalty is applied. If the penalty reaches a certain threshold, the route is not advertised to the providers internal or external peers. Penalties are decreased over time, and the route is advertised again after a period of stability. Route reflectors An IBGP route reflector has the following characteristics: It is a mechanism for reducing the IBGP full mesh. It designates clusters of routers. Inside a cluster, one or more routers are route reflectors. Other routers in a cluster only peer with these route reflectors. route reflectors in all clusters still require full-mesh peering between themselves.
102
Intermediate System-Intermediate System (IS-IS)

The Intermediate System-Intermediate System (IS-IS) Open Systems Interconnect (OSI) routing protocol is an intra-domain protocol and link-state routing protocol that utilizes the Dijkstra algorithm. (Intermediate system is an OSI term for router.) The Shasta 5000 BSN supports the following two modes of sending IS-IS packets in IP environments: Using each interfaces native link layer directly Encapsulated in IP (as per an Internet draft) This mode is supported only on Ethernet types of Internetthat is Ethernet, Fast Ethernet, and Gigabit Ethernet. An IS-IS router sends hello packets and builds adjacencies. It creates a Link State PDU (LSP) and floods it everywhere. It receives LSPs from its neighbors. It runs the Dijkstra algorithm to calculate routes. When adjacent changes occur, it creates a new LSP that reflects the changes and floods it everywhere. When new LSPs are created or received, IS-IS reruns the Dijkstra algorithm and calculates new routes. IS-IS has two levels of hierarchy: The level 2 (L2) topology is similar to the OSPF backbone area. The level 1 (L1) area is similar to the OSPF stub area.
The L1 routing knows the topology of its own area only. Traffic to other areas is sent to the closest L2 intermediate system. If a L1 area is connected to another router not in the same area, it will not bring up the adjacency. L2 knows about intermediate systems in other areas. Frequently, L2 must also route inside the areas of these other intermediate systems, so L2 often performs both L1 and L2 routing. Transit traffic requires IS inside the area to know about other areas. L2 must form a contiguous backbone. The L2 backbone is comparable to OSPF area 0.
214659-B
103
Chapter 5 Content technologies

This chapter describes the features provided by the Shasta 5000 Broadband Service Node that support content delivery networks. Various content technologies are sometimes used in combination to create features. For instance, content filtering relies on Web steering; it can also include use of Personal Content Portals for subscriber authentication and authorization. This chapter includes the following sections: Personal Content Portals This section describes the Personal Content Portal technology. For complete details on Personal Content Portals and how to implement them, see the Nortel Networks Shasta 5000 Broadband Service Node Personal Content Portal Implementation Guide. Content filtering Web steering
Personal Content Portals

One way in which service providers and corporate enterprises can participate in the content delivery network is by using the Shasta 5000 BSN to offer personalized content services at the subscriber edge. The Personal Content Portal is a platform-independent content delivery software engine that operates in conjunction with the Shasta 5000 BSN. Using the Service Creation System (SCS) graphical user interface, a service provider can create Personal Content Portal policies for each subscriber. These policies make it possible for the Shasta 5000 BSN to redirect subscriber HTTP requests from the Web site the subscriber intended to a configured Personal Content Portal Web server where additional policies can be applied and content incorporated. (The
104
ability of the Shasta 5000 BSN to direct subscribers to the Personal Content Portal for required viewing is largely what makes Personal Content Portals possible.) Subscribers may visit their intended Web sites only if the software at the Personal Content Portal instructs the Shasta 5000 BSN to allow the subscriber to do so. The Personal Content Portal enables the subscriber to maintain an identity. The subscriber becomes known to the service provider as a unique individual with customized content needs. Subscriber visibility makes possible the generation of a whole new range of service models, including delivery of locally customized content, personalized advertising, and self-provisioning. A service provider may use a Personal Content Portal Web site for a number of purposes. The service provider can adapt the Personal Content Portal server to offer the subscriber a personalized Web page and various hosting solutions. An Internet service provider (ISP) might use a Personal Content Portal to deploy a palette of high-touch services to subscribers or a menu of service packages. Note: Personal Content Portals can be used to apply service policies and profiles to a subscriber only after the subscribers initial profile or policies are applied. After a subscribers profile is created and policies are applied, service providers might allow the subscriber to provision his or her own services and apply these services immediately. Self-provisioning of services enhances the experience of broadband access, which is about increasing speed and delivering services faster to the user. Self-provisioned policies are automatically applied to the subscriber profile. In addition to specifying the services they require, such as a firewall or virtual private network (VPN) membership, subscribers can provide information for billing. Subscribers wanting to change their services may do so readily. For instance, subscribers needing additional bandwidth to receive a critical file immediately can quickly upgrade to a premium service for better throughput. Together, the Personal Content Portal and the Shasta 5000 BSN dynamically enable the requested services, freeing the network operator from these provisioning tasks.
214659-B
105
In addition to service selection, the Personal Content Portal enables the service provider to offer customized content to the subscriber. As Figure 13 shows, Personal Content Portals may display advertisements or service-provider branding. By understanding the subscriber identity, the service provider may inject personalized, focused advertising and content, generating new revenue streams.
Figure 13 Delivering customized content to subscribers
Weddings
Shasta 5000 BSN
Customized Content
BigTime NEWS
Portal Server
Weddings eddings
BigTime NEWS
10073EA
The HTTP hijacking capability enables the service provider to direct subscriber traffic to an appropriate Personal Content Portal. For instance, one application of Personal Content Portal use allows the subscriber to obtain broadband Internet access only while retaining an open toolbar that injects advertising or targeted user content. In this scenario, the service provider receives advertising revenue and the subscriber is permitted to burst above the connected access rate. The Personal Content Portal content engine software provides the capability to implement this feature. Other models include directing the subscriber to the Personal Content Portal at specified intervals to view advertisement. The service provider can provide the Personal Content Portal as part of a server farm at the access point-of-presence (PoP). The Personal Content Portal policy can be configured to apply to groups of subscribers or an individual subscriber, providing flexibility and scalability for all levels of service providers from ISP to wholesale environments.
106
Additionally, the service provider might use the Personal Content Portal Web site to offer listings of destinations or services such as video streaming.
How it works
If a subscriber is configured for Personal Content Portal support, when the subscriber logs in to the network, that subscriber is directed by the Shasta 5000 BSN to the service providers portal server (via HTTP interception). Instead of presenting the subscriber with the expected HyperText Markup Language (HTML) page specified by the universal resource locator (URL) the user entered, the Shasta 5000 BSN redirects the subscriber request to the Personal Content Portal. The subscriber is then presented with specific HTML pages from the Personal Content Portal. For instance, a customized home page might be pushed to the subscriber or the subscriber might be presented with a menu of services. There are two modes affecting subscribers that are managed by the Personal Content Portal technology: Captive mode, a state in which an HTTP request has been captured (or hijacked) and redirected to an external Personal Content Portal server and URL. Noncaptive mode, a state in which the subscriber is allowed to visit the intended Web site or to browse freely. The subscriber session enters noncaptive mode only if the portal server directs the Shasta 5000 BSN to switch the subscriber from captive mode. After the configured session time has expired, the subscriber may be redirected to visit the Personal Content Portal site again.
A subscriber can be forced back to captive mode by a command from the Personal Content Portal to the Shasta 5000 BSN or expiration of a timer that the ISP or corporate enterprise can set. In summary, the mandatory Personal Content Portal process works in the following way, according to the following steps: 1 2 The ISP defines a Personal Content Portal policy and applies the policy to its subscribers. When the subscriber enters a URL, the Shasta 5000 BSN receives the subscriber HTTP request and captures, or hijacks, it.
214659-B
107
3 4
The Shasta 5000 BSN modifies the hijacked HTTP request, adding additional subscriber information and the IP address of the Shasta 5000 BSN. The Shasta 5000 BSN redirects the original HTTP request, sending it to the Personal Content Portal Web site, based on attributes specified in the portal policy.
The service providers Personal Content Portal server (external to the Shasta 5000 BSN) communicates with a portal task on the Shasta 5000 BSN. The Shasta 5000 BSN Personal Content Portal support provides the ability to: Release the subscriber from captive mode. Replace the subscribers services with a new set of services. Recapture the subscriber. Authenticate the subscriber using RADIUS. Configure policy for the subscriber. Allow HTTP traffic to specific networks. Change dynamic VPN membership.
Figure 14 shows how HTTP requests from a subscriber destined for a specific Web site are captured and redirected by the Shasta 5000 BSN to a Personal Content Portal Web site. In this scenario, the Personal Content Portal presents an interface to allow new subscribers to open an account. The Personal Content Portal uses a RADIUS server to authenticate existing subscribers. It uses a separate server for accounting and billing purposes.
108
Chapter 5 Content technologies Figure 14 Personal Content Portal process flow

Existing User Login User Name Password Change Details New User Account Name Address Telephone Credit Card Service Level
Personal Content Portal Radius/Authentication Server Hijacked HTTP Request Web pages Captive Mode Switch Accounting and Billing Server
ISP Backbone HTTP Request Subscribers PC Shasta 5000 BSN

10097EA
The policy defined for a subscriber through the Shasta 5000 BSN SCS defines how non-HTTP traffic and HTTP traffic are to be handled when the subscriber is in the captured state. For instance, a subscriber policy might allow DHCP and DNS but drop everything else.
Personal Content Portal SCS specification

The following Personal Content Portal attributes are specified through the SCS Policy Editor: The path to the page within the Personal Content Portal Web site that the subscriber must view (for example, the URL /cgi-bin/index.cgi) The amount of time a subscriber may remain in noncaptive mode before the Shasta 5000 BSN must recapture the subscriber (for example, Session Timeout: 60 minutes) A list of ip-addresses (in the form of an ip-farm) specified with multiple requests handled in round robin fashion among all servers in the list
214659-B
109
Content filtering
The growth and openess of the Internet and the growth in broadband access have made available to end users a wide diversity of content. This content availability imposes on businesses, educational institutions, and residential users the need to restrict access to content deemed inappropriate for their environment or offensive to their user base for the following reasons: Businesses are faced with the challenge of limiting content that is objectionable within the workplace. For businesses, enterprises, and small offices and home offices (SOHOs), restricting access to content can also enhance the productivity of workers. Parents must control content that is inappropriate for children. Public schools and libraries are faced with the need to somehow monitor students use of the Internet for acceptable purposes.
Content filtering tools address all of these requirements. They provide the ability to selectively restrict access to content depending on the requirements of the environment. The Shasta 5000 BSN content filtering service, which interoperates with a content-filtering server, can be used to serve business enterprises, educational institutions, and residential users. The Shasta 5000 BSN leverages its Web steering ability to direct content filtering subscribers to the content-filtering server. Note: Use of the Web steering service for content filtering allows for redirection of HTTP requests (traffic using port-80) only. Use of policy-based forwarding allows for support of content filtering with other protocols. Content filtering can be centrally deployed and provisioned through the Shasta 5000 BSN at the service provider premises. The service provider can offer content filtering as a value-added service, bundled with broadband access, or as part of a bronze, silver, or gold service offering that includes other high-touch services. A network-based approach to content filtering benefits the service provider in the following ways. It enables the service provider to: Create service profiles and apply those profiles across groups of subscribers.
110
Ensure that software is upgraded and that databases are updated and downloaded regularly.
Because the service provider, not the content filtering vendor, provides all the interfaces to the content filtering service, a network-based approach to content filtering also benefits the user by offering an interface consistent with other services offered by the service provider.
Offering content filtering as a value-added service

Content filtering services are usually available in basic, advanced, or custom filtering models. Service providers who wish to offer content filtering as a value-added service can take advantage of these models, which are described as follows: BasicThis offering may include strictly the filtering of Web traffic based on predetermined settings. This model is most appropriate for the residential user. AdvancedThis offering may include alerts (indicating when individuals have attempted to view disallowed content), time of day limits, or other features more appropriate for business environments. CustomThis offering may require that the service provider customize several different settings and service options for the business customer.
Additionally, a service provider may bundle any of these content filtering service options with other Shasta 5000 BSN high-touch services to create bronze, silver, or gold service offerings.
Creating categories and customizing content-filtering offerings

To provide content filtering with the Shasta 5000 BSN and the interoperative content filtering server, the service provider defines default filters for all subscribers, groups of subscribers, and other categories of subscribers, as needed. The service provider also configures who among the users has the power to change the filters used.
214659-B
111
To provide content filtering, the service provider should customize the kind of content to be filtered based on the subscribers requirements and general standards for those requirements. Content filtering vendors have predefined categories, or profiles, such as Intolerance, Crime, Drugs, and so on, which filter both the content of Web sites and the context in which words are used. To determine appropriate filtering within each service offered, in defining categories, service providers might find it helpful to seek the support of the content filtering vendor or that of third-party consultants. The following kinds of content filtering products are offered to subscribers: G-rated serviceThis service blocks the categories of Crime, Drugs, Intolerance, Sex, Personals, and Nudity. PG-rated serviceThis service blocks the categories of Intolerance, Sex, Personals, and Nudity. Productivity serviceThis service blocks the categories of Job Search, Sex, Games, Sports, Gambling, Interactive (chat), Personals, and Nudity. Nonrated serviceFor this category, no content filtering is necessary.
Each ratingfor instance, G, PG, or Productivitycan be established either on the same content filtering server or on separate servers that reside within the service provider premises. Each content filtering server must be identified with an IP address. When servers are established for the content filtering ratings, the Shasta 5000 BSN Web steering policy can be configured to direct subscribers to the appropriate server. If several servers are provisioned for content filtering, the Web steering function will perform a level of load balancing to ensure that the given server is available. The Web steering function is designed to loadshare HTTP traffic across multiple servers. Note: Policy-based forwarding does not allow for load balancing to servers; therefore it is not recommended for content filtering. For details about the Shasta 5000 BSN Web steering feature, see Web steering on page 113.
112
Authenticating subscribers
The processes for authenticating subscribers and directing them to their content filtering service differ for those subscribers accessing the Shasta 5000 BSN across PPP and PPPoE and those subscribers coming in across 1483 Bridged or 1483 Routed connections. The following process might occur for subscribers using PPP or PPPoE: 1 2 The subscriber is authenticated through RADIUS, and the RADIUS handshake completes. The Shasta 5000 BSN steers the subscriber to his or her content filtering service on the appropriate server. On the subscribers first access, the server sends back to the subscriber a Web page with a login and password entry box, prompting for the subscribers user name and password. The subscriber submits login information. The content filtering server creates a RADIUS authentication packet and sends it to the RADIUS server. The RADIUS server responds with an ACK or a NACK. The content filtering server searches its local configuration file for the subscribers content filtering settings.
3 4 5 6
Subscribers using 1483 Bridged or 1483 Routed who do not use RADIUS for authentication could be set up to utilize the content filtering vendors Web page for content filtering authentication (and thus the profile established for them for their session). Alternatively, these subscribers could be set up to use a service provider interface; for instance, one implemented through use of the Shasta 5000 BSN Personal Content Portal feature. (See Personal Content Portals on page 103.) For those using the content filtering server Web page authentication mechanism, the subscriber is sent a cookie to maintain session control. Within a residential environment in which several family members require different filtering mechanisms, IP-DEMUX is required to distinguish between family members. As with any IP-DEMUX implementation, subscribers can be either static (preconfigured) subscribers with their own IP addresses and list of services or they can be automatically created based on a templated set of services.
214659-B
113
Filter service
A RADIUS server accessed by a Shasta 5000 BSN may implement a filter service (RADIUS attribute 242). In such cases, when a subscriber successfully logs in to an ISP service on the Shasta 5000 BSN, the Shasta 5000 BSN downloads a filter file for that subscriber. The filter specifies restrictions and capabilities for the user. For example: Pass all ingress packets Pass all egress packets
Or the filter may specify that some types of packets are to be dropped: Drop all incoming ICMP packets Note:
The BSN does not support binary filters for the RADIUS filter service. The RADIUS filter service may not work with the Captive Portal feature. If the SSM fails, the RADIUS filter definition feature is not saved. The BSN would not reapply the filter serves to the subscribers next call. Therefore this feature is not yet carrier grade.
Web steering
The Shasta 5000 BSN Web steering feature, described in Web steering on page 71, is the mechanism that is used in content filtering to steer traffic to the content filtering server. Just as Personal Content Portals are possible because of Web steering, so, too, is content filtering. Content filtering is possible because the Shasta 5000 BSN Web steering policy enables port-80 HTTP-targeted traffic to be redirected to a proxy server at port 80 without the knowledge of the Web client.
114
The service provider can offer subscribers a content filtering service and establish a rule to steer traffic to a server dedicated to that service. The IP-farm object referenced by the Web steering process contains the list of IP addresses that refer to the content filtering proxy servers. Each HTTP connection that matches the rule is redirected to one of the servers listed in the corresponding IP-farm object. For example, G-rated Web steering would be directed to the server on the service provider premises that handles G-rated content. The Web steering policy has the standard rule-based format. Rules can be added specifying which IP conversations (specified by source and destination address) should be steered, and which should not be steered. Rules that specify a steer action must also specify an IP-farm object. For the purposes of the Web steering service, the contents of the referenced IP-farm object should be a list of IP addresses that refer to proxy cache servers. Note that an IP-farm object can list up to 255 IP addresses. Each HTTP connection that matches a steer rule will be redirected to one of the servers listed in the corresponding IP-farm object. A hashing function is performed on the three most significant octets of the origin servers IP address in order to choose the proxy server in the IP farm.Consequently, requests to the same origin server will always be redirected to the same proxy server, regardless of the source of the request. The hashing function takes the three most significant octets from the IP address, adds them up, and, based on the eight least significant bits, chooses the cache server to redirect the traffic to. Many Web sites load-balance incoming requests to a farm of Web servers, and, frequently, this farm is on the same class C subnet, for example, nslookup on popular sites such as yahoo.com, cnn.com, and altavista.com. By not including the least significant octet in the hash function, requests to any of these replicated servers will be redirected to the same proxy cache server, thus maximizing the hit ratio, as illustrated in Figure 15.
214659-B
Chapter 5 Content technologies Figure 15 Web steering service hashing function
115
Send Packet Back to the User
Substitute Source IP Address on the Packet by origin Server IP Address Shasta Substitute Destination IP Address on the Packet by Cache IP Address
Return Page
Send Packet to Cache Device
Is Web page Cached?
Hashing Function Chooses which Cache to send the Traffic
No HTTP Request Is HTTP Traffic? Internet
User
10149EA
Proxy server high availability (failure handling)

The Shasta 5000 BSN performs periodic health checks on all members of every IP farm in use by instantiated Web steering services. When a health check fails, the IP address of the failing IP farm server is removed from the hash table in all referenced nodes so that no new HTTP requests will be redirected to it. Additionally, the remaining IP farm members that are active are configured to take over the hash entries formerly associated with the failed server. This takeover occurs only if the active IP farm members do not exceed the allowed maximum number of hash entries that any given IP farm member can take over. Hash entries that do not have an associated proxy server for redirection because of excessive proxy server failures are forwarded directly to the origin server.
116
When the proxy server comes back up, its information is restored in each hash table in the same place where it existed previously. Requests previously hashed to the reinstated server are once again redirected to it. This approach tolerates short-lived outages well because cache saved in secondary storage persists across outages. Currently, ICMP pings are the only type of health check supported. Ping health checks are performed every 15 seconds by default for every member of each IP farm in use. Three consecutive failures cause an IP farm member server to be transitioned to a down state. For a server to be brought back up, two consecutive successful ping health checks must occur.
Adding or removing IP farm members

You use the SCS to add members to or remove them from an IP-farm object. This activity changes the corresponding hash table. Adding a new member causes some number of hash entries to be taken away from each previously existing member in order to populate some hash entries with the new member. Similarly, deleting a member causes its hash entries to be evenly redistributed among all remaining members. If an addition and a deletion are performed in the same update, the new member will take over all of the deleted members hash entries leaving other members hash entries unchanged.
IP farm sizing
Currently, the Shasta 5000 BSN does not attempt to determine when proxy cache servers are overloaded. Therefore, it is imperative that you create an IP farm of the proper size to handle the anticipated peak load. You should build excess capacity into the IP farm to handle some possible proxy server failures. Consider an IP farm that contains 20 proxy servers. Each proxy server will receive one twentieth of the HTTP redirections. However, if four of the proxy servers become unreachable, then each remaining proxy server will receive one sixteenth of the HTTP redirections.
214659-B
117
IP farms are configured with a limit on the number of hash entries that can be reassigned to each member when other members fail. This percentage defaults to one fourth over the initial assignment (that is, one fourth more than an IP farm member has assigned to it when all members are reachable). Therefore, in the preceding example given, one sixteenth of the hash table equaled the limit that could be assigned to each IP farm member at any given time: (5/4) * (1/20). Note: This value changes when members are added to or removed from an IP farm. To show all IP farms in use, use the following command:
show ipfarm
To show the number of hits in each hash bucket (which shows how evenly the hash algorithm distributes the load), use the following command:
show stats ipfarm [farm=]farmname [node=node]
To change the limit of the percentage of hash entries that any given IP farm member can be assigned above its fair share, use the following command:
set ipfarm [farm=]farmname limit
This value determines how many hash buckets can be reassigned to other IP farm members when a subset of IP farm members fails. An IP farm members fair share is precisely 1/nth of the number of hash buckets given n members of the IP farm. The input for this command is a percent value. A percentage value of 0 should be chosen if IP farm members should never go over their fair share. A value of 33, the default value, indicates members can go up to 33 percent over their fair share in the event other members fail. A value of 100 indicates that a member can double its fair share in the face of failures. The following command is for viewing the configuration of the IP health checker:
show iphc
118
The following command is for setting the configuration of the IP health checker:
set iphc ping [failcnt=failcnt] [successcnt=succnt]
The following command is for viewing the health-checker details for any specific IP address:
show iphc ipaddr [ipaddr| netmask=netmask] [[isp=]vrid]
A netmask of 255.255.255.255 will show the statistics for all IP addresses currently registered with the IP health checker. If a vrid value is not supplied, a wildcard is assumed.
214659-B
119
Chapter 6 DSL aggregation

This chapter explores deployment of the Shasta 5000 Broadband Service Node for Digital Subscriber Line (DSL) aggregation. DSL aggregation is the process of combining subscriber traffic from many sourcesfor instance, from many DSLAMsand providing value-added services to the subscriber traffic. This chapter includes the following sections: About DSL, next About PPP on page 120 PPPoA for direct host (PC) connection on page 121 DSL PPP sessions and L2TP on page 122 Bridging on page 125
About DSL
DSL delivers high bandwidth connectivity to mass-market users across existing copper loop technology at affordable cost. Within a DSL deployment, the provider offering the basic DSL connectivity (perhaps an ILEC or a CLEC) and the service provider (such as an ISP) controlling the subscribers and the Shasta 5000 BSN are two different entities. This separation allows ISPs to peer with multiple DSL connectivity providers across a given metropolitan area. ILECs or CLECs can offer DSL connectivity services to multiple ISPs.
120
Access methods (or encapsulations) from the subscribers Customer Premises Equipment (CPE) to the Shasta 5000 BSN across the DSL link include the following: Point-to-Point Protocol over Ethernet (PPPoE) PPPoE is used for multiple hosts connecting to a single DSL line. See PPPoE on page 80 for an overview of PPPoE. Point-to-Point Protocol over AAL5 (PPPoA) PPPoA is used for direct host connectivity using ADSL. See PPPoA on page 82 for an overview of the PPPoA. RFC 1483 Bridged (or RFC 1490 Bridged) Multiple hosts connecting to a single DSL line use PPPoE and RFC 1483 Bridged for ATM connections and PPPoE and RFC 1490 Bridged for frame relay connections. See 1483 Bridged (1490 Bridged) on page 76 for an overview. RFC 1483 Routed (or RFC 1490 Routed) See 1483 Routed (1490 Routed) on page 75 for an overview. RFC 1483 Routed is used for routed CPE over ATM connections and 1490 Routed is used for routed CPE over frame relay connections. The uplink from the Shasta 5000 BSN into the ISP core may be ATM, FastEthernet, PPP over SONET, Gigabit Ethernet, or frame relay. Trunk connections from the Shasta 5000 BSN into the ISP core are typically RFC 1483 Routed (or RFC 1490 Routed), except if tunneling is used, in which case PPP within layer 2 Tunneling Protocol (L2TP) is used.
About PPP
PPP, which is implemented at layer 2, provides a standard method for transporting multiprotocol datagrams over a link connecting two points. PPP consists of three main parts: an encapsulation method, a Link Control Protocol (LCP), and various Network Control Protocols (NCPs) used to establish and configure layer 3 protocols. If multiple protocols are used on the same link, each protocol requires appropriate NCP support. The Shasta 5000 BSN supports IP at layer 3 and Internet Protocol Configuration Protocol, (IPCP) which is the NCP for IP. For additional information about PPP, see PPP on page 77.
214659-B
121
PPPoA for direct host (PC) connection

Direct host connectivity using PPP over AAL5 (PPPoA) comprises the largest use of DSL access technology today. It gives residential users access to ISP backbones and corporate backbones. Residential subscribers are provided ADSL services delivered primarily by ILECs and CLECs. For residential subscribers, the simplest scenario consists of a host connecting to the ADSL loop via an integrated network interface card (NIC), a plug-in card, or an external modem. Modems used in this capacity implement PPPoA, as defined in RFC-2364. (For a description of PPPoA, see PPPoA on page 82.) Direct host configuration permits the subscriber to emulate the Internet dial model. It also allows the existing RADIUS server to be used for authentication and auto-configuration. Figure 16 shows a DSL direct host configuration scenario using a NIC, not an external modem. In this figure, packets are sent from the users PC across the ADSL line encapsulated in PPPoA and an IP header. The DSL Access Multiplexor (DSLAM) sends the packets, within the same encapsulation, across the OC-3 line to the Shasta 5000 BSN. The PPPoA session is terminated on the Shasta 5000 BSN, and the subscriber data is sent over IP to the ISPs core. The RADIUS server shown in Figure 16 performs the authentication.
Figure 16 Single, direct host connectivity using PPPoA
PSTN Gateway ISP Core Cable Modem CMTS Headend
RADIUS Server Portal Server
IP PPP PPPoE 100BASE-T
IP 1483R ATM AAL5 DOCSIS
IP PPP PPPoE 100BASE-T
IP 100BASE-T
Subscriber PPP Within PPPoE
ISP Routing
10069EA
122
The line from the DSLAM to the Shasta 5000 BSN could be any of the following: OC-3, OC-11, SONET, ATM, FR, T1, or T3. This process works as described in the following steps: 1 The subscriber initiates a PPP session via the dial-up client (for instance, the MS Windows or Macintosh dial-up client) on his or her home system. This process begins the Link Control Protocol (LCP) phase of PPP negotiation. The user ID and password data entered during this phase are authenticated by the RADIUS server that supports the Shasta 5000 BSN the subscriber is connected to. 2 The RADUIS server accepts or rejects the login information, or it may issue a challenge. If the login information is accepted, the process enters the next phase, the IPCP phase. This phase encompasses optional address assignment. Subscriber IP addressing is either dynamic or assigned by the ISP. If the subscriber forwards an address of 0.0.0.0 during IPCP, the Shasta 5000 BSN dynamically assigns an IP address from a local or RADIUS pool. Alternatively, the ISP may assign an address to the subscriber before the subscriber begins this connection process, and that IP address is used.
DSL PPP sessions and L2TP

The Shasta 5000 BSN can aggregate many DSL subscribers and terminate them. If a number of these subscriber sessions are destined for the same ISP or corporate enterprise, it is more efficient to tunnel them collectively to that destination than to route each one separately. (A tunnel provides a method of carrying layer 2 connections over other mediums, commonly multiplexing multiple layer 2 connections over a single path. A tunnel consists of a control connection plus zero or more sessions.) layer 2 Tunneling Protocol (L2TP), which consists of a tunnel plus sessions in the tunnel, is often used for this purpose. Because it offers security, L2TP is commonly used to provide telecommuters secure access to a corporate Intranet. It is also used to provide secure connections between a
214659-B
123
subscribers access point and the ISP device. The subscribers DSL PPP sessions coming into the Shasta 5000 BSN on the access side are encapsulated with an L2TP header and tunneled to their destination ISP or corporate enterprise network in L2TP tunnels on the trunk side. The Shasta 5000 BSN that encapsulates the PPP session in the L2TP tunnel is acting as an L2TP Access Concentrator (LAC). In a DSL deployment, L2TP tunnels are usually created between an aggregator functioning as an LAC and an ISP or corporate router performing an L2TP Network Server (LNS) function. The LAC establishes the tunnel to the LNS at the destination ISP or corporate enterprise. An L2TP session is created when an end-to-end PPP session is established between a user (PC) and an LNS. A user wanting to establish an L2TP tunnel first initiates a PPP session and establishes a PPP link to the LAC. The Shasta 5000 BSN acting as the LAC uses the users fully qualified domain name to query an AAA server as to the proper L2TP tunnel to use. Instead of terminating the session and routing into the ISP backbone, the Shasta 5000 BSN encapsulates the PPP session within the L2TP tunnel for transport to the destination LNS. (This tunnel is considered a compulsory tunnel.) If PPPoE is used to connect to the Shasta 5000 BSN, it is terminated at the Shasta 5000 BSN and the PPP session is carried in the L2TP tunnel, end to end. After traversing the core network, the users data arrives at the ISPs or enterprises LNS. This device terminates the PPP session and the L2TP tunnel, passing the traffic to the providers core or the corporations Intranet. Depending on the size of the enterprise or ISP, the LNS may be located on site at the corporate enterprise or service provider, or it may be outsourced at the networks edge. Both architectures achieve the same goal. Final authentication takes place at the destination AAA server, and the user is assigned an IP address via DHCP. A single deployment for an ISP might include multiple Shasta 5000 BSNs acting as LACs or LNSs. In a scenario such as this, multiple L2TP tunnels originating at one LAC carry subscriber sessions to any number of different LNSs, as shown in Figure 17.
124
Chapter 6 DSL aggregation Figure 17 L2TP tunnels between multiple LACs and LNSs
L2TP Tunnel
LAC-1
LNS-1
LAC-2
LAC-3
LNS-2
10147EA
In another common DSL scenario that uses L2TP, DSL users dial into a network and they are aggregated at a DSLAM, then blindly tunneled across L2TP to a Shasta 5000 BSN at the edge of the ISP or corporate network. In this case, the L2TP tunnel carries the PPP sessions to the Shasta 5000 BSN acting as the LNS at the ISP or corporate network edge. The Shasta 5000 BSN LNS at the ISP or corporate network edge terminates the PPP session, then sends it onto the Internet or corporate Intranet. Another deployment model that uses L2TP tunneling for DSL subscribers is entirely wholesaler based. For instance, a wholesaler could install a Shasta 5000 BSN in one of its POPs to perform tunnel consolidation. For this scenario, the CVX 1800 would initiate L2TP tunnels to the Shasta 5000 BSN. The Shasta 5000 BSN would consolidate tunnels from multiple RASs and provide the ISP or corporate enterprise with a single tunnel across the backbone. To accomplish this, the Shasta 5000 BSN acts as both an LNS and a LAC. Behaving as an LNS, the Shasta 5000 BSN terminates the L2TP tunnels from the RASs. Behaving as a LAC, it then consolidates multiple sessions going to the same ISP or corporate enterprise and initiates a new L2TP tunnel to the ISP or corporate enterprise. Now, instead of hundreds of tunnels, the ISP or corporate enterprise need manage only several tunnels.
214659-B
125
Bridging
If many hosts such as PCs connected to a local area network (LAN) must connect to a single ADSL line, an external ADSL modem is required and bridging is used. This is the case for broadcast networks, such as Ethernet (and sometimes USB), and most of the ADSL modems used for these configurations are bridge devices. For scenarios such as these, PPPoE is used to extend the PPP session across the subscribers Ethernet segment. This process allows emulation of the Internet dial model, with its Authentication, Authorization, and Accounting (AAA) and dynamic destination capabilities. However common bridging problems expose the network and the subscriber host to security breaches. This section describes bridging and explains how the Shasta 5000 BSN addresses the two main problems inherent to bridginghow to handle security and how to efficiently use IP addresses. This section includes the following sections: Problems inherent to bridging, next Subscriber bridging on page 127 Bridge groups on page 127 The Shasta 5000 BSN and half bridging on page 128 Configuration of Independent bridged subnet on page 130 Configuration of half bridging with static IP addressing on page 131 Configuration of bridged PPPoE subscribers on page 132
Problems inherent to bridging

Bridging typically exposes users to privacy and security problems. This is especially true when the traditional configuration using a layer 2 bridge and a layer 3 router is used, as shown in Figure 18. In this topology, all subscriber hosts and the router used to access the Internet are linked into the same IP subnet domain through a layer 2 bridge. All subscriber traffic to and from the Internet uses the router as the default gateway. The main problem inherent in this configuration is that because all subscribers are connected through a layer 2 bridge, they are capable of receiving one anothers broadcast and multicast traffic. Thus, privacy and security cannot be assured.
126
Chapter 6 DSL aggregation Figure 18 Subscriber network with bridge and router
Subscriber Subscriber Subscriber
Internet Router
Bridge
Subscriber
Subscriber
Subscriber
10033EA
One way to solve the security and privacy problems of bridging is to put each subscriber on its own subnet. A configuration that puts each subscriber on its own subnet requires that subscribers communicate with one another or interact with the Internet through the layer 3 router. In this case, all packet filtering, packet blocking, and packet forwarding decisions would be made or configured at layer 3 of the router, affording greater data privacy. However, this solution introduces another problem: overuse of IP addresses. To support the maximum number of subscribers, this configuration requires the maximum number of subnets per address space. In this case, a 30-bit subnet mask is required, leaving 2 bits for host specifications. These 2 bits give four IP addresses per subnet: one for the router interface, one for the subscriber host, one for the network address (for example, 00), and one for the network broadcast address, (for example, 11). For every four IP addresses, only one is actually used by the subscriber. Although this scenario provides for improved security and privacy, it is highly wasteful of IP addresses, which are a scarce resource. Thus, it does not provide an ideal solution. When an RFC 1483 Bridged implementation is used, the problems intrinsic to layer 2 bridging ensue. All subscriber virtual circuits (VCs) aggregate onto a single interface and share the same subnet domain. This common environment allows for no data privacy and opens the system to security breaches. The Shasta 5000 BSN is especially vulnerable to spoofing and hijacking because of its need to handle the cross traffic through ARP broadcasts and MAC address learning.
214659-B
127
Thus, RFC 1483 Bridged alone does not satisfy privacy and security requirements for broadband access. To provide a solution that allows for use of RFC 1483 Bridged, the Shasta 5000 BSN implements subscriber bridging and bridge groups, as described in the following sections.
Subscriber bridging
Subscriber bridging is a technique that allows the router-aggregator to perform the traditional layer 2 functionality at layer 3, giving the administrator the ability to selectively configure filters among all subscriber VCs, providing some degree of privacy. Subscriber bridging improves scalability and privacy, but it is still vulnerable to Medium Access Control (MAC) spoofing and Address Resolution Protocol (ARP) hijacking.
Bridge groups
The bridge group offers another technique that is closely related to subscriber bridging. For this technology, groups of users are segmented into different bridge groups. Each group is a separate layer 3 entity with an individual IP subnet. Using bridge groups, the service provider can segment groups of users based on policy. All traffic from one bridge group to the other is through layer 3 routing. This technology is implemented in the Shasta 5000 BSN and made available through the Independent Bridged Subnet bridging parameter. For bridge groups, all traffic from one bridge group to another is sent through layer 3 routing. Figure 19 shows two bridge groups, each on its own IP subnet and with its own DSL modem bridge.
128
Chapter 6 DSL aggregation Figure 19 Bridge groups and the Shasta 5000 BSN
Subscriber
DSL Modem-Bridge VC1 Subnet-1/30 DSL Modem-Bridge VC1 Subnet-2/28
Internet
Shasta 5000 BSN (Aggregator)

10070EA
The Shasta 5000 BSN and half bridging

The Shasta 5000 BSN implements a workable solution to the problems of IP addressing and breaches to security intrinsic to bridging by providing a feature called half bridging. Half bridging uses subscriber bridging and bridge groups. Half bridging changes the way the aggregator processes subscriber packets. For half bridging, the Shasta 5000 BSN performs the Proxy-ARP agent function at layer 3. It does not rely on Address Resolution Protocol (ARP) to determine which packets to send over which VCs. Instead of passing the packets to the layer 2 process within the router, half bridging allows the service provider to determine and control at layer 3 the direction of packets to specific VCs. (For bridging, packets are usually passed to layer 2, giving no control to the administrator.) The Shasta 5000 BSN responds directly with its own hardware address to all ARP requests coming across VCs. However, it does not respond to ARPs destined for a local host as it has learned the locality of all subscriber nodes in each VC segment. If a subscriber were to spoof the MAC address, it would be irrelevant because all decisions at the aggregator are made at the IP layer.
214659-B
129
For half bridging, each subscriber is treated as an individual layer 3 object by the Shasta 5000 BSN in terms of address assignment and security. All subscriber traffic is routed through the Shasta 5000 BSN as the default gateway for the subnet. Consequently, from the subscriber perspective, the Shasta 5000 BSN implements only bridginghence the name half bridging. To deploy half bridging, you use the Shasta 5000 BSN Service Creation Systems (SCSs) Member of Bridge Group bridging parameter. Half bridging works on the Shasta 5000 BSN in the following way: To obtain control over the direction of packets, the Shasta 5000 BSN performs the Proxy-ARP agent function at layer 3. The Shasta 5000 BSN does not respond to any ARP targeting a local host. The Shasta 5000 BSN treats each subscriber as an individual layer 3 object in regard to address assignment and security. All subscriber traffic routes through the Shasta 5000 BSN as the default gateway for the subnet, and the subscriber perceives this as bridging.
Figure 20 illustrates half bridging.

Figure 20 Half bridging and the BSN
Subscriber
Subscriber
DSL Modem-Bridge Internet DSL Modem-Bridge Shasta 5000 BSN (Aggregator) Subscriber Subnet-A
DSL Modem-Bridge
10102EA
130
Configuration of Independent bridged subnet

This section gives an overview of the configuration tasks required for a simple scenario that establishes 1483 Bridged connections from the subscriber to the Shasta 5000 BSN. In this deployment, virtual circuits (VCs) connect the Shasta 5000 BSN to the subscriber location. Each VC connection represents an IP subnet owned by the subscriber. Each subnet can have a unique subnet mask. Each subscriber premise can have as many subscriber hosts, compatible to the local subnet, as its IP address space allows. At the Shasta 5000 BSN, no preconfiguration of IP addresses is required. Figure 21 shows this scenario.
Figure 21 Independent bridged subnet
Subscriber 14.1.1.46/30 20.1.1.15/24 14.1.1.45/30 Shasta 5000 BSN 20.1.1.16/24 1483/R Internet Router 10.1.1.41/24 10.1.1.12/24 14.1.1.20/28 DSL ModemBridge Subscriber Subscriber Subscriber 14.1.1.21/28 14.1.1.22/28 14.1.1.46/30 VC1 0/101 VC1 0/102 1483/B
DSL Modem-Bridge
SPM Server
10146EA
214659-B
131
To configure this scenario for DSL access using 1483 Bridged connections: 1 Create the 1483 Bridged connections for DSL access. (Repeat this step for each required 1483 Bridged connection.) The Connection Type is Access and the Encapsulation Type is 1483-LLC-B. Ensure that the VPI/VCI settings (0/101) match those in the ATM device at the other end of the connection. (VPI/VCI settings between two endpoints must be matched in the subscriber provisioning system.) Note: You perform these functions via the Service Creation System (SCS). You must be logged in as device-owner with an ISP profile. 2 Create the subscriber interface bridged subnets for each subscriber line (VC).(Repeat this step for each required 1483 Bridged connection.) When you configure the connection using SCS, select the Dedicated Connection button in the Access Method Binding selection box. On the Addressing tab, select the Independent Bridged Subnet button.
Configuration of half bridging with static IP addressing

This section gives an overview of how to configure the Shasta 5000 BSN for half bridging with static IP addressing. In this deployment scenario, all subscriber hosts on the access side reside on the same subnet. All subscriber traffic routes through the Shasta 5000 BSN as the default gateway for the subnet. To configure half bridging on the Shasta 5000 BSN using SCS, you use the Member of the Bridge Group parameter, which implements the half bridging technique.
132
To configure this scenario for DSL access using 1483 Bridged and half bridging with static IP addressing: 1 Create 1483 Bridged connections for DSL access. (Repeat these steps for additional connections.) The Connection Type is Access and the Encapsulation Type is 1483-LLC-B. Ensure that the VPI/VCI settings (0/101) match those in the ATM device at the other end of the connection. (VPI/VCI settings between two endpoints must be matched in the subscriber provisioning system.) Note: You perform these functions via the Service Creation System (SCS). You must be logged in as device-owner with an ISP profile. 2 3 Create a bridge group. Create subscribers and bridged addresses.
Configuration of bridged PPPoE subscribers

PPPoE provides the ability to connect many subscriber hosts over 1483 Bridged to a remote access aggregator, such as the Shasta 5000 BSN. Each subscriber host has its own PPP session, allowing for billing, access control and type of service to be handled per subscriber. In a deployment scenario that uses PPPoE Bridged DSL access, subscribers are not bound to a particular VC connection. Therefore, they can access the Shasta 5000 BSN through any PPPoE tunnel, provided that the tunnel can validate with a user group that the subscriber belongs to. This DSL access deployment scenario requires PPPoE support at both the Shasta 5000 BSN and the subscriber host (through installation of a PPPoE client shim). To configure this scenario for DSL access using PPPoE and 1483 Bridged: 1 Create 1483 Bridged connections for DSL access. Note: You perform these functions via the Service Creation System (SCS). You must be logged in as device-owner with an ISP profile.
214659-B
133
2 3 4 5 6
Create a connection template. Create PPPoE tunnels, and select the connection template created in the previous task. Create an access group. Create an address pool, and select the access group created in the previous task. Create subscribers who will use the PPPoE tunnels.
134
214659-B
135
Chapter 7 Virtual Private Networks

This chapter describes the Virtual Private Networks (VPNs) supported by the Shasta 5000 BSN. VPNs give service providers the ability to offer network-based solutions that integrate multiple fixed sites, xDSL connected (or cable) telecommuters, and dial-in telecommuters. This chapter elaborates on the introduction to VPNs given in Chapter 2, BSN: overview and features, on page 31. Then it describes the three types of VPNsVirtual Private Routed Networks (VPRNs), MPLS and VRF-VPNs, and Virtual Leased Lines (VLLs)supported by the Shasta 5000 Broadband Service Node and gives example scenarios of each. Next, the chapter explains use of the Contivity CES platform that offers Virtual Private Dial Network (VPDN) capability to enterprises in conjunction with VPRNs and VLLs to provide a complete VPN solution. Finally, the chapter explains Virtual Private Access Networks supported by the Shasta 5000 BSN, which allow remote access users to dynamically connect to an enterprise network. Although they rely on IPsec, VLLs do not include automatic key exchange or topology discovery. The chapter includes the following sections: VPNs supported by the Shasta 5000 BSN on page 136 Virtual Private Routed Networks on page 136 MPLS and VRF-VPNs on page 154 Virtual Leased Lines on page 159 Contivity CES Server Farm on page 161 Virtual Private Data Networks on page 163
136
VPNs supported by the Shasta 5000 BSN

A VPN connects the components and resources of one network over another network. To do so, VPNs allow the user to tunnel through the Internet, or another public network, while maintaining secure communications. The Shasta 5000 BSN implements VPNs at layer 3. It implements per-VPN forwarding tables (virtual routers) to support private and overlapping addressing. It supports IPsec for secure network connections offering end-to-end tunnels independent of any interior topology or networking topology. Interoperability with third-party Competitive Local Exchange Carrier-based (CLEC) IPsec devices is also supported. This use of the Shasta 5000 BSN enables the service provider to offer a complete outsourced networking solution including VPN and Internet access over a single network. The Shasta 5000 BSN supports three types of VPNs: Virtual Private Routed Networks (VPRNs), MPLS VRF-VPNS, and Virtual Leased Lines (VLLs). The Shasta 5000 BSN enables service providers to deliver IP VPNs with or without secure Internet access to small and medium businesses as well as to remote sites and telecommuters of larger corporations. Because they are decoupled from the underlying link-layer technology, Shasta 5000 BSN VPNs offer universal connectivity based on the Internet Protocol (IP). One of the many benefits of VPNs supported by the Shasta 5000 BSN is that initial deployment is not dependent on new core networking technologies. Rather, Shasta 5000 BSNs complement existing access and backbone networks. For additional information introducing VPNs, see Virtual Private Networks on page 50.
Virtual Private Routed Networks

This section gives an overview of VPRNs, explaining intelligent meshed VPRNs and differentiated services. It also explains the factors contributing to VPRN scalability. You must take into account these factors in determining how to deploy and configure your Shasta 5000 BSNs to support the maximum number of VPRNs you require.
214659-B
137
This section includes two scenarios addressing the two types of VPRNs the Shasta 5000 BSN supports. One scenario describes a VPRN in which the enterprise obtains Internet access from a different service provider than the one supplying the VPRN; the other scenario describes a VPRN in which the enterprise obtains Internet access from the same service provider as the one providing the VPRN. This section includes the following topics: About Virtual Private Routed Networks on page 137 Virtual Private Routed Networks without Internet access on page 150 Virtual Private Routed Networks with Internet access on page 151
About Virtual Private Routed Networks

A VPRN emulates a multisited routed network appearing as an IP cloud to edge devices. It provides an enterprise with a private IP network backbone that is network managed and restricted to IP traffic. Use of a routing protocol across the network edge is optional. IPsec tunnels are used for VPRN trunks. Thus, VPRNs supported by the Shasta 5000 BSN are optimized for enterprises requiring secure connectivity as well as high-touch services. The enterprise customer outsources its routed network backbone to the service provider. To the enterprise customer, the outsourced VPRN is opaque; the enterprise has no visibility into it, nor need they be concerned about it. The carried traffic is opaque. Traffic carried within a VPRN (or VLL) may have no relation to the traffic carried on the IP backbone. The customers IP network may use addressing that is unrelated to that of the IP backbone on which the traffic is transported. Outsourcing the routed network backbone is possible because VPRNs supported by the Shasta 5000 BSN are network based rather than requiring and relying on equipment at the customer premises (CPE). By contrast, Figure 22 shows a CPE-based VPN in which the enterprise customer owns and manages the infrastructure. In this configuration, all responsibility for infrastructure and network management falls on the corporate enterprise.
138
Chapter 7 Virtual Private Networks Figure 22 CPE-based VPN

Branch Office
Branch Office
Branch Office
PVC/IP Tunnel
Headquarters
10108EA
VPRNs replace costly leased lines and full mesh frame relay networks. In addition to eliminating the need for the enterprise customer to own infrastructure, network-based VPRNs remove from the customer the responsibility for establishing and maintaining tunnels and permanent virtual circuits (PVCs). Instead, the service provider owns the equipment and manages the network. The customer benefits from network-based VPNs through reduced equipment cost and management overhead while still gaining the same delivery services and privacy and security features offered by a CPE-based network. All that a service provider must do to set up a VPRN on the Shasta 5000 BSN is define the VPRN and assign members to it. Figure 23 shows a network-based VPRN.
214659-B
Chapter 7 Virtual Private Networks Figure 23 Network-based VPRN

Branch Office
139
Branch Offices
Branch Offices Shasta 5000 BSN Shasta 5000 BSN
Shasta 5000 BSN
IP Tunnel
Headquarters
10109EA
Beginning with Release 2.0 of the Shasta 5000 BSN, any type of subscriber can become a member of a VPRN. That is, any Customer Premises Equipment (CPE) that can be configured as a subscriber through the Service Creation System (SCS) interface can be bound to a VPRN. Possible subscribers include the following types: 1483B, 1483R, PPP, PPPoE, GRE, IPsec, IP/HDLC, PPP/HDLC, CISCO/ HDLC, 1490R-FR, PPP/FR, Ethernet, and IPDemux. The Shasta 5000 BSN implements the use of per-VPRN forwarding tables, or virtual routers, to support private and overlapping addressing. These Forwarding Information Blocks (FIBs) allow for communication to occur within a VPRN. A VPRN is capable of determining customer IP addresses reachable over the access link via static configuration or activation of a dynamic protocol including Open Shortest Path First (OSPF) and Routing Information Protocol (RIP). This information is disseminated within the network core via a per-VPRN routing instance.
140
VPRN plus Internet support is possible because the VPRN shares its FIB with the ISPs routing table. A VPRN without Internet support does not share its FIB with an ISP.
DiffServ marking and VPRNs

The Type of Service/Differentiated Service (ToS/DS) byte is a field in the IP header that is set to mark traffic so as to distinguish different traffic types (such as, ftp, smtp, and H.323) from one another. The ToS bit settings allow you, as a service provider, to offer different classes of service at different price points to customers. Network core routers interpret the ToS bits to determine which traffic gets preferential service in terms of delivery, queueing, and packet discard. For instance, DiffServ marking allows you to give mission-critical traffic higher priority than other types of traffic. The Shasta 5000 BSN supports the ability to control the setting of the ToS/DS field in the outer IP header for VPRN IPsec tunnels. As a service provider, you can either allow the subscriber to specify the ToS bit settings by configuring (via SCS) the Shasta 5000 BSN to copy the bits previously set by the subscriber from the inner IP header to the outer one. Alternatively, you can control the ToS/DS field settings yourself by explicitly setting the value in the outer IP header.
Dynamic VPRNs with intelligent meshing

The Shasta 5000 BSN supports dynamic VPRNs with intelligent (partial) meshing, also referred to as dynamic membership discovery. A dynamic VPRN allows subscribers to dynamically join the network through use of subscriber templates. Instead of establishing the full mesh of tunnels comprising the entire VPRN, intelligent meshing allows for a tunnel belonging to a VPRN to be set up when the first subscriber requesting use of that tunnel connection logs in to the network to connect to it. If part of a VPRN is unusedsay, a tunnel from BSN-Hub1 to BSN-Hub 6 or a tunnel from BSN-Hub 6 to BSN-Hub 4the tunnel is not constructed until the first subscriber needing use of the connection between the two hubs logs in to the network. Thus, tunnels for a VPRN only exist between Shasta 5000 BSNs that have subscribers for that VPRN. Activation and deactivation of a dynamic VPRN occurs automatically.
214659-B
141
Figure 24 and Figure 25 show examples of VPRNs, one using intelligent meshing and the other using full meshing. The deployment in Figure 24 illustrates intelligent meshing. In this case, the six Shasta 5000 BSNs are deployed as hubs supporting three currently active VPRNs. Three tunnels of the red intelligent mesh VPRN are established because these are the only connections subscribers belonging to the red VPRN are using. Five tunnels are established for the black VPRN because subscribers belonging to that VPRN require these tunnels. Three tunnels provisioned for the blue VPRN are established.
Figure 24 Intelligent (partial) mesh
Chicago
San Francisco
New York City
Los Angeles
Atlanta
Dallas
10113EA
The VPRN in Figure 25 shows a full-meshed VPRN. A full-meshed VPRN is considered less intelligent because all of its tunnels are established from the outset, consuming limited resources whether or not subscribers are using the tunnel connections between hubs.
142
Chapter 7 Virtual Private Networks Figure 25 Full mesh

Chicago
San Francisco
New York City
Los Angeles
Atlanta
Dallas
10112EA
When there are no subscribers attached to a VPRN, the VPRN is removed from the Shasta 5000 BSN. A VPRN is deleted after a delay of 60 seconds from when the last subscriber is removed. In summary, intelligently meshed VPRNs offer these benefits over fully meshed VPRNs: Conservation of resources Tunnels are brought up only when subscribers belonging to the VPRN require them for connections. This flexibility makes resources available that might be required by other VPRNs on the same Shasta 5000 BSN. Reduction of overhead The IKE handshake process between two Shasta 5000 BSNs participating in a tunnel entails a negotiation phase that includes secure establishment of encryption key information. Encryption keys have a maximum lifetime and are changed at regular intervals. Security associations (SAs) are sent between tunnels to rekey for encryption, requiring overhead that otherwise could be avoided until a tunnel is brought up. Dynamic VPRN topologies also decrease overhead by requiring that resources for a VPRN such as FIBs and OSPF instances are allocated only on Shasta 5000 BSNs having active subscribers belonging to the VPRN.
214659-B
143
IPsec tunnel support and VPRN scalability

The Shasta 5000 BSN supports use of IPsec tunnels on both the access (subscriber) side and the trunk (service provider) side. Because they are outside control of the service provider (who can offer some degree of security within its own network even without encryption), subscriber IPsec tunnels coming into the networkfor example, from Contivity servers and third-party routersmust support data encryption. Thus, they require application of either DES or 3DES. (For an overview of IPsec, see IPsec on page 89.) VPRNs are composed of trunk IPsec tunnels from one hub to another. Data encryption is not mandatory for IPsec tunnels provisioned when a VPRN (with or without an Internet connection) is defined in a Shasta 5000 BSN domain as part of a trunk connection mesh. Similar to virtual contexts on the Shasta 5000 BSN, each VPRN is discrete and protected from other VPRNs within the service providers network. Depending on the level of trust the network offers, a customer may require a VPRN with encryption. For details on security concerns regarding VPRNs, see Security considerations on page 147. Whether encryption is used for VPRNs factors into the scalability for any given deployment because encryption relies on use of the HiFn encryption processor, which is a limited processing resource. In order to determine the number of VPRNs your network topology can support, you must take into account the number of subscriber IPsec tunnels terminated on the Shasta 5000 BSNs in your configuration. The interplay between subscriber IPsec tunnels and VPRN IPsec trunk tunnels with encryption is explained later in this section. The actual number of tunnels, and thus VPRNs, that any service provider can support is variable and determined by many factors, not just the total number of IPsec tunnels requiring security.
Factors affecting scalability

The number of VPRNs on each Shasta 5000 BSN is limited to 5000. This limit is set based on the factors contributing to scalability and the understanding that most deployments will not exceed this limit in their requirements. The maximum number of VPRNs theoretically possible is much higher. Note: If you require a greater number of VPRNs, contact your systems engineer who will review your deployment plans to help you determine how to meet your requirements.
144
To determine how many IPsec tunnels and, thus, how many VPRNs, you can support (with and without encryption) for a given implementation, you must consider the interplay among the following hardware and software entities: Subscriber Service Card (SSC). There are six SSCs per Shasta 5000 BSN. Each SSC has four SSMs. The SSC bandwidth limitation is 622 Mb/s. Subscriber Service Module (SSM). There are four SSMs per SSC. Each SSM has four processors and one HiFn chip, which is used for encryption. Throughput on the SSM is 65,000 64-byte packets per second without encryption and 26,000 64-byte packets per second with 3DES. The SSM bandwidth limitation is 155 Mb/s. Maximum user bandwidth per SSM in Mb/s, assuming 1500-byte packets, is 133 Mb/s without encryption. With 3DES encryption, it is 80 Mb/s. Subscriber Services Processor (SSP). There are four SSPs on each SSM. The HiFn chip used for encryption is associated exclusively with only one of the four processors. The bandwidth limitation on the SSP is 80 Mb/s. Each SSP can terminate up to approximately 2000 IPsec tunnels. Of these, each SSP can terminate up to 512 subscribers maximum. (Although this is the maximum number of IPsec tunnels, processor throughput places the actual limit on this number, and you must consider SSP and SSM bandwidth constraints.) Of the remaining tunnels, some are used to terminate the IPsec tunnels belonging to the VPRN trunk mesh. VPRN trunk mesh tunnels associated with secure IPsec subscriber tunnels must be terminated on the same SSP. Each VPRN is terminated on a single SSP. A single SSP can support multiple VPRNs. The SSP bandwidth limitation is 80 Mb/s. HiFn chip. The HiFn chip is required to support DES and 3DES encryption on an IPsec tunnel. The HiFn chip operates with only one of the SSPs on the parent SSM. Subscriber IPsec tunnels. These IPsec tunnels require encryption and must be terminated on the SSM with the associated HiFn chip. Thus, 512 subscriber IPsec tunnels are supported per SSM. Because there are four SSMs per Subscriber Service Card (SSC), a total of 2048 subscriber IPsec tunnels are support per SSC.
214659-B
145
VPRN IPsec tunnels. You can define a VPRN with no encryption in an IPsec profile, and that VPRN could run on an SSP that is not the one the HiFn chip is associated with. The VPRN IPsec tunnels and the subscriber IPsec tunnels they are associated with must be terminated on the same HiFn-related SSM processor.
Security Associations (SAs). Each SSM can support 8000 SAs. Each tunnel consumes four SAs, resulting in 2000 tunnels per SSM. Two SAs are required for each IPsec tunnel. However, because SAs are periodically rekeyed, four SAs could be required per tunnel at any time. The SA overhead restricts the usable number of tunnels on a Shasta 5000 BSN to 32,000. This said, the SA limit is rarely significant and usually is rendered meaningless by other limits. An SA is a set of policies and keys used to protect information. It is a unidirectional and logical connection between two IPsec tunnels. To secure bidirectional communication between two hosts or two security gateways, two SAs (one in each direction) are required.
Figure 26 shows the SSC with four SSMs.

Figure 26 Subscriber service card
Subsciber Service Card (SSC) SSC-1 4 X Subscriber Service Modules SSC-2 SSC-3 SSC-6 4 X Processors and HW Encryption Per SSM
Modular: 2.5 Gbps 5Gbps 10 Gbps
Conrtol Management Card (CMC)
Access/Trunk Line Cards (xLC)

10114EA
146
These are the primary customer-based factors affecting scalability that you must take into account as a service provider offering VPRNs: Number of customers outsourcing their network to you Average number of sites per customer Average sustained bandwidth per site Average number of routes to be advertised per site Whether or not packets are encrypted Number of SAs
For an example service providers deployment offering VPRNs, see Example VPRN deployment constraints test on page 148. This example tests the proposed topology against the Shasta 5000 BSN parameters and constraints to determine if the desired number of VPRNs can be offered. You can terminate only 512 subscriber IPsec tunnels per HiFn SSM giving a total of 2048 per SSC. VPRN trunk mesh tunnels associated with those encrypted IPsec subscriber tunnels must terminate on the same SSPs. To determine the number of IPsec tunnels the Shasta 5000 BSN could support without taking into account other constraining factors, consider the following equations: 2000 tunnels per SSP x 16 SSP per SSC = 32000 x 6 SSCs = 192000 tunnels. Because this number is theoretical and unrealistic given the interplay of other resources and their constraints, an upper limit of 32000 is placed on the number of IPsec tunnels supported by the Shasta 5000 BSN. Less than the majority of subscribers belonging to a service provider will not access the Shasta 5000 BSN across IPsec tunnels, so the maximum capacity should satisfy all service provider requirements.
214659-B
147
For the hardware resources described previously, Table 5 identifies the resource, the number of subscriber tunnels it supports, and any pertinent considerations. These limits are imposed by the number of subscribers supported on the SSP; they are not IPsec-specific limits. Specific deployment scenarios will vary in their use of resources.
Table 5 Subscriber tunnels supported per resource
Resource SSM SSC Shasta 5000 BSN Subscriber tunnels per resource 500 2000 12000 Considerations SSM must have encryption. All SSMs must have encryption. All SSMs must have encryption.
For the hardware resources described previously, Table 6 gives the resource, the number of VPRN tunnels it supports, and any pertinent considerations.
Table 6 VPRN mesh tunnels supported per resource
Resource SSP VPRN tunnels per resource 500 Considerations These tunnels may be encrypted if HiFn is associated with them and depending on how they are provisioned. Only 500 may be encrypted. HiFn is required. Only 2000 may be encrypted. HiFn is required. Only 16000 may be encrypted. HiFn is required.
SSM SSC Shasta 5000 BSN
2000 8000 32000
Security considerations
Some enterprises that outsource their VPRNs will require security. For instance, even if a VPRN is constrained to a network in which the service provider owns the routers, an enterprise might still want security to protect against masquerading, spoofing, and so on because other VPRNs, though separate and protected from one another, are on the same network.
148
Smaller service provider organizations that own the Shasta 5000 BSNs might outsource their use of infrastructure, rendering the network less secure. Even large service providers who own their routers as well as their Shasta 5000 BSNs commonly do not own the fiber. Rather, they outsource it from an ILEC or a CLEC. Outsourcing any aspect of the network opens it to security risks. Security problems can be serious and common on large Internet routers. For any of these reasons, enterprise VPRN customers might want their data encrypted and require that the service provider offer IPsec with encryption.
Example VPRN deployment constraints test

This example describes a service provider network using 20 Release 2.5 Shasta 5000 BSNs deployed to support VPRN customers and subscribers. Then, it tests the network VPRN configurations against the parameters and constraints explored previously in this chapter. The example service provider network encompasses 20 Shasta 5000 BSNs and supports 20,000 VPRNs. Of these VPRNs, 1,000 are VPRNs-and-Internet access and 19,000 are VPRNs alone. The maximum number of VPRNs per Shasta 5000 BSN is 5000 with mainly dial customers using 20 KB of sustained bandwidth. The average number of VPRNs per Shasta 5000 BSN is 2,000. A typical VPRN in this service provider network consists of 5 nodes in a VPRN mesh with a maximum of 9 nodes in a VPRN mesh. The average number of members per VPRN is 50. The largest VPRN has a community of 1000 members. Of these, 100 members are routed. Of the routed members, two have internal subnetworks and the remaining members are single address or single bridged subnetworks. The maximum number of subscribers also using a Shasta 5000 BSN in same service providers network is 5000.
Test 1: Hard limit

Each Shasta 5000 BSN supports 5000 VPRNs. Across the example network, which includes 20 Shasta 5000 BSNs, there are 20,000 VPRNs. Therefore, the network passes the hard limit test.
214659-B
149
Test 2: Non-mesh tunnel test

A Shasta 5000 BSN can support 32,000 IPsec tunnels. Each VPRN mesh requires n-1 tunnels, where n is the number of Shasta 5000 BSNs in the network. The maximum mesh is 9 nodes. Thus, each VPRN requires 8 (9-1) IPsec tunnels. The total number of 5000 VPRNs times 8 IPsec tunnels exceeds the limit of 32,000 IPsec tunnels. Therefore, a different mesh sizea mesh size of 7would be required, based on the following equation: 32,000 IPsec tunnels/(number of VPRNs))+1 See Outcome and resolution on page 149 for how this problem is resolved.
Test 3: Routes and route sizing

VPRN-only member site routes exist in only one VPRN in the network. VPRN-and- Internet access site routes occur in two VPRNs (VPRN and ISP context). The maximum number of routes in all VPRNs is 160,000, which is the number of VPRN-and-Internet members on the Shasta 5000 BSN. In only one network, the maximum number of routes in all VPRNs is 300,000. The total number of routes for the VPRN-and-Internet configuration is 50average.Sub x 5,000 VPRNs) x 2 routes per subscriber = 500,000 routes. The total of 500,000 routes exceeds the limit of 300,000 VPRN-only routes, so the example network fails this test.
Outcome and resolution

The greatest problem in this example scenariobecause it is the largest mismatch between constraint and the networks valueis the number of routes required for the network: 500,000. To solve this problem, the number of VPRN routes must be reduced. This gives 2 routes per subscriber with subnetworks having an average of 50 subscribers, resulting in 3000 VPRNs.
150
Reducing the number of VPRNs also solves the IPsec number test failure. Testing the number of IPsec tunnels with 3000 VPRNs results in less than 32,000 tunnels, which is within the limit: 9-1 * 3000 = 24,000.
Virtual Private Routed Networks without Internet access

The Shasta 5000 BSN provides support for VPRNs alonethat is, VPRNs without Internet access on the same link. Internet connectivity is assumed to be provided by one of the VPRNs member sites. For VPRNs, one ISP provides subscribers with a VPRN while another ISP provides them with Internet access. For instance, subscribers belonging to an enterprise VPRN provided by one ISP might use a router in their own corporate network to connect to a different ISP for their Internet access. The default route in the VPRN FIB points to the VPRN member site that provides Internet support. Every subscriber that is bound through the service profile to a VPRN without Internet access shares a routing table that is separate from the ISP routing table. Many VPRNs can be configured across the same IP network because they are completely separate from each other. Because its routing table is not shared with anything else, a VPRN is analogous to a context, which is a distinct address space and virtual router. Subscribers belonging to the VPRN can access the network across any technology and communicate with other enterprise members of the VPRN across the virtualized core. Figure 27 gives a simple view of a network-based VPRN that does not support Internet access on the same link. Instead, a router at the headquarters site provides access to the Internet via an ISP that is different from the one providing the VPRN. This example shows subscribers from large branch sites and corporate headquarters connected to the VPRN, although small branch site employees and telecommuters could also belong to the VPRN.
214659-B
Chapter 7 Virtual Private Networks Figure 27 VPRN alone (without Internet access)
151
Large Site
Large Site
Shasta 5000 BNC
Shasta 5000 BNC
Opaque Network Shasta 5000 BNC Shasta 5000 BNC
Internet
Large Site
10115EA
Virtual Private Routed Networks with Internet access

The Shasta 5000 BSN provides support for both a VPRN and Internet access across the same connection (through a single link). VPRN plus Internet support allows every subscriber that is bound to a VPRN with Internet support to either constrain communication to the private VPRN network or to gain access to the Internet using the ISPs routing table. There is no default route for a VPRN with Internet access. Instead, the activity falls through to the ISP. For VPRN plus Internet support, the VPRN occupies one VPRN route and one ISP context route. Routes learned are entered in the ISP table as RIP-ACCESS routes. By default, RIP-ACCESS routes are advertised by RIP and OSPF on all interfaces in the ISP context.
152
The Shasta 5000 BSN supports autoprovisioning of network connectivity between network devices via standard Internet Key Exchange (IKE) and maintains individual router tables for each IP VPRN. Use of a policy-based provisioning and management system simply requires the VPRN to be defined with an identity and then individual sites assigned to the VPRN with a policy common for that specific VPRN. (Such a policy also allows basic Internet access to be provided on the same IP connection without a separate virtual circuit and firewall, enabling the VPRN plus Internet support feature.) The Shasta 5000 BSN incorporates a simple traffic-steering mechanism that directs traffic either within the VPRN network or to a public Internet connection. Although the VPRN shares its FIB with the ISPs routing table to make possible VPRN plus Internet support, this sharing of FIBs does not allow other Internet users to gain access to the VPRN subscribers. Rather, session initiation can come from VPRN plus Internet subscribers only. For VPRN plus Internet support, the Shasta 5000 BSN certified firewalls are configured in the VPRN profile to protect subscribers from hacker attacks. Every subscriber bound to a VPRN plus Internet network must have applied to it a special firewall policy. These firewall policy rules enable the Shasta 5000 BSN to determine if the subscriber belongs to the VPRN or if the subscribers packet should be forwarded to the Internet or another destination that its ISP routing table specifies it may be sent to. Table 7 shows an example firewall policy that is commonly used for this purpose.
Table 7 VPRN and Internet firewall policy
Source VPN_addr SUB_addr Destination VPN_addr ANY Service ANY ANY Action Accept_via_VPN Accept
The Shasta 5000 BSN, via SCS, interprets the policy shown in Table 7 in the following way: Rule 1If a packet enters the Shasta 5000 BSN, if the IP network source address of that packet is within the VPRN FIB, and if the packet is destined for an IP network that is also within the VPRN FIB, then the IP packet is forwarded using the VPRN routing table.
214659-B
153
Rule 2If a packet enters the Shasta 5000 BSN, if its IP network source address is within the ISP FIB, and if it is destined to ANY IP network, then this IP packet is forwarded using the ISP routing table. Rule 3 (implicit)Everything else is dropped.
If you are routing a subscribers traffic on the access side and want that traffic to remain within the VPRN, then you would change the policy shown in Table 7 to the policy shown in Table 8.
Table 8
Source VPN_addr SUB_addr VPN_addr SUB_addr
VPRN-only firewall policy

Destination VPN_addr ANY ANY ANY Service ANY ANY UDP port 520 OSPF Action Accept_via_VPN Accept Accept_via_VPN <== for RIP protocol Accept_via_VPN <== For
Figure 28 shows a VPRN in which a single connection is used for VPRN and Internet access.
154
Chapter 7 Virtual Private Networks Figure 28 VPRN plus Internet access support
Branch Site
Internet
SOHO
Shasta 5000 BNC
Shasta 5000 BNC
Opaque Network Shasta 5000 BNC Shasta 5000 BNC
Internet
Large Site
Main Office
10116EA
MPLS and VRF-VPNs

Prior to the introduction of Multi-protocol Label Switching (MPLS), networks in general relied on conventional IP forwarding. This process required that for each packet, each hop perform a forwarding table lookup to determine the appropriate next-hop for the destination address. The table lookup is based on a longest match principle. MPLS is a standards based protocol that combines the benefits of layer 2 switching with layer 3 routing. The Shasta BSN supports RFC 2547bis based VPNs. This implementation includes the following features:
214659-B
155
Labels on page 155 VRF-VPNs on page 155 Label Switched Paths on page 156 Label and packet header formats on page 156 MPLS signaling protocols on page 157 Quality of Service on page 157 VRFs and sites on page 158 Distribution of VPN routing information on page 158 MPLS forwarding on page 159
Labels
As with standard label switching, MPLS assigns labels to packets and uses these labels to perform label swapping. In addition, MPLS defines a mechanism for label distribution, through the use of a label distribution protocol, that advertises locally assigned labels to other MPLS devices. This allows the network to automatically converge based on shortest cost LSPs or engineered LSPs.
VRF-VPNs
A VRF-VPN is a Virtual Private Network structure based on MPLS that incorporates: High-speed layer-2 data forwarding protocol based on BGP/MPLS (2457bis), using Label Switched Paths (LSPs) Quality of Service (QoS) capabilities Traffic engineering capabilities Route distribution using MP-BGP
In a VRF-VPN, Shasta 5000 BSNs serve as Provider Edge (PE) routers. PE routers are also known as Label Edge Routers or Edge Label Switched Routers. Note that although MPLS is not based on IP, it operates in IP networks, adding speed, security, and flexibility.
156
Label Switched Paths

A VRF-VPN uses a set of Label Switched Paths (LSPs) that are set up between the PE routers. Label Switched Routers (LSRs) make up the core of the service providers network. A Label Switched Path is unidirectional and is defined by labels that lead from an ingress PE router to an egress PE router. Traffic enters and leaves the network by way of the PE routers. The Shasta BSNs that serve as PE routers are positioned at ingress and egress points of VRF-VPNs, where most of the work associated with MPLS/BGP VPNs occurs. The PE router also assigns two labels (inner and outer) to each incoming packet and pushes them on the label stack for the packet. The inner label identifies the VRF with which the packet is associated. The outer label specifies a value and an outgoing interface on the PE router. The outer label directly specifies the next step, and indirectly it specifies the entire label switched path. Because IP addresses are not used in an LSP, an LSP can serve as a tunnel through an IP network. The LSR that receives a packet forwarded from the ingress PE router decides how to forward it further, based on the identity of the receiving interface and the value specified in the outer label. The LSR replaces that label with a new label that specifies an outgoing interface to send the packet out on and a new value. In this way each packet proceeds from the ingress PE router to the egress PE router, along the label switched path. When an egress PE router receives a packet on the LSP, it pops the outer label, reads the inner label, and forwards the packet toward its destination, according to the IP address specified in the packets IP header. Thus for establishing and maintaining a label switched path, the PE routers require more processing overhead than the LSRs.
Label and packet header formats

Initial support of MPLS on the Shasta BSN uses shim headers. A shim header consists of 4 bytes. The MPLS label constitutes the first 20 bits, and the format of the label is Shasta specific.
214659-B
157
MPLS signaling protocols

MPLS on Shasta supports two signaling protocols for the distribution of outer labels among LSRs: LDP, which provides downstream unsolicited label distribution with independent control and liberal retention, is used for setting up best-effort LSPs. RSVP-TE, which provides downstream on-demand label distribution, is used for setting up TE tunnels. MPLS-TE support is limited to Explicitly-Routed LSPs (ER-LSPs).
Only one signaling protocol can be chosen on any trunk interface. Diff-Serv support over MPLS is provided for the outer label only and is limited to the ingress direction (access to trunk). Currently the Shasta BSN supports signaling of bandwidth information using RSVP-TE. However, guarantees of bandwidth on the Shasta BSN are not supported.
QoS specification
RSVP-TE can specify resources to allocate to a tunnel. For example, it can specify the bandwidth to reserve on each link.
Quality of Service
MPLS cannot provide exactly the same guarantees for Quality of Service (QoS) that IP protocols provide, because it does not control the delivery of packets from the sender to the receiver, end-to-end. Instead, MPLS operates only between the ingress PE router and the egress PE router. However, a VRF-VPN can be configured to: Reserve resources for flows with specific QoS requirements Provide levels of service similar to those in Diff-Serv and traffic engineering models
158
In an MPLS network you can implement service classes using E-LSPs and L-LSPs. The Shasta BSN currently supports E-LSPs only.
E-LSP
For an E-LSP packets can be assigned to different service classes. Premium service packets can overtake standard service packets. The outer label is not enough to determine the service class.L-LSP
VRFs and sites

Two sites connected to different PE routers can communicate over the backbone only if they are parts of the same VPN. A Virtual Routing and Forwarding (VRF) instance is associated with each site and implemented on a PE router. A given VRF can include multiple VPNs, and a VPN can be part of more than one VRF.
Distribution of VPN routing information

The multiprotocol extension to the BGP routing protocol (see RFC 2283, Multiprotocol Extensions for BGP-4) is used to distribute VRF-VPN information to the PE routers that participate in a VRF-VPN.
Route target
The distribution of VPN routing information is controlled through use of VPN route target communities, implemented as BGP extended communities. Each VRF has an import target list and an export target list, for importing and exporting VPN route target communities from and to other VRFs. The route-target attribute is logically equivalent to a VPN.
Route target profile

A route target profile contains the names of all VPNs (route targets) in which a VRF participates. Only routes necessary for supported VPNs are imported and exported from and to other VRFs.
214659-B
159
Route distinguisher
Each VRF is identified by its route distinguisher. The VPN-IPv4 prefix uniquely identifies a customer address, even if the customer site is using globally non-unique private IP addresses.
MPLS forwarding
After a full mesh of LSPs has been established between the PE routers, the VRF-VPN can forward its traffic on them. LDP or RSVP-TE or both can be used to set up the LSP mesh. The VRF configuration determines which type of LSP (best effort or traffic engineered) is used for forwarding the traffic for that VRF.
Virtual Leased Lines

Virtual leased lines (VLLs) emulate leased lines across an IP backbone, connecting pairs of sites via IP tunnels. In particular for the Shasta 5000 BSN, a VLL is a point-to-point link. It is a connection that is a concatenation of an access connection, an IPsec tunnelif the access connections are on different Shasta 5000 BSNsand another access connection. If the two access connections are on the same BSN, no IPsec tunnel is needed. A VLL provides layer 2 frame transport service only. The BSN does not interpret the frame contents on a VLL, either for forwarding at layer 3 using the IP address, forwarding at Layer 2 using the MAC address, or layer 2 encapsulation translation. For additional details, see Virtual Leased Lines on page 56. Figure 29 shows an example VLL.
160
Chapter 7 Virtual Private Networks Figure 29 Virtual Leased Lines

IP Backbone Branch Remote Office Access Access
IPSec: DES/3DES
Branch Remote Office

10029EA
Virtual local area networks (VLANs)

802.1Q VLANs allow a shared medium, such as Ethernet, to be shared across groups of users. Each Ethernet frame is tagged with a VLAN ID, which identifies the group to which the frame belongs. The Shasta BSN uses VLAN tags to identify the subscriber configured on an Ethernet connection. 802.1p is a method of tagging Ethernet frames with specific user priority. The Shasta BSN supports the mapping of DiffServ Code points to 802.1p user priority levels.
214659-B
161
Contivity CES Server Farm

A Contivity Server Farm is a collection of Contivity CES platforms deployed in conjunction with the Shasta 5000 BSN to allow for termination of VPDN connections that traverse the public Internet. Together, the Contivity Server Farm and the Shasta 5000 BSN provide a total Virtual Private Network (VPN) solution.
Note: The Contivity Server Farm has been declared end-of-life and is no longer a recommended solution.
T
The Shasta 5000 BSN does not terminate subscribers dialing into the platform using IPsec as their access method. To terminate these and other subscribers coming from different sources, a farm of Contivity CES platforms is configured behind the Shasta 5000 BSN. After they are terminated on a Contivity platform, subscribers are then routed to other Shasta 5000 BSNs or on to Internet access, if required. Figure 30 shows a Contivity Server Farm that supports VPN connections coming into the VPN across IPsec tunnels. The Contivity Server also supports telecommuters accessing headquarters across the Internet apart from the VPN.
162
Chapter 7 Virtual Private Networks Figure 30 Contivity Server Farm

Presida Mobile Workers Headquarters On-net LNS CVX 1800 Off-net
Telecommuters Shasta 5000 BSN Shasta 5000 BSN Remote Office Internet NAT Shasta 5000 BSN NAT
NAT
Remote Branch Office

10065EA
Note: In addition to IPsec dial-up connections, the Contivity Server Farm enables enterprises to integrate mobile telecommuters via L2TP, PPTP, or L2F tunnels. In Server Farm mode, the Contivity platform is used only to terminate tunnels. The Contivity Server Farm is supported on the 2600, 4500, and 4600 platforms. To signal between a specific Shasta 5000 BSN, the Contivity Server receiving the remote access VPRN connection uses messages similar to RADIUS accounting messages. The Shasta 5000 BSN acts as a RADIUS server for the Contivity platform belonging to a Server Farm, providing both authentication and accounting services. These requests are forwarded to the Shasta 5000 BSN from the Contivity platform. On the Shasta 5000 BSN, a RADIUS proxy task (RPT) listens for the Contivitys RADIUS requests.The RADIUS proxy profile configuration has the following attributes: authentication listen port, accounting listen port, SYNC listen port, and secret.
214659-B
163
In this environment, the Contivity Server Farm has the following simple configuration: RADIUS configuration of the Shasta 5000 BSN is as a RADIUS server. (There should be only one configuration on the Contivity Server Farm to configure the Shasta 5000 BSN for RADIUS and for synchronized accounting information.) Routing Information Protocol (RIP) is disabled. The address pool is configured.
The Contivity Server Farm terminates tunnels from the following clients: All Contivity IPsec clients, including MS Windows 95, MS Windows 98, MS Windows NT, and MS Windows 2000 Microsoft PPTP clients Win2000 L2TP clients Win2000 L2TP/IPsec clients NTS PPTP clients for the Macintosh Free S/Wan for Linux The IRE IPsec client Other ICSA certified clients Network Associates IPsec clients for the Macintosh Solaris embedded clients AIX embedded clients HP-UX embedded clients
Virtual Private Data Networks

The Shasta 5000 BSN supports a variety of remote access scenarios in which sites and users are connected dynamically to the enterprise network. Remote access solutions rely on PPP encapsulations or IPsec between the subscriber and the ISP or corporate gateway. PPP over Ethernet (PPPoE) is used to extend the PPP session across the local Ethernet segment if the subscriber installation includes multiple PCs. You can deploy the Shasta 5000 BSN to support network-based L2TP Access Concentrator (LAC) and L2TP Network Server (LNS) functionality as well as IPsec termination.
164
L2TP consists of a tunnel plus sessions in the tunnel. The tunnel consists of a control connection and zero or more sessions. An L2TP session is created when an end-to-end PPP session is established between a users PC and an LNS. L2TP uses two types of messages: control and data. Control messages are used for establishment, maintenance, and clearing of tunnels and calls. Data messages are used to encapsulate PPP frames carried over the tunnel. For remote access solutions, subscribers access an ISPs Network Access Server (NAS)/LAC and are tunneled to a corporate Home Gateway (HGW)/LNS. A LAC can be used for either compulsory or voluntary tunneling in the following ways: For compulsory, the tunnel is set up from the LAC to the customer LNS. Compulsory tunneling initiates the tunnel at the NAS/LAC upon subscriber domain authentication through the providers authentication server. For voluntary, the tunnel is set up from a PC. The user initiates the L2TP tunnel; the PC operates as the LAC. The subscribers host initiates the L2TP, IPsec, or PPP tunnel, with the ISP not participating in tunnel creation. In this case, the tunnel terminates at the HGW/LNS located at the corporation or ISP. Figure 31 shows a remote access implementation spanning multiple devices. In the upper part of the diagram, a DSL subscriber is placed in an L2TP tunnel at the providers aggregator, a Shasta 5000 BSN acting as a LAC. This tunnel terminates in a device located at the corporate site with the Contivity Server acting as an LNS. The lower portion of the figure illustrates an Internet wholesaling scenario in which the subscriber is placed in an L2TP tunnel at the Remote Access Server (RAS), a CVX-1000 acting as a LAC. This LAC terminates at an ISP that has deployed the Shasta 5000 BSN as an LNS.
214659-B
Chapter 7 Virtual Private Networks Figure 31 Integrated remote access scenarios

PPPoE PPP/ATM DSLAM Service Mgmt. BSN (LAC) Contivity (LNS) L2TP/IPSec Telecommuter /Home Office
165
Corporation X
Compulsory Tunneling Mobile Workforce CVX-1800 (LAC) BSN (LNS) Corporation Y

10030EA
How dynamic subscribers gain VPRN access

You can enable a PPP, PPPoE, PPPoA, or L2TP subscriber to become a member of a VPRN in the following ways: You can define the subscriber statically via SCS as a member of a specific VPRN. You can configure a RADIUS server to authenticate these PPP subscribers and then have the RADIUS server send back a Shasta 5000 BSN Vendor Specific Attribute telling the Shasta 5000 BSN which VPRN the subscriber belongs to. From Release 2.0 of the Shasta 5000 BSN, you can use RADIUS and DHCP servers within the VPRN network or within the ISP network. For instance, you might have a RADIUS or DHCP server within a VPRN network so that the same IP network would be shared by static subscribers and dynamicthat is, telecommutersubscribers.
166
214659-B
167
Chapter 8 Cable
This chapter explores the role the Shasta 5000 Broadband Service Node plays within the cable modem infrastructure in cable modem deployments. The chapter includes scenarios that address various deployments and uses of the Shasta 5000 BSN as well as the access methods supported in the cable modem environment. Before describing these scenarios, this chapter gives a general overview of the cable modem environment. This chapter includes the following sections: Cable modem deployments and the BSN, next About cable systems on page 168 Cable deployment access methods on page 173 DHCP architecture on page 187
Cable modem deployments and the BSN

Although initially designed to provide downstream transmission of video signals, the cable broadband spectrum today provides two-way transmission of multiple signal types and formats, including voice, video, and data. One area of concern in regard to cable as a broadband access method is its original use as a shared medium, which can sometimes limit download speeds and engender security issues. Though these concerns persist, through careful network planning and application of enhanced IP services, such as the firewall and other security features available through the Shasta 5000 BSN, service providers deploying cable broadband access can readily overcome them.
168
Chapter 8 Cable
Cable modem deployments that support broadband data transmission used for corporate and Internet access have evolved recently to support these two customer requirements: Security in an always-on environment Security in the cable modem environment protects subscribers against hackers and secures the network from users violating Acceptable Use Policies (AUPs). The Shasta 5000 BSN is the only cable aggregation device that offers per-subscriber stateful firewall policies, preventing, among other attempted security breaches, denial-of-service attacks. Security policies may be deployed in bulk for classes of subscribers or they may be customized on a per-subscriber basis. For an overview of security on the Shasta 5000 BSN, see Security on page 34. Open access Open access gives customers the ability to select an ISP, removing the limitation that previously bound the subscriber to a single ISP. In an open access deployment model, the user subscribes to a cable modem service but is not required to use the ISP associated with the cable provider. As open access to ISPs is implemented in cable modem deployments, multiple service operators (MSOs) require an IP services architecture that is capable of on-demand connectivity, a capability supported for both ISPs and corporations by the Shasta 5000 BSN. Figure 32 shows the open-access cable architecture made possible by the Shasta 5000 BSN.
About cable systems

This section gives an overview of the cable modem infrastructure and its interfaces. If you are familiar with cable systems, it is not necessary that you read this overview to understand use of the Shasta 5000 BSN within the cable modem architecture.
214659-B
Chapter 8 Cable
169
This section includes the following topics: Cable modem infrastructure on page 169 Standardized cable system interfaces on page 170 Cable headend on page 171 Cable modem environment on page 172
Cable modem infrastructure

Cable modem infrastructure encompasses support for residential and small business subscribers connected via cable modems to a Hybrid Fiber COAX (HFC) cable plant. This HFC local loop is a cable system that has been upgraded to allow two-way data transmission. To accomplish this transmission, end-to-end cable is replaced with a combination of coax (at the subscriber end) and fiber, as shown in Figure 32. The cable operator segments its service area into regions containing anywhere from 50 to 500 cable modem subscribers, depending on data usage. This region is served by a single downstream channel supporting up to 36 Mb/s. Multiple CMTS headends connect to the Shasta 5000 BSN via Fast Ethernet, which, in turn, connects to ISPs and corporations over the service providers backbone. At the subscriber end, the cable modem may include both data and voice (RJ-11) interfaces without impacting existing video delivery. Figure 32 illustrates the cable modem infrastructure.
170
Chapter 8 Cable Figure 32 Cable modem infrastructure

IP Backbone ranch Remote Office Access Access
IPSec: DES/3DES
Corporate Headquarter
ranch Remote Office

10029E
Standardized cable system interfaces

Many existing cable deployments use proprietary equipment, but most MSO cable providers are migrating to the Data Over Cable Systems Interface Specification (DOCSIS) standard. DOCSIS, developed by the Multimedia Cable Network System (MCNS), which was founded by a group of cable operators, allows for vendor-independent interoperability between cable headends and subscriber cable modems.
Note: The Shasta BSN does not support the DOCSIS standard.
The DOCSIS standard specifies a physical and medium access control (MAC) protocol, offering asymmetric data service between the headend and the subscriber. DOCSIS widens the choice of hardware and vendor options for service providers. Cable service providers can mix and match vendor equipment if the equipment complies with DOCSIS.
214659-B
Chapter 8 Cable
171
The DOCSIS standard covers these main areas: Data interfaces Internal interfaces, such as radio frequency and telephony return Operations support system interface Security management interface
The DOCSIS standard addresses the security issues entailed in sending data across shared media by encrypting the data between the cable modem (CM) and the cable modem termination system (CMTS). DOCSIS does not provide for any specifications of firewalls to protect cable modem subscribers from hackers. However, the Shasta 5000 BSN provides the additional protection of firewalls when used in conjunction with a DOCSIS-compliant CM and CMTS. The following components are required for a DOCSIS-compliant cable deployment scenario: A cable modem (CM) A cable modem termination system (CMTS) A Dynamic Host Configuration Profile (DHCP) server A Trivial File Transfer Protocol (TFTP) server A configuration file
DHCP is often used for dynamic IP address configuration. The DHCP and TFTP servers are managed via a cable modem provisioning system.
Cable headend
A cable deployment solution comprises key components, central of which is the cable headend. The cable headend is where the cable router connects to one or more coaxial links. A typical Hybrid Fiber Cable (HFC) plant is configured in either of the following two ways: As a single headend topology In the single headend architecture, a different channel is used for each optical node, resulting in less efficient use of the frequency spectrum provided to the cable provider.
172
Chapter 8 Cable
As a central headend with secondary hub topology A central headend is the more commonly used architecture in HFC plants because it allows the cable providers to reuse the same transmission channel across the various secondary hubs. Within a cable deployment, a Fast Ethernet (FE) uplink from the cable modem headend will connect directly to the Shasta 5000 BSN (if they are colocated) or to an external FE-ATM converter. Colocation is likely, as a cable provider serving a given metropolitan area may consolidate headends at a central site. The choice of the cable headend will determine the role performed by the Shasta 5000 BSN. If the cable modem headend device performs only layer 2 functionality, the Shasta 5000 BSN will perform all layer 3 processing. Existing cable encapsulations are not session oriented in the same way that dial or DSL are.
Cable modem environment

In the cable modem environment, data is transmitted over shared media. Upstream and downstream data are differentiated from one another, and they run on different frequencies. As cable modem usage spread into the business environment, it was discovered that the upstream bandwidth was insufficient for bandwidth-intensive business applications, such as video conferencing. To address this constraint, many CMTS headends are capable of multiple upstream channels. Upstream and downstream channels and the data they carry are distinguished from one another in the following ways: Upstream channels Upstream data is subscriber data transmitted from a PC up to the CM, then to the CMTS, and on to the Internet. Upstream channels run on frequencies ranging from 5 through 42 MHz. Upstream data is managed by time slotting the upstream frequencies into minislots. The upstream channels (also called return channels) run on frequencies ranging from 5 to 42 MHz. However, a limited number of return paths is available because not all of this bandwidth is usable due to noise. The upstream channel is 3.2 MHz, the maximum throughput is 10.24 Mb/s using QAM16 modulation, or 5 Mb/s using QPSK modulation. The upstream channel width is user-definable, extending up to 3.2 MHz.
214659-B
Chapter 8 Cable
173
Downstream channel Downstream data is data sent from the Internet to the CMTS and on to the CM. Downstream data is transmitted over a 6 MHz analog channel. All data is transmitted using the full 6 MHz, resulting in a maximum throughput per channel of 38.8 Mb/s when using QAM 256 modulation or 26.9 Mb/s when using QAM56 modulation. Downstream channels can be sent over a frequency spectrum ranging from 88 to 860 MHz. The downstream channel width is a fixed bandwidth.
Cable deployment access methods

Cable modem providers, depending on their business models, may offer their customers a choice of access options and protocols. The protocols and architectures described in this section map readily into the Nortel Networks end-to-end cable open access solution, also described in the section. Scenarios for the following access methods, commonly used for cable, are described in this section: Bridged PPPoE client on page 173 (RADIUS) Layer 3 tunnel client on page 176 IP Demux on page 179
Bridged PPPoE client

PPPoE offers cable subscribers an access paradigm similar to analog dial. PPPoE enables service selection and wholesaling via interaction with a RADIUS server and L2TP tunneling. This architecture requires that the user install a software client shim, and it supports subscriber self-provisioning. In the PPPoE deployment environment, the subscriber or the cable operator connects the PC and cable modem. The modem operates in bridged mode, not routed mode. Either the MSO or the ISP delivers the client software to the subscriber and the subscriber installs the PPPoE client on the PC. For an overview of PPPoE, see PPPoE on page 80.
174
Chapter 8 Cable
The protocol architecture for PPPoE places the shim between the PPP layer and the Ethernet MAC (the PPPoE layer). The shim is carried across the cable infrastructure to the Shasta 5000 BSN where it is removed for both ISP contexts or for L2TP tunneling. (The PPPoE shim, which is a client entity, is never carried beyond the Shasta 5000 BSN.) The PPP architecture enables the access provider to offer various options, or models, such as the following: A pure outsource service Multiple ISP contexts within the Shasta 5000 BSN
Outsourced service model

An outsourced service model, which is very simple, supports self-provisioning, but it does not allow the service provider to add value through application of high-touch services to the subscriber. The outsourced service model works in the following way: The subscriber logs in to the ISP selected via a fully qualified domain name (FQDN). For information on FQDNs, see Fully qualified domain names and realms on page 65. The Shasta 5000 BSN maps the subscriber PPP session without the client shim into an L2TP tunnel terminating at the ISPs L2TP Network Server (LNS). The LNS could be another Shasta 5000 BSN or a third-party platform. Figure 33 illustrates this scenario.
214659-B
Chapter 8 Cable Figure 33 PPPoE service selection
175
LNS
ISP Backbone
LAC Cable Modem
LNS
ISP Backbone
LNS
L2TP Tunnels or Routing

10124EA
Multiple ISP contexts service model

In this service model, the following two self-provisioning portal architectures are possible: ISP-specific portal server Each ISP owning a context on the Shasta 5000 BSN may operate its own provisioning portal server. This model requires that subscribers belonging to an ISP know the proper login sequence to the ISP. Initial provisioning portal server The access provider owning the Shasta 5000 BSN makes available an initial provisioning portal server that lists all supported ISPs having a context on the Shasta 5000 BSN, thus providing the user with service selection. Figure 34 illustrates this model. The initial provisioning portal server model works in the following way: The subscriber is directed to the initial provisioning portal for service selection.
176
Chapter 8 Cable
Under this architecture, a new subscriber logs in to the portal, for example, using a login of the type newuser@accessprovider.net. The subscriber is then assigned an IP address from the providers space that limits connection to the portal subnet(s). The subscriber selects an ISP and is directed to that ISPs particular portal. The subscriber enters the required service information at the ISPs portal. The portal communicates this information to the Shasta 5000 BSN Service Creation System (SCS) and to the ISPs RADIUS server. When the subscriber logs in again subsequent to this process, he or she is presented with the ISPs authentication screen, is authenticated, and is then mapped into the proper ISP context within the Shasta 5000 BSN. For this model, the access provider can configure ISP contexts based on static or dynamic routing.
Figure 34 Managed ISP contexts
Demarcation Line Static or Dynamic Routed Contexts ISP Backbone
Subscribers
Telecommuters
Shasta 5000 BSN Cable Operator ISP ISP Backbone

10068EA
Layer 3 tunnel client

The layer 3 client access method enables multiple users within the same household to access both ISPs and corporate enterprise destinations. Layer 3 tunnel client architecture relies on deployment of a tunnel client.
214659-B
Chapter 8 Cable
177
As the MSO or the ISP cooperating with the MSO, you can provide this client to the subscriber. Alternatively, you can allow the subscriber to use the native MS Windows L2TP client. Providing your own client software to the subscriber allows you to brand your service and add value to your network offering. Use of L2TP does not require that the PC be rebooted when a new IP address is used. This is because the architecture is used only in a tunnel (the PCs IP address is not used). Regardless of which method you choose, the following process is the same: 1 2 The subscriber-client creates a tunnel through the DOCSIS architecture to the Shasta 5000 BSN. Either the tunnel is terminated and the client data is routed or the client data is switched to a second tunnel terminating at the selected ISP or corporate enterprise via Fast Ethernet (FE) or ATM.
Figure 35 shows the L2TP tunnels (or MS Windows client software was used) originating with the subscriber clients coming into and terminating at the Shasta 5000 BSN. The client data is then either switched to another L2TP tunnel for transmission to the destination ISP or corporate enterprise, or it is routed to the appropriate destination. If the client data is switched to another L2TP tunnel, the Shasta 5000 BSN acts as the L2TP access concentrator (LAC) and another Shasta 5000 BSN or a third-party platform acts as the L2TP Network Server (LNS).
178
Chapter 8 Cable Figure 35 Layer 3 client service selection
LNS
ISP Backbone
LAC Cable Modem
LNS
ISP Backbone
LNS
L2TP/PPTP Tunnels L2TP Tunnels or Routing

10125EA
For the default configuration, the client process occurs in the following way: The client program issues a DHCP request, identifying the destination ISP. The Shasta 5000 BSN relays the subscribers DHCP request to a colocated or a distant DHCP server. It is preferable because more efficient if the DHCP server is capable of supporting pools for multiple ISPs. This capability is available through the Nortel Networks Preside INAM product. The IP address is sent to the subscriber PC. When the PC receives the IP address, the subscriber is activated within the ISPs service domain.
As an MSO, you may add value to the service by deploying a portal server to advertise local content or your services. Some ISPs provide clients that create their own IP tunnels and assign an additional IP address native to the ISP. A client such as this will function appropriately within the architecture explained in this section.
214659-B
Chapter 8 Cable
179
IP Demux
IP Demux enables support of multiple subscribers behind one access connection. Subscribers have their own sets of services that could include membership in a Virtual Private Network. Subscribers may be static, that is, preconfigured with their own IP addresses, or they may have multiple IP address ranges with a list of services. Static subscribers could also have reachability subnets. With IP Demux, subscribers can be automatically created based on a template specifying a set of services. These subscribers are then automatically created when the Shasta 5000 BSN detects a new IP address. When IP Demux is used, a port is limited to ten access connections for Ethernet access. No such limit applies to ATM access connections with 1483 Bridged or 1483 Routed encapsulations. For IP Demux, an access connection terminates on a Shasta 5000 BSN. For each port, IP Demux can be used for up to 5120 users, on a per-port basis. If an 8-port Fast Ethernet (FE) card is used, then as many users as the Shasta 5000 BSN can handle are supported. The only limitation is that more than one access connection is required to support over 512 users. To enable IP Demux features, the following three items are configured under the subscriber menu: IP Demux container subscriber This container subscriber is a normal subscriber with an additional attribute identifying it as an IP Demux container, which means that it contains multiple subscribers, that is, it is a group holder of subscribers. IP template subscriber (used for automatically generated subscribers) This template subscriber provides the services or service profiles. Multiple IP Demux child subscribers (used to preconfigure subscribers with a specific set of addresses and a specific set of services) The child subscriber is a normal subscriber that is bound by an IP address. The following fields are associated with the child subscriber: the IP address range for the subscriber, which can be one or more disjoint lists of addresses, a set of services or associated service profiles, and participation in a VPN. For an overview of IP Demux, see IP Demux and Ethernet access on page 67.
180
Chapter 8 Cable
This section includes the following scenario sketches for cable modem deployments using IP Demux: Bridged CMTS with all subscribers belonging to a single ISP Bridged CMTS with subscribers belonging to different ISPs Routed CMTS with all subscribers belonging to a single ISP Routed CMTS with subscribers belonging to different ISPs
Bridged CMTS with all subscribers belonging to a single ISP

This cable modem IP Demux scenario is characterized by the following configuration and behavior: The CMTS is used as a bridge. Configure the bridge CMTS not to switch between PCs. It must funnel all packets to the Shasta 5000 BSN for services to be applied. No services can be applied to packets that are switched by the CMTS. The CM can be used either as a bridge or as a router. CMs obtain their IP addresses from the DHCP server reachable through the Shasta 5000 BSN. For PCs, IP addresses are assigned statically or they are assigned through DHCP requests. IP addresses for both the CM and the PC are allocated from the same subnet.
For this scenario, there must exist a static subscriber configuration for one of the CMs that is used as a router. You use the SCS to create the configuration. Assuming that the CMTS is connected to Ethernet port 1 on slot 5 of the Ethernet line card, you would take the following steps using SCS to create the configuration for this scenario. To create the configuration: 1 Create an access connection. Name:Access-1 encap=ethernet slot=5 port=1
214659-B
Chapter 8 Cable
181
Create the IP subscriber template. Name:sub-ip-tempServices:none
Create the IPDemux container subscriber. Name: sub-cmts Dedicated connection: access-1 Addresses:100.1.1.1/24 Forces Proxy ARP Note: Forced proxy ARP is required because all PCs are in the same subnet, and the CMTS is configured not to switch between CMs and PCs.
Create the subscriber. Name: sub-cm 1 Bound by IP-address Addresses: Addr: 100.1.1.2 range -1 Reachability: 190.1.1.0/29 nexthop: 100.1.1.2 (implicit)
For this scenario, subscribers for PCs and for CMs are automatically generated when the Shasta 5000 BSN discovers any IP address in the range of 100.1.1.3 through 100.1.1.254. For instance, when the subscriber with the IP address of 100.1.1.9 sends an IP packet to the Shasta 5000 BSN, the device generates a subscriber with the name sub-ip-temp:100.1.1.9. Services configured for sub-ip-temp are applied to this subscriber.
Bridged CMTS with subscribers belonging to different ISPs

This cable modem IP Demux scenario includes two subnets that do not overlap each other. It is characterized by the following configuration and behavior: On the access side, ISP-1 subnet (100.1.1.1/24) is used. On the access side, ISP-2 subnet (135.1.1.1/25) is used. This subscriber template has a captive portal service.
182
Chapter 8 Cable
The CMTS is used as a bridge. Configure the bridge CMTS not to switch between PCs. It must funnel all packets to the Shasta 5000 BSN for services to be applied. No services can be applied to packets that are switched by the CMTS.
The CM can be used either as a bridge or as a router. CMs obtain their IP addresses from the DHCP server reachable through the Shasta 5000 BSN. For PCs, IP addresses are assigned statically or they are assigned through DHCP requests. IP addresses for both the CM and the PC are allocated from the same subnet. Note: For this scenario, an ISP context could have two or more access connections to allow for support of more than 512 subscribers behind a single CMTS.
For this scenario, all DHCP packets are received on both access connections that is, they are received by both ISPs. DHCP requests are relayed to the appropriate DHCP server. The DHCP server must have a binding address for their subscribers that is based on the MAC address enabling the correct DHCP server to respond to the DHCP request. To create the configuration for ISP-1 using SCS: 1 Create the IP subscriber template. Name:sub-ip-tempServices: none 2 Create the IP Demux container subscriber. Name:sub-cmts Dedicated connection: access-1 Addresses: 1001.1.1/24 3 Create the subscriber. Name:sub-cm1 Bound by IP-address Addresses: Addr:100.1.1.2 range-1
214659-B
Chapter 8 Cable
183
Reachability:190.1.1.0/29 nexthop:100.1.1.2 (implicit) Name:sub-cmts-q Dedicated connection:access-1 Addresses:100.1.1.1/24 To create the configuration for ISP-2 using SCS: 1 Create the IP subscriber template. Name:sub2-ip-temp services: captive-portal-svc 2 Create the IP Demux container subscriber. Name:isp-2-cmts Dedicated connection: access-1 Addresses: 135.1.1.1/24
Routed CMTS with all subscribers belonging to a single ISP

For this cable modem IP Demux scenario, the CMTS is used as a router and it is connected to the Shasta 5000 BSN over Ethernet. All user-subscribers behind the CMTS belong to a single ISP. To eliminate the need for a next hop configuration, the subnet IP address must be a /30 so that there is only one address behind the Shasta 5000 BSN. In this scenario, the CMTS is responsible for the DHCP relay requests for all CMs and PCs that use dynamic addressing. The DHCP server can be connected directly to the CMTS or to the Shasta 5000 BSN. If the DHCP server is connected to the Shasta 5000 BSN, the device interprets the DHCP requests as simple IP packets. This occurs because the Shasta 5000 BSN views the DHCP relay packet from the CMTS to the DHCP server. To create the configuration for this scenario using SCS: 1 Create the access connection. Name:Access-1 encap=ethernet slot=5 port=1 2 Create the IP subscriber template.
184
Chapter 8 Cable
Name:sub-ip-tempServices: captive-portal-1 3 Create the IP Demux container subscriber. Name:sub-cmts Dedicated connection:access-1 Addresses: 100.1.1.1/30 (CMTS address is 100.1.1.2) Reachability: 180.1.1.0/24 (nexthop is assumed to be 100.1.1.2) 181.1.2.0/24 (nexthop is assumed to be 100.1.1.2) 180.1.3.0/24 (nexthop is assumed to be 100.1.1.2) Note: Only 700 subscribers may be active concurrently because the access connection exists on a single Subscriber Services Processor (SSP). 4 Create the subscriber. Name: sub-cm1 Bound by IP-address Addresses: Addr:181.1.2.2 range -1 Reachability: 115.1.1.0/29 (assumed nexthop: 100.1.1.2)
Routed CMTS with subscribers belonging to different ISPs

For this scenario, there are three ISPs. The CMTS is used as a router, and it is connected to the Shasta 5000 BSN over Ethernet. All user-subscribers belong to different ISPs. This configuration assumes that the CMTS has policy-based routing functionality. For this scenario, you must configure the CMTS to route all packets using the following routes: ISP-1 subnets default route to 100.1.1.1. ISP-2 subnets default route to 100.1.1.5. ISP-3 subnets default route to 100.1.1.9.
214659-B
Chapter 8 Cable
185
Assuming that the CMTS is connected to Ethernet port 1 on slot 5 of the Ethernet line card, you would use the following SCS values to create the access connections for this scenario:
Name: Access-1encap=ethernet slot=5 port=1 owner-isp:isp-1 Name: Access-2encap=ethernet slot=5 port=1owner-isp:isp-2 Name: Access-3encap=ethernet slot=5 port=1owner-isp:isp-3
To create the configuration for ISP-1 for this scenario using SCS: 1 Create the IP subscriber template. Name:sub-ip-tempServices:captive-portal-1 2 Create the IP Demux container subscriber. Name:sub-cmts Dedicated connection: access-1 Addresses:100.1.1.1/30 (CMTS address is 100.1.1.2) Reachability: 120.1.1.0/24 (nexthop is assumed to be 100.1.1.2) 125.1.2.0/24 (nexthop is assumed to be 100.1.1.2) 125.1.3.0/24 (nexthop is assumed to be 100.1.1.2) 3 Create the subscriber. Name:sub-cm1 Bound by IP-address Addresses: Addr: 181.1.2.2 range-1 Reachability: 115.1.1.0/2 (assumed next hop: 100.1.1.2)
186
Chapter 8 Cable
To create the configuration for ISP-2 for this scenario using SCS: 1 Create the IP subscriber template. Name:sub-ip-tempServices:captive-portal-1 2 Create the IP Demux container subscriber. Name:sub-cmts Dedicated connection:access-1 Addresses: 100.1.1.5/30 (CMTS address is 100.1.1.6) Reachability: 181.1.1.0/24 (nexthop is assumed to be 100.1.1.6) 181.1.2.0/24 (nexthop is assumed to be 100.1.1.6) 3 Create the subscriber. No dedicated subscribers in this ISP. To create the configuration for ISP-3 for this scenario using SCS: 1 Create the IP subscriber template. Name:sub-ip-tempServices:captive-portal-1 2 Create the IP Demux container subscriber. Name:sub-cmts Dedicated connection:access-1 Addresses:100.1.1.9/30 (CMTS address is 100.1.1.10) Reachability: 200.1.1.0/24 (nexthop is assumed to be 100.1.1.10) 3 Create the subscriber. No dedicated subscribers in this ISP.
214659-B
Chapter 8 Cable
187
DHCP architecture
The DHCP profile architecture does not require end user subscribers to install a software client shim on their personal computers, thus minimizing client support required. Through use of a captive portal, DHCP may also support service selection and wholesaling. To instantiate a user into a DHCP server, the service provider uses the Shasta 5000 BSNs SCS. This architecture supports subscriber self-provisioning. If the Cable Modem Termination System (CMTS) implements routing, this is the preferred access method. Note: If an IP address encompassed by the ISP is redefined, the PC must be rebooted. However, use of the active client software, Broadjump, provides a circumvention to rebooting. Broadjump cleans up instances of older IP addresses from any registers to ensure that new IP addresses are used for all applications. In the DHCP deployment environment, first the subscriber or the cable operator connects the PC and cable modem. The DHCP deployment works in the following way: The subscriber is directed to the DHCP server and assigned a temporary IP lease from the provisioning ISP space operated by the MSO. The subscriber is directed to the service providers provisioning server to select an ISP. The subscriber is directed to the selected ISPs server that provides a web-based provisioning portal operated by the ISP. The subscriber enters the relevant service information.
Figure 36 shows the DHCP architecture with the service providers initial portal server providing the subscriber with service selection.
188
Chapter 8 Cable Figure 36 DHCP architecture with service selection

DHCP Server + RADIUS (opt) SCS
ISP
Portal Server ISP Cable Modem Subscriber CMTS Headend Shasta 5000 BNC Corporation
10128EA
The ISPs Web-based provisioning portal is based on the Shasta 5000 reference architecture customized by the ISP to offer various levels of service. The portal could be the ISPs existing Web-based provisioning system with the interfaces customized to allow the user to enter the required service information. The modem ID, the MAC address, or both are used in the following ways: To provision the DHCP server and the SCS server Optionally, to provision the RADIUS server and a billing server To limit a subscriber to a specific site during the authentication sequence
The following process ensues when the subscriber next logs in to the service after rebooting his or her system: The subscriber is provider with an IP address within his or her ISPs address space. The IP address is assigned to the subscriber through association with the subscribers MAC address.
214659-B
Chapter 8 Cable
189
If the RADIUS server is used, the subscribers login connection is captured by the ISPs login screen to enable the subscriber to enter a user ID and password. The RADIUS profile is applied against the subscriber. The subscriber is mapped to the selected ISP, which is an ISP having a context on the Shasta 5000 BSN.
To change ISPs, the subscriber may access the initial provisioning server via a known URL and repeat this process.
190
Chapter 8 Cable
214659-B
191
Chapter 9 Wholesaling and the Shasta 5000 BSN

This chapter provides scenarios describing the principal ways wholesalers can use the Shasta 5000 BSN to offer their customersISPs, corporations, and content providerscompelling value beyond basic aggregation. The concept of service selection is central to meeting the needs of various customers, and the Shasta 5000 BSN enables the wholesalers to offer their customers a menu of services. The Shasta 5000 BSN can support many user experiences concurrently in a wholesaling infrastructure, allowing a wholesaler to attract a range of customers with widely differing requirements. Note: In many specific instances, the scenarios in this chapter refer to the ISP as the wholesalers customer. Reference to the ISP exclusively is used for simplicity. The customer might be a corporation or a content provider, and not only an ISP. This chapter includes the following sections: About wholesaling and the Shasta 5000 BSN on page 192 L2TP tunneling based on the FQDN on page 195 ISP context membership selection based on FQDN on page 201 ISP membership based on DHCP service selection on page 207 ISP membership based on IP Demux on page 209 Advanced wholesaling and vanity domain support on page 210 Advanced wholesaling using FQDN with realm support on page 213
192
Chapter 2, BSN: overview and features, gives a detailed introduction to wholesaling. Before you read this chapter, be sure that you have read the following sections provided in Chapter 2: Fully qualified domain names and realms on page 65 Realms and global roaming on page 66 Wholesaling on page 68
About wholesaling and the Shasta 5000 BSN

Wholesalers are providers that own and manage the Shasta 5000 BSN platform and offer their customers comprehensive network services. A wholesaler may be any of the following entities: A local service provider, such as an ILEC or CLEC An ISP selling services to other ISPs, as well as managing its own subscriber base
Shasta 5000 BSN wholesalers can offer their customers the following services: Virtual router contexts Routed contexts are private address spaces with routing capabilities that give the wholesaler customer, such as an ISP, local Points of Presence (PoPs). Shasta 5000 BSN-based PoPs enable ISPs to offer their subscribers advanced, high-touch services. Tunneling A wholesaler can take a pipe coming in from a customer and tunnel that pipe up a trunk to a service provider. The service provider might be an ISP, a content provider, or a corporation. Backhauling services Vanity domains Comprehensive network services These services enable local content for the ISP, including network-based firewalls and high-touch services.
214659-B
193
The Shasta 5000 BSN enables wholesalers to increase the value they provide to their customers because they are not selling only bandwidth and access aggregation. Rather, they are selling an entire management and operational infrastructure. The Shasta 5000 BSN gives wholesalers the opportunity to provide ISPs, content providers, and corporations with the services they need by meeting these fundamental customer requirements: Network access universality to the customer The Shasta 5000 BSN allows the wholesaler to aggregate a wide range of network access technologies, including DSL, cable modem, dial, ATM, frame relay, or wireless. For instance, a single Shasta 5000 BSN wholesaler can provide an ISP with access support and high-touch services for all of its subscribers coming into the network edge across diverse access technologies and methods. This capability frees the ISP to focus on content delivery. Service selection model flexibility for each customer ISPs, content providers, and corporations each have their own business model and ways in which they want to differentiate the services they offer their subscribers and users. Some ISPs want simple tunneling. Others want contexts giving them multiple PoPs distributed throughout a wholesalers territory. Still others may require only a backhaul solution to a single site. Therefore, a single solution is unacceptable as a wholesaler offering. Rather, a wholesaler must offer customers a menu, encompassing enough options to fit the specific needs of a variety of customers, each with their own goals. The Shasta 5000 BSN lends itself to this variety of offerings. A wholesaler can decide how best to package the capabilities of the Shasta 5000 BSN to meet its present customer base and scale to accommodate anticipated customer growth. Effective retail partitioning To provide ISPs with true subscriber ownership and to minimize the administrative burden on themselves, wholesalers must offer their customers network management access. They must offer the customer provisioning and viewing capabilities on their own resources and subscriber or user base. At the same time, the wholesaler must secure a subscriber or user base from another customers set of capabilities on the same Shasta 5000 BSN. The Shasta 5000 BSNs Service Creation System (SCS) includes functions for applying these controls. The SCS allows the Shasta 5000 BSN wholesaler to assign ownership of various components of the Shasta 5000 BSN to itself and to its customers. Consequently, the wholesaler and each of its ISP,
194
corporate, and content provider customers has access to and can look at or modify only those components configured by the wholesaler as within the sphere of control of that customer. For instance, because competitive ISPs might be involved, no ISP can ever see another ISPs configuration or subscriber base. Security is maximized while administrative overhead is minimized. A wholesaler determines how much or how little control a customer may have over itself. All provisioning of a customers subscribers or users may be done by the customer itself, freeing the wholesaler from the need to coordinate subscriber service activation. Providing the framework for value-added services In addition to giving the ISP, content provider, or corporation access to their subscribers or users, the Shasta 5000 BSN enables the customer to apply high-touch services, such as firewalls, QoS support, VPN capabilities, and so on, to their subscribers or users. This application is possible because the subscribers PPP session is terminated on the Shasta 5000 BSN. The Shasta 5000 BSN is not restricted to backhauling the session to an ISP platform, for example, that might not have high-touch service application capability. Wholesaling equality and service tiers to attract ISPs When an ISP is considering a wholesaler, the ISP wants to know that it has opportunity equal to that of other ISPs to secure the subscriber base serviced by the wholesaler, including opportunity equal to that of the wholesaler itself, if the wholesaler has a retail arm. The Shasta 5000 BSN makes this possible. The ISP has complete control over the components the wholesaler delegates to it. For instance, a wholesaler may provide an ISP with ownership of a set of PVCs off a DSLAM, and the ISP could determine the types of services to be run on each PVC. Consider the model in which subscriber ownership is dictated by the Fully Qualified Domain Name (FQDN) as specified by user@domain entered by the user through the PPPoE client. In this case, the PPPoE tunnel can be defined as any ISP. This configuration allows subscribers who log in to that infrastructure to choose any of the available ISPs for service selection. The BSN allows an ISP a degree of autonomy that enables the ISP to become a wholesaler should an opportunity present itself.
214659-B
195
It is important for the wholesaler to incorporate wholesale tiering. This is a model that enables the wholesaler to sell different models of service to satisfy different target markets. These tiers are typically referred to as tier 1, tier 2, and tier 3. Wholesale tiering not only satisfies the different needs of various wholesale customers, it also allows the wholesaler to achieve better profit margins than is possible with bandwidth provisioning only. A wholesaler can sell the full value of the Shasta 5000 BSN solution to an ISP, for instance, for a certain price. Another ISP might want a simpler, more traditional lower-cost bandwidth solution because that ISP itself is already providing high-touch services.
L2TP tunneling based on the FQDN

This section describes uses of the L2TP tunneling model based on fully qualified domain names (FQDNs). It includes these sections: Outsource service using compulsory tunneling, next L2TP tunneling configuration and FQDN selection example on page 196
Outsource service using compulsory tunneling

The L2TP tunneling model based on fully qualified domain names (FQDNs) is perhaps the simplest Shasta 5000 BSN architecture. It is familiar to wholesalers because it is akin to the PPP services offered by first-generation Broadband-Remote Access Server (B-RAS) architectures. In this model, the wholesaler offers an outsource service. Subscribers log in to their selected ISP specifying a FQDN. On the Shasta 5000 BSN, the subscriber PPP session, without the PPPoE shim, is mapped into an L2TP tunnel known as a compulsory tunnel. The tunnel terminates at the ISPs L2TP Network Server (LNS), which might be another Shasta 5000 BSN or a third-party platform. This model has the following characteristics and limitations: It supports the Shasta 5000 BSNs self-provisioning feature.
196
It allows for the Shasta 5000 BSN to shape traffic and police individual PPP sessions within the L2TP tunnel without terminating the PPP session. (This capability is unique to the Shasta 5000 BSN.) It does not allow the wholesaler to add much value to the subscriber because the PPP session is terminated at the ISP PoP. (The opportunity to apply high-touch services is passed on to the ISP, which can provide additional value instead.) The fundamental limitation of this model is that no high-touch services can be applied because the L2TP tunnel creates a wrapper around the PPP sessions, and the session traffic itself is perceived as payload.
The L2TP backhaul model can be used advantageously to backhaul a corporate PPP traffic session to an extranet switch such as the Nortel Networks ContivityTM switch. Figure 37 depicts L2TP tunneling based on FQDN.
Figure 37 PPP sessions backhauled via L2TP
LNS
ISP Backbone
Parent LAC LNS ISP Backbone
Parent
Child
Bridge CPE LNS ISP Backbone
PPPoE Tunnels L2TP Tunnels

10067EA
L2TP tunneling configuration and FQDN selection example

This section uses an example configuration to illustrate how to configure the Shasta 5000 BSN to support the L2TP tunneling wholesale model described conceptually in Outsource service using compulsory tunneling on page 195.
214659-B
197
This scenario assumes that a single ISP, known as the ISP wholesaler, owns the Shasta 5000 BSN. The ISP owns the physical infrastructure, the virtual circuits or connections on the access (subscriber) side, all tunnels on the trunk side (toward the ISP and the Internet), and all subscriber templates configured using SCS. For this model, usually the Shasta 5000 BSN is configured with one context, or address space, which the ISP wholesaler controls. Tunnel selection to an ISP or a corporation is based on the FQDN, which is used to map a subscriber template to the correct tunnel. Three entities are created to participate in this scenario: the wholesaler ISP called LEC_ISP, a retailer ISP called RETAIL_ISP, and a corporation called ATLAS. RETAIL_ISP terminates its own services within its own network. ATLAS terminates its DSL services in its corporate site. Figure 38 shows how the components of this networking model fit together and who owns each of them.
198
Chapter 9 Wholesaling and the Shasta 5000 BSN Figure 38 ISP service selection using L2TP tunneling and FQDN
Device 5000 Name: Toronto 5000 IP: 12.12.12.12 Shelf Card/Port Defn Etc. ISP Wholesale ISP: LEC_ISP Default ISP IP: 10.10.10.10 Assigned 5000 Toronto
Connection (1-1-1-52) Connections ISP: LEC_ISP Connection ID: 1-1-1-52 Trunk/Access: Access VPI/VCI: 1/52 Traffic Params: Etc.
Connection (1-1-1-55) Connections ISP: LEC_ISP Connection ID: 1-1-1-55 Trunk/Access: Trunk VPI/VCI: 1/55 Traffic Params: Etc. Routing Static Summary OSPF Selected RIP BGP Trunk Interfaces Connections ID: 1-1-1-55 Interface Type: P2P Local IP: 10.10.1.2 Remote IP: 10.10.1.3 Encap Type: 1483R
Connection Template Conn Template: Any_ISP Type: PPP/L2TP Connection ISP: Any PPP Parameters FQDN ISP Selection Etc. Subscriber (1) L2TP Tunnel Subscriber (1) Template Sub ID Outbound Tunnel Bridging/Routing Service Policies Accounting/Logs Etc.
PPoE Tunnel Connections ID: 1-1-1-52 Conn Template: Any_ISP Session/Tunnel Session/Host FQDN Etc.
Access Group (1) Radius DHCP DNS/NBNS Idle/Session Etc.
Subscriber (X) L2TP Tunnel
Subscriber (X) Template Sub ID Outbound Tunnel Bridging/Routing Service Policies Accounting/Logs Etc.
Access Group (X) Radius DHCP DNS/NBNS Idle/Session TO Etc.
LNS Device/Name LNS IP Connection Template LAC Device/Name LAC IP Authenticate, Etc.
ISP 1 L2TP LNS
Corp X L2TP LNS
Wholesaler ISP Control: LEC_ISP ISP 1 Control: Retail_ISP Corporation X Control: ACME
10137EA
214659-B
199
Table 9 lists the network components shown in Figure 38. Each entry describes a component, where ownership is assigned, and the capabilities the component makes available.
Table 9 Component description for ISP L2TP tunneling and FQDN example
Component (device, infrastructure, connections) 1. Shasta 5000 BSN device (cards, ports, and so on) Ownership assignment Capability or function
Wholesaler ISP, LEC_ISP. LEC_ISP device owner has authority to Provided with add, change, and delete physical device device_owner user IDs. objects on the Shasta 5000 BSN (i.e., cards that constitute the physical infrastructure). Wholesaler ISP, LEC_ISP. This example has only one ISP, the wholesaler ISP. Other examples might include ISPs with their own context on the same Shasta 5000 BSN. Controls the single address space and templates owned by LEC_ISP. Configures for backhauling all subscriber PPP sessions via L2TP. (Individual ISPs do not need context. They use only backhauling services.)
2. ISP component identifier that identifies individual ISPs and which Shasta 5000 BSNs they reside on (Each ISP has its own context, routing tables, and set of subscriber templates.) 3. Connection
Wholesaler ISP, LEC_ISP, Creates ATM connections for both access in its capacity as and trunk purposes. All ATM connections device_owner. are assigned to LEC_ISP. Access connection is VPI/VCI 1.52 with connection ID 1-1-1-52. Trunk connection is VPI/VCI 1.55 with connection ID 1-1-1-55. Wholesaler ISP, LEC_ISP. LEC_ISP has its own trunks and routing used to reach other ISPs so that L2TP tunnels can be formed using them. (In this example, LEC_ISP trunk interfaces are mapped to an OSPF area 0.) Valid ATM connections are selected to create trunk interfaces. This is how ATM connections destined for the wholesaler core network or to make L2TP tunnels routable to other ISPs and corporations are assigned. Trunk interfaces are mapped to routing protocols.
4. Trunk interface and routing
200
Table 9 Component description for ISP L2TP tunneling and FQDN example
Component (device, infrastructure, connections) 5. Connection template Ownership assignment Capability or function
Wholesaler ISP, LEC_ISP. Defines the behavior of the connection above the ATM layer (i.e., encapsulation type expected on the connection: PPP or 1483) and expected subscriber behavior. The connection ISP can be LEC_ISP or ANY because only one ISP and context exists. The domains entered as subscriber templates under the LEC_ISP resolve appropriately when the subscriber enters the FQDN. Wholesaler ISP, LEC_ISP. Ownership of PPPoE session is established when subscriber enters FQDN. Wholesaler ISP, LEC_ISP. When a user logs in with a FQDN, the FQDN is associated with the best matching subscriber template definition. All ISPs use this tunnel. The PPPoE tunnel is linked to a specific ATM connection (1-1-1-52 in the example). Defines how the service operates for the subscriber when the user is identified as a PPP session. The subscriber template defines for the user all security policies, QoS policies, logs and accounting, and policies defining how the Shasta 5000 BSN should process the subscribers traffic. The template directs traffic at the target LAC and down the target L2TP tunnel. Allows individual subscriber templates to be associated with different RADIUS, DHCP, NDN, or NDIS server farms. Thus, within the ISP context, these entities can be applied to different subscribers or groups of subscribers for ultimate flexibility.
6. PPPoE tunnel
7. Subscriber template
8. Access group
Wholesaler, ISP, LEC_ISP.
9. Subscriber L2TP tunnel
Wholesaler ISP, LEC_ISP. Subscriber template is bound to a specific L2TP tunnel. In this example, defines tunnel connectivity and behavior to the RETAIL_ISP. All FQDN PPP sessions within the ATLAS domain (and vanity FQDNs, if any) are inserted into the L2TP tunnel terminating at the ATLAS site on a CPE device functioning as an LNS.
214659-B
201
ISP context membership selection based on FQDN

This section describes using the Shasta 5000 BSN to offer their own private contexts to many ISPs, content providers, and wholesalers. It includes these sections: Using the Shasta 5000 BSN to operate multiple ISP routing contexts, next Context selection based on FQDN example on page 202
Using the Shasta 5000 BSN to operate multiple ISP routing contexts
The wholesaler can dedicate a Shasta 5000 BSN to operate many ISP routing contexts, or use a single Shasta 5000 BSN to offer contexts and other service models concurrently. Whether the wholesaler is an ILEC, CLEC, or ISP, it can sell contexts to ISPs, content providers, and corporations. The Shasta 5000 BSN supports over 64 dynamic routed contexts utilizing BGP, OSPF, or RIP. With static routes, more than several hundred contexts are supported. A subscriber enters an ISPs context, or virtual router, when that subscriber selects the FQDN through the PPPoE client. Figure 39 shows use of the Shasta 5000 BSN for two ISP contexts, although this same configuration could support many contexts.
202
Chapter 9 Wholesaling and the Shasta 5000 BSN Figure 39 ISP context membership
Static Routed Contexts Managed Virtual Routers Vanity ISPs through RADIUS Wholesale DSL Wholesale Dial Demarcation Line LEC/IAP ISP
Subscribers ISP Backbone Telecommuters Shasta 5000 BNC Value Add Wholesaling: Beyond Selling Pipes Corporate Network
10134EA
When this model is used, PPP sessions are terminated at the Shasta 5000 BSN. At the wholesalers discretion, the Shasta 5000 BSNs high-touch services can be extended to every ISP. Each ISP has its own separate address space to prevent any conflicts or security breaches involving shared routing tables. This model lends itself to ISPs with limited PoP ability. They find it especially useful in regard to having presence in remote areas where it is not cost-effective to deploy ISP PoPs. No longer must they backhaul PPP sessions to a single L2TP tunnel at their own PoP to provide their subscribers with high-touch services. Now, for example, an ISP with its headquarters in Manhattan can have access to the subscriber base in upstate New York in the LEC serving that territory.
Context selection based on FQDN example

When the Shasta 5000 BSN is configured to support many contexts, usually the wholesaler ISP and many ISPs each have their own contexts, and possibly so do some corporations and content providers. In this configuration, the wholesaler ISP owns all physical infrastructure, virtual circuits, or connections on the access side, going toward the subscriber. Each ISPwholesaler and retail ISPsis in possession of its own address space, routing, and subscriber configurations.
214659-B
203
This configuration provides each retail ISP equal opportunity to use all advantages and service features the Shasta 5000 BSN offers without incurring the expense of infrastructure development and management. Figure 40 shows how the components in this wholesaling model fit together and who owns each component.
Figure 40 Context selection based on FQDN example
Connection (1-1-1-52) Connections ISP: LEC_ISP Connection ID: 1-1-1-52 Trunk/Access: Access VPI/VCI: 1/52 Traffic Params: Etc. ISP Retail ISP: LEC_ISP Default ISP IP: 30.10.10.10 Assigned 5000 Toronto
Connection (1-1-1-55) Connections ISP: LEC_ISP Connection ID: 1-1-1-55 Trunk/Access: Trunk VPI/VCI: 1/55 Traffic Params: Etc. Routing Static Summary OSPF Selected RIP BGP Trunk Interfaces Connections ID: 1-1-1-55 Interface Type: P2P Local IP: 10.10.1.2 Remote IP: 10.10.1.3 Encap Type: 1483R
Connection Template Conn Template: Any_ISP Type: PPP/L2TP Connection ISP: Any PPP Parameters FQDN ISP Selection Etc. Subscriber (X) L2TP Tunnel
PPoE Tunnel Connections ID: 1-1-1-52 Conn Template: Any_ISP Session/Tunnel Session/Host Etc.
FQDN
Access Group (X) Radius DHCP DNS/NBNS Idle/Session Etc. Subscriber (n) Template Sub ID Outbound Tunnel Bridging/Routing Service Policies Accounting/Logs Etc. Access Group (n) Radius DHCP DNS/NBNS Idle/Session TO Etc.
Corp X L2TP LNS
Wholesaler ISP Control: LEC_ISP ISP 1 Control: Retail_ISP Corporation X Control: ACME
10138EA
204
Table 10 Components for context selection based on FQDN example
Wholesaler ISP, LEC_ISP. LEC_ISP device owner has authority to Provided with add, change, and delete physical device device_owner user IDs. objects on the Shasta 5000 BSN (i.e., cards and ports that constitute the physical infrastructure). Wholesaler ISP, LEC_ISP. Because LEC_ISP is also the device owner, LEC_ISP has the authority to add other ISPs. LEC_ISP adds an ISP called RETAIL_ISP and creates user accounts for it that can access components only within its context scope. User accounts are provided with connections, the ISP subscriber base, and tools for RETAIL_ISP to create its own services. Controls the single address space and templates owned by LEC_ISP. Configures for backhauling all subscriber PPP sessions via L2TP. (Individual ISPs do not need context. They use only backhauling services.)
2. ISP component identifier that identifies individual ISPs and which Shasta 5000 BSNs they reside on (Each ISP has its own context, routing tables, and set of subscriber templates.)
3. Connection
Wholesaler ISP, LEC_ISP, Creates ATM connections for both access in its capacity as and trunk purposes. All ATM connections device_owner. assigned to LEC_ISP in this model for access only. Access connection is VPI/VCI 1.52 with connection ID 1-1-1-52. ATM trunk connections associated with trunks for routing must be assigned to each ISP. Trunk connection is VPI/VCI 1.55 with connection ID 1-1-1-55 assigned to RETAIL_ISP.
214659-B
Chapter 9 Wholesaling and the Shasta 5000 BSN Table 10 Components for context selection based on FQDN example
Component (device, infrastructure, connections) 4. Trunk interface and routing Ownership assignment Capability or function
205
Wholesaler ISP, LEC_ISP. ATM connections destined for each retailing ISP core network or routable L2TP tunnels are assigned by selecting valid ATM connections provided by the wholesaler to create trunk interfaces. Trunk interfaces are mapped to routing protocols. Routing is done independently in each ISP context. RETAIL_ISP has its own trunks and ties routing back to its own backbone using OSPF. RETAIL_ISP trunk interfaces are mapped to OSPF area 0, which allows RETAIL_ISP to manage its own IP address space. Wholesaler ISP, LEC_ISP. Defines the behavior of the connection above the ATM layer (i.e., encapsulation type expected on the connection: PPP or 1483) and expected subscriber behavior. For this example, the connection ISP must be set to ANY because the PPPoE tunnel can be used for any ISPs subscribers. Domains entered as subscriber templates under LEC_ISP and RETAIL_ISP will select the right context and resolve appropriately when the subscriber enters the FQDN in the PPPoE client. Wholesaler ISP, LEC_ISP. Ownership of access tunnel is assigned to the wholesaler providing bandwidth infrastructure. When the subscriber enters the FQDN, ownership is established on the PPP session. All ISPs use this tunnel. This model is different from a 1483 dedicated connection model in which the retail ISP could own the access connection because it would map to a specific subscriber in their customer base. PPPoE tunnel is linked to the ATM connection 1-1-1-52.
5. Connection template
6. PPPoE tunnel
206
Table 10 Components for context selection based on FQDN example

Component (device, infrastructure, connections) 7. Subscriber template Ownership assignment Wholesaler ISP, LEC_ISP. When a user logs in with a FQDN, the FQDN is associated with the best matching subscriber template definition. Capability or function Defines how the service operates for the subscriber when the user is identified as a PPP session. The subscriber template defines for the user all security policies, QoS policies, logs and accounting, and policies defining how the Shasta 5000 BSN should process the subscribers traffic. The template selects the ISP or context based on which ISP owns the subscriber template. This process defines how vanity domains are created per ISP. The subscriber template for the corporate domain wildcard@ATLAS is created under RETAIL_ISP. It becomes part of the RETAIL_ISP address space and uses RETAIL_ISP routing. Allows individual subscriber templates to be associated with different RADIUS, DHCP, NDN, or NDIS server farms, as required. Thus, within an ISP context, these entities can be applied to different subscribers or groups of subscribers for ultimate flexibility.
8. Access group
Wholesaler, ISP, LEC_ISP.
Wholesaler ISP, LEC_ISP. Subscriber template is bound to a specific L2TP tunnel. In this example, defines tunnel connectivity and behavior to the corporation ATLAS. All FQDN PPP sessions within the ATLAS domain are inserted into the L2TP tunnel terminating at the ATLAS corporate CPE device functioning as an LNS.
214659-B
207
ISP membership based on DHCP service selection

The Shasta 5000 BSN offers choices to subscribers who change ISPs or contexts frequently. Use of PPP service selection via PPPoE clients or PPPoA clients lends itself well to many types of subscribers, but especially to telecommuters and other individuals who fit this category. Subscribers who change ISPs frequently but who do not want to use a PPPoE client can use DHCP service selection. This process works in the following way: 1 The subscriber is originally directed to the DHCP server. Because the subscriber is unknown, he or she is assigned a temporary IP lease from a space on the DHCP server operated by the wholesaler. This space is referred to as the provisioning ISP space. The subscriber is then directed to the wholesalers selection and provisioning server. From the wholesalers provisioning server, the subscriber is directed to an ISPs server that presents a Web-based provisioning portal operated by the ISP. Using this portal, the subscriber enters his or her service information. The portal the ISP presents is based on the Shasta 5000 BSNs reference architecture, which is customized by the ISP to offer different service levels. If the portal used is the ISPs existing Web-based provisioning system, the ISP customizes the interfaces to support entry of the subscribers service information. 4 The following systems are provisioned with the information entered by the subscriber through the ISPs portal, and the modem ID and MAC address: the DHCP service and, optionally, a RADIUS server; the SCS and, optionally, a billing server. The modem ID and the MAC address, or only the MAC address, may be used to limit a subscriber to a specific site during the subsequent authentication process. Figure 41 shows this scenario.
2 3
208
Chapter 9 Wholesaling and the Shasta 5000 BSN Figure 41 ISP context membership assignment through DHCP
Application Hosting Customer Service Management
Service Provider Infrastructure Business Partners or Suppliers Internet
Virtual Private Network
Regional or Branch Offices
Customers SOHO 1 Telecommuters Mobile Users

10028EA
When the subscriber next logs in to the service after the system is rebooted, he or she is provided with an IP address belonging to the address space of the ISP the subscriber selected. The association between the subscriber and the ISP is made based on the subscribers MAC address. This process works in the following way: 1 2 3 If a RADIUS server is used, the subscriber is captured by the ISPs login screen. Here, the subscriber enters a user ID and password. The RADIUS user profile is applied against the subscriber. The subscriber is mapped to the proper ISP. The target ISP may be an entity that has a context within the Shasta 5000 BSN.
The subscriber may change ISPs. If the subscriber wishes to do so, he or she accesses the provisioning server through a known URL and then repeats this process. In this scenario, many subscribers within the same household have access to different ISPs and corporations, just as they do when they use PPPoE as their access method.
214659-B
209
ISP membership based on IP Demux

The Shasta 5000 BSN offers an advanced service model, called IPDemux. Fundamental to IP Demux is the concept of a container. A container consists of a range of supported IP addresses. The service provider can group these addresses by subnet into a logical connection and bind an IP address to a subscriber or a subscriber template. After a container is matched to a subscriber template, services personalized for subscribers who are members of the container can be applied to them. The wholesaler allocates the correspondence between containers and ISPs. Different ISPs are allocated different containers, or ranges of IP addresses. Thus, in the IPDemux model, ISP membership for a subscriber is supplied based on an IP address, which is usually assigned through a DHCP server. Subscribers become members of containers either by static or dynamic assignment.
Bulk connection configuration for domain groups

A domain group (also called a limited domain set) consists of one or more associated domains. The SCS Bulk Connection manager allows wholesaling service providers with device owner privileges to associate one or more domain groups with a specific bulk access connection on the Shasta BSN. This enables a service provider to specify or limit which subscribers terminate on a specific bulk access (for example, frame relay or ATM) connection. That is, only a subscriber from a specific domain can access the Shasta BSN over a bulk connection that you designate. This enhancement streamlines the provisioning of large numbers of bulk access connections with domain groups. With this enhancement, service providers are not required to create individual connections and then associate domain groups with each of them. A service provider can associate domain groups with bulk connections using the following encapsulations PPP/FR (CT3 card/port) PPP/ATM (PPPoA using ATM card/port) PPP/ATM with associated PPPoE tunnel (PPPoEoA using ATM card/port)
210
Ethernet/VLAN and connections with encapsulations not mentioned above do not support domain group associations.
Advanced wholesaling and vanity domain support

This section explains vanity domains and gives example scenarios. It includes these topics: About wholesaling and vanity domains, next Vanity domain configuration using L2TP tunneling: examples on page 211 Vanity domain configuration using ISP context membership: examples on page 212
About wholesaling and vanity domains

A vanity domain, defined more fully in Vanity domains on page 67, refers to a private domain name assigned to an organization and owned by that organization. An example of a vanity domain is zylocast.com. Remote Access Server (RAS) platforms implement vanity domain support using aliases. An alias is simply a translation back to the service providers domain, and it relies on the RADIUS server for processing. The Shasta 5000 BSN allows the use of tens of thousands of vanity domains, all usable without the user having to reenter information already provided to RADIUS though SCS. The Shasta 5000 BSN takes this approach to vanity domains: it creates a subscriber template thus, a particular service setfor the vanity domain in the ISP. This allows the vanity domain name to map to a whole range of firewalls or other high-touch services. Use of wildcard subscriber templates can be applied to vanity domains just as they are against the service providers own domains. The Shasta 5000 BSN vanity domain implementation enables members of the vanity domain with the following capabilities:
214659-B
Log in to any ISP under their own domain name Be assigned their own firewall Be placed within their own IP VPN Be provided their own QoS
211
All of these capabilities can occur without additional data entry because of use of wildcards, which passes the user authentication onto the RADIUS server while maintaining the identity of the subscriber. Support for the FQDN model in the Shasta 5000 BSN gives limitless flexibility to ISPs in relation to large numbers of vanity domains. The Shasta 5000 BSN allows for the configuration of RADIUS servers, DHCP servers, DNS servers, and so on, per domain, or even per subscriber. This capability benefits corporate clients who want their broadband telecommuters to be verified against the corporate RADIUS site, not the ISP RADIUS site or the wholesaler RADIUS site. Any number of servers for any number of subgroups required by the ISP can be defined using the Shasta 5000 BSN.
Vanity domain configuration using L2TP tunneling: examples

Authentication and service selection are the primary concerns that affect vanity domains. Vanity domains are usually configured within the wholesalers ISP context. The two examples given in this section assume that the following characteristics apply to the vanity domain called myDomain.com: It exists within the wholesale ISP, ISP_LEC. A wildcard subscriber template called wildcard@myDomain.com is created for the domain. A specific service definition is created for myDomain.gold. The special default subscriber template wildcard@wildcard with LEC_ISP defaulted to bronze service is created. No service definition is required for wildcard@wildcard. The service will default accordingly if the subscriber is located on the RADIUS server.
Example 1
In this example, the subscriber bob@myDomain.gold logs into the domain myDomain. No explicit match is found for subscriber bob@myDomain.gold, so the best match is assessed and applied: wildcard@myDomain.gold. The second best match is determined to be wildcard@myDomain*.
212
For authentication, the FQDN bob@myDomain.gold is sent to the RADIUS server associated with the matched subscriber. Because of how the match and authentication is performed, the explicit FQDN need not be configured in the SCS in any way. As a result of application of this template to the subscriber, the subscriber is provided all the services afforded the wildcard@myDomain.gold subscriber template. Alternatively, it is possible that the subscriber session might not be authenticated and terminated, but rather would be tunneled to the ISP myDomain belongs to or to a corporate site via an L2TP tunnel assigned to the subscriber template.
Example 2
Subscriber joe@groundhog logs in to the network. No domain is defined for groundhog, and the best match found is the default domain, wildcard@wildcard. The default domain relies on LEC_ISP, the wholesaler ISP, for RADIUS server authentication. When the subscriber is authenticated, LEC_ISP may assign the subscriber a bronze level service profile based on the actions defined wildcard@wildcard. LEC_ISP might then subsequently route the subscriber to the public Internet.
Vanity domain configuration using ISP context membership: examples

This scenario gives two examples of use of a vanity domain that belongs to an ISP context. In the ISP context deployment model of the Shasta 5000 BSN, each ISP has its own address space. When vanity domains are used in an ISP context, the subscriber is terminated within the ISP address space on the Shasta 5000 BSN itself. The two examples given in this section assume that the wholesaler ISP, LEC_ISP, creates the following entities and definitions: A wildcard subscriber template called wildcard@myDomain.gold with a specific service definition for myDomain.gold The special default subscriber template wildcard@wildcard
214659-B
213
An LEC_ISP defaulted bronze service, associated with the LEC_ISP defaulted bronze service A vanity domain called wildcard@widget for use in the retail ISP, RETAIL_ISP
Example 1
Subscriber joe@myDomain logs into the network. No domain is defined for myDomain in any ISP on the Shasta 5000 BSN. The onlyand therefore, best domain match is the default domain in the context for the wholesaler ISP, LEC_ISP. The default domain uses the RADIUS server associated with LEC_ISP for authentication. Once the subscriber is authenticated, the LEC_ISP may then assign the subscriber a bronze level service profile and subsequently route the subscriber to the public Internet.
Example 2
Subscriber fred@widget logs in to the network and is matched to the ISP, RETAIL_ISP. The RADIUS server associated with the matching domain name wildcard@widget is used to authenticate the subscriber. The subscriber is provided an IP address within the context owned by RETAIL_ISP. At this point, RETAIL_ISP applies a service definition, taking any of the approaches in the following list. RETAIL_ISP can apply: A default service definition used for RETAIL_ISP. A service definition specific to the customer fred@widget. A service definition for the entire block of subscribers served by the subscriber template wildcard@widget.
Advanced wholesaling using FQDN with realm support

The Shasta 5000 BSN extends the support it provides for global roaming and ISP support by adding the realm element to the FQDN format, resulting in the following prototype, described fully in Realms and global roaming on page 66: realm/user@domain For the Shasta 5000 BSN, the realm element adds a dimension to the FQDN.
214
This section includes the following topics describing use of realms: Realms and dial ISP deployments on page 214. Realms and dial with broadband RADIUS on page 214. Realms and ISP equality for vanity domains on page 215. How the realm feature works on the Shasta 5000 BSN on page 215. Example subscriber selection and steering using the realm feature on page 219.
Realms and dial ISP deployments

In dial ISP implementations, the realm/user@domain format is used to add a third dimension to the FQDN to provide support for roaming. Subscribers dialing into a guest ISP while traveling often require RADIUS authentication and tunneling via their domain to connect to their home ISP through several other ISP networks. Suppose that corporate customer ATLAS does not want to rely on a single ISP for its telecommuters, but rather uses two ISPs: RETAIL_ISP and ALTERNATIVE_ISP. In this case, RETAIL_ISP/user@ATLAS and ALTERNATIVE_ISP/user@ATLAS both require the same RADIUS authentication and tunneling based on domain name (ATLAS) even though they are served by different ISPs on the same Shasta 5000 BSN. This type of global roaming allows the Shasta 5000 BSN wholesaler to offer ISPs value in order for them to effectively compete with one another.
Realms and dial with broadband RADIUS

To satisfy the requirements of all ISPssome wanting the Shasta 5000 BSN to support realms in the FQDN and others wanting the Shasta 5000 BSN not to provide this supportthe Shasta 5000 BSN provides multiple format support. Both the standard FQDN (user@domain) and the extended realm FQDN (realm/ user@domain) are supported. The Shasta 5000 BSN implementation allows each ISP to support multiple formats concurrently without causing issues for other ISPs.
214659-B
215
Realms and ISP equality for vanity domains

The Shasta 5000 BSN provides support for thousands of vanity domains without the realm dimension or the requirement on the user to enter many domains in order to obtain explicit support. Before introduction of realms to the Shasta 5000 BSN, only one ISP controlled the default wildcard@wildcard domain. This limitation created inequity between ISPs, producing an unfair wholesaling model. Use of realms eliminates this inequity. Instead of explicitly entering domain support for each ISPfor example, wildcard@ATLAS and wildcard@widget, the wholesaler can create a default domain action for each ISP. For instance:
RETAIL_ISP/wildcard@wildcard the RETAIL_ISP context.
can be specified as the default profile for
ALTERNATIVE_ISP/wildcard@wildcard can be specified as the default profile for the ALTERNATIVE_ISP context.
It is unnecessary to know in advance what domains belong to either ISP RETAIL_ISP or ALTERNATIVE_ISP if the domain information is entered in the respective ISPs RADIUS server. Given that the subscriber specifies the correct realm, the ISP can define the necessary degree of explicit service mapping, depending on the service definitions and the need for content delivery. It is possible for both ISPs to have only one subscriber template, the default one. In this case, neither ISP needs to enter data to begin offering IP services using the Shasta 5000 BSN.
How the realm feature works on the Shasta 5000 BSN

This section describes how to use the realm feature on the Shasta 5000 BSN and how it works. It includes the following sections: Activating the realm feature on page 216. Authentication formats on page 216. Authentication service process using service provider FQDN on page 217. Authentication service process using service provider FQDN with defaulted domain on page 218.
216
Authentication service process using basic FQDN on page 218. Authentication service for unqualified user on page 219.
Activating the realm feature

When the following two events occur concurrently, the realm feature is activated: The connection template has its ISP value set to ANY. This setting informs the Shasta 5000 BSN that any ISP can use the access tunnelPPPoE might be the access method used, for example. ISP set to ANY also means that ownership of the subscriber is determined by the FQDN when the subscriber enters it. The subscriber enters the FQDN in the format realm/user@domain or realm/ user.
When these two events occur, the realm becomes the ISP-selected context. If the connection template is assigned to a particular ISP instead of ANY, the specified ISP becomes the ISP-selected context, regardless of the realm specification. This functionality and feature preserves existing RADIUS implementations where service selection is not based on realms. The concatenated realm/user is interpreted as the user instead of distinct entities.
Authentication formats
If the realm is provided by the user entering the FQDN, the realm component is handled by RADIUS authentication in either of two ways: it can be interpreted as such, that is, realm/user are interpreted as two distinct entities; both components can together be interpreted as the user. Four basic authentication formats are supported, each with different suboptions, described in the referenced sections. These are the four formats that subscribers can use: Service provider FQDN, specified by realm/user@domain. (See Authentication service process using service provider FQDN on page 217.) Service provider FQDN with defaulted domain specified by realm/user. (See Authentication service process using service provider FQDN with defaulted domain on page 218.)
214659-B
217
Basic FQDN specified by user@domain. (See Authentication service process using basic FQDN on page 218.) Unqualified user specified by user. (See Authentication service for unqualified user on page 219.)
Authentication service process using service provider FQDN

Assuming the subscriber entered the realm/user@domain FQDN through the PPPoE or the PPPoA client, these possible types of authentication are supported by the Shasta 5000 BSN and can be performed: The complete service provider FQDN (realm/user@domain) is authenticated. It is sent to the selected RADIUS server associated with the domain for authentication. The realm component is used for context selection. The domain component is used to identify a subscriber template within the context for assignment of services and for selection of the RADIUS server within the context. Only the user component of the realm/user FQDN entered via the service provider FQDN name is sent to the RADIUS server for authentication. This process is referred to as trimming the realm. It is useful when the ISP does not support the realm feature in its RADIUS implementation. The wholesaler can offer use of this method to other ISPs also. The domain component can be used to identify a subscriber template within a context for assignment of services and for RADIUS server selection within the context. However, the domain component can be trimmed for authentication, if necessary. The user value is sent to the RADIUS server specified as the full FQDN that is, the realm component is not trimmedbut only the user component is authenticated. This allows ISPs who have chosen to enable input of the realm component on their RADIUS servers as part of their user names to maintain consistency. The domain can be used to identify a subscriber template within a context for assignment of services and for RADIUS server selection within the context. However, the domain component can be trimmed for authentication, if necessary.
218
Authentication service process using service provider FQDN with defaulted domain
Assuming the subscriber entered the entire realm/user FQDN in the PPPoE or PPPoA client, the following possibilities are supported: This format is the same as the standard service provider FQDN with the exception that the domain component is assumed to match the wildcard@wildcard template associated with the context selected by the realm. The RADIUS server to be used defaults to the RADIUS server of the context. The user value is sent to the selected RADIUS server specified as the full FQDN that is, the realm component is not trimmedbut only the user component is authenticated. This allows ISPs who have chosen to enable input of the realm component on their RADIUS servers as part of their user names to maintain consistency. Only the user component of the realm/user FQDN entered via the service provider FQDN name is sent to the RADIUS server for authentication. This process is referred to as trimming the realm. It is useful when the ISP does not support the realm feature in its RADIUS implementation. However, the wholesaler can offer use of this method to other ISPs also.
Authentication service process using basic FQDN

Assuming the subscriber entered the entire basic FQDN user@domain in the PPPoE or PPPoA client, the following condition prevails: An ISP is selected based on a match of the domain membership to a subscriber template within a context given that the connection template is assigned to ANY. The domain can be supplied as either an exact match or a partial wildcard. For instance, the domain euphoria would match exactly the subscriber template euphoria, and the context would be selected. However, the next best possible match for the domain euphoria would be the subscriber template euph, possibly belonging to a different context than does euphoria. The RADIUS server used would be the one associated with the subscriber template.
214659-B
219
Authentication service for unqualified user

Assuming the subscriber entered only the user format of the FQDN in the PPPoE or PPPoA client, the following condition prevails: An ISP is selected only if there is one wildcard@wildcard supported. The RADIUS server associated with the wildcard@wildcard is selected.
Example subscriber selection and steering using the realm feature

Use of realms adds a dimension additional to domains, and this dimension is most obvious in an implementation that adds tunneling to context selection. This section provides an example using multiple contexts that enables tunneling to a corporate enterprise from two different ISPs on the same Shasta 5000 BSN based on FQDNs. It applies a fair wholesaling model to the Shasta 5000 BSN. Figure 42 shows how the components of this networking model fit together and who owns each of them.
220
Chapter 9 Wholesaling and the Shasta 5000 BSN Figure 42 ISP service selection using realm and domain FQDN-based example
Connection (1-1-1-52) Connections ISP: LEC_ISP Connection ID: 1-1-1-52 Trunk/Access: Access VPI/VCI: 1/52 Traffic Params: Etc. ISP 1 Routing
Connection (1-1-1-55)
Connection (1-1-1-57)
Trunk Interfaces
Connection Template Conn Template: Any_ISP Type: PPP/L2TP Connection ISP: Any PPP Parameters FQDN ISP Selection Etc. Subscriber (X) L2TP Tunnel
PPoE Tunnel Connections ID: 1-1-1-52 Conn Template: Any_ISP Session/Tunnel Session/Host Etc.
Trunk Interfaces
Routing
ISP 2
FQDN
Access Group (X) Radius DHCP DNS/NBNS Idle/Session Etc. Subscriber (X) Template Access Group (X) Radius DHCP DNS/NBNS Idle/Session TO Etc.
Corp X L2TP LNS
LNS Device Name LNS IP Connection template LAC Device/Name LAC IP Authenticate, Etc.
Wholesaler ISP Control: LEC_ISP ISP 1 Control: Retail_ISP ISP 2 Control: Alternate ISP Corporation X Control: ACME
10139EA
214659-B
221
Table 11 Components for ISP service selection using realm and domain FQDN-based example
Wholesaler ISP, LEC_ISP, provided LEC_ISP device owner has authority with device_owner capable user to add, change, and delete physical IDs. device objects on the Shasta 5000 BSN (i.e., cards and ports that constitute the physical infrastructure). Wholesaler ISP, LEC_ISP. Because ISP context capabilities LEC_ISP is also the device owner, LEC_ISP has the authority to add other ISPs. LEC_ISP adds an ISP called RETAIL_ISP and creates user accounts for it that can access components only within its context scope. RETAIL_ISP has its own trunk connections, routing configuration, and subscriber templates each referencing a specific access group of resources. LEC_ISP adds an ISP called ISP context capabilities ALTERNATIVE_ISP and creates user accounts for it that can access components only within its context scope. ALTERNATIVE_ISP has its own trunking connections, routing configuration, and subscriber templates, each referencing a specific access group of resources.
2. ISP 1 ISP component identifier that identifies individual ISPs and which Shasta 5000 BSNs they reside on (Each ISP has its own context, routing tables, and set of subscriber templates.)
3. ISP 2 ISP identifier component that identifies individual ISPs and which Shasta 5000 BSNs they reside on. (Each ISP has its own context, routing tables, and set of subscriber templates.)
222
Table 11 Components for ISP service selection using realm and domain FQDN-based example (continued)
Component (device, infrastructure, connections) 4. Connection Ownership assignment Wholesaler ISP, LEC_ISP, in its capacity as device_owner. Capability or function Creates ATM connections for both access and trunk purposes. All ATM connections assigned to LEC_ISP in this model for access only. Access connection is VPI/VCI 1.52 with connection ID 1-1-1-52. ATM trunk connections associated with trunks for routing must be assigned to each ISP. Trunking connection is assigned to RETAIL_ISP and ALTERNATIVE_ISP. ATM connections destined for each retailing ISP core network or to make the L2TP tunnels routable are assigned by selecting valid ATM connections to create trunk interfaces. The wholesaler provides the ISP with these connections. Trunk interfaces are mapped to routing protocols. Routing is done independently in each ISP context. RETAIL_ISP and ALTERNATIVE_ISP each has its own trunks; each ties routing back to its own backbone. RETAIL_ISP uses OSPF. ALTERNATIVE_ISP uses BGP. RETAIL_ISP trunk interfaces are mapped to OSPF area 0. ALTERNATIVE_ISP is assigned to AS 22. RETAIL_ISP and ALTERNATIVE_ISP see no routes between them and have no visibility into each others subscriber base services.
5. Trunk interface and routing Wholesaler ISP, LEC_ISP.
214659-B
Chapter 9 Wholesaling and the Shasta 5000 BSN Table 11 Components for ISP service selection using realm and domain FQDN-based example (continued)
Component (device, infrastructure, connections) 6. Connection template Ownership assignment Wholesaler ISP, LEC_ISP. Capability or function
223
Defines the behavior of the connection above the ATM layer (i.e., encapsulation type expected on the connection: PPP or 1483) and expected subscriber behavior on the connection. For this example, the connection ISP must be set to ANY because the PPPoE tunnel can be used for any ISPs subscribers. For use with realms, because the connection ISP is set to ANY, the right context is selected based on the realm provided by the subscriber when he or she enters the FQDN in the PPPoE client. All ISPs use this tunnel. This model is different from a 1483 dedicated connection model in which the retail ISP could own the access connection because the access connection would map to a specific subscriber in their customer base. PPPoE tunnel is linked to the ATM connection 1-1-1-52.
7. PPPoE tunnel
Wholesaler ISP, LEC_ISP. Ownership of access tunnel is assigned to the wholesaler providing DSL infrastructure. When the subscriber enters the FQDN, ownership is established on the PPP session.
224
Table 11 Components for ISP service selection using realm and domain FQDN-based example (continued)
Component (device, infrastructure, connections) 8. Subscriber template Ownership assignment Wholesaler ISP, LEC_ISP. When a user logs in with a FQDN, the FQDN is associated with the best matching subscriber template definition within the context supplied by the realm. Resolution within the context is based on the domain entered as part of the FQDN. Capability or function Defines how the service operates for the subscriber when the user is identified as a PPP session. The subscriber template defines for the user all security policies, QoS policies, logs and accounting, and policies defining how the Shasta 5000 BSN should process the subscribers traffic. The subscriber template is one of the available templates matching the domain under the specified realm. This allows two ISPs to support the same domain name. Subscriber template for corporate domain wildcard@ATLAS is created under RETAIL_ISP; becomes part of RETAIL_ISP address space; uses RETAIL_ISP routing when subscriber enters RETAIL_ISP/user@ATLAS. Corporate domain wildcard@ATLAS could be entered concurrently under the ALTERNATIVE_ISP and be selected when the ALTERNATIVE_ISP/ user@ATLAS is provided by the subscriber via FQDN.
214659-B
Chapter 9 Wholesaling and the Shasta 5000 BSN Table 11 Components for ISP service selection using realm and domain FQDN-based example (continued)
Component (device, infrastructure, connections) 9. Access group Ownership assignment Wholesaler, ISP, LEC_ISP. Capability or function
225
Allows individual subscriber templates to be associated with different RADIUS, DHCP, NDN, or NDIS server farms, as required. Thus, within an ISP context, these entities can be applied to different subscribers or groups of subscribers for ultimate flexibility. Subscriber template is bound to a specific L2TP tunnel. In this example, defines tunnel connectivity and behavior to the corporation ATLAS. All FQDN PPP sessions within the ATLAS domain are inserted into the L2TP tunnel terminating at the ATLAS corporate CPE device functioning as an LNS. For realms, this adds another dimension to RADIUS control. Each domain within the context can have its own RADIUS server regardless of realm. The selected RADIUS server is not restricted to the one associated with the realm entered with the FQDN.
Wholesaler ISP, LEC_ISP. Attempts to minimize the impact of oscillating and fluctuating networks on the global Internet and large providers. When their state changes, individual routes are penalized by removing a portion of the routes credit pool. If the credit pool becomes negative due to multiple state changes within a period of time, the route is not advertised to the providers internal or external peers. Credits are regained over time and the route is advertised again after a period of stability allows the credit pool to become positive again.
226
214659-B
227
Chapter 10 Retailing
This chapter describes how Internet service providers (ISPs), and others, can use the Shasta 5000 Broadband Service Access Node as retailers. It also describes how service providers can support both DSL and dial subscribers on a single platform.
Retailing the Shasta 5000 BSN services

The Shasta 5000 Broadband Service Access Node lends itself well to retail services because of the wide feature set it enables you to offer customers. As a retailer, you can decide to make available a subset of those services or exploit them all in some way, depending on how you want to position yourself in the marketplace and the subscriber base you want to serve. Drawing from available services, you can offer your customers a rich menu including firewalls, Virtual Private Networks (VPNs), and traffic management features such as policy-based forwarding. In fact, you can offer your customers any of the features that wholesalers might offer theirs. For an overview of the services the Shasta 5000 BSN makes available to you for retail, see Chapter 2, BSN: overview and features. Several scenarios exist in which you might use the Shasta 5000 BSN as a retailer. A common retail scenario is that of an Internet service provider (ISP) who purchases a private context (which is much like a virtual router) on the Shasta 5000 BSN from a wholesaler. In turn, the ISP purveys services to its subscriber base. Many other ISPs might also own private contexts on the same Shasta 5000 BSN, establishing themselves are retailers.
228
In the capacity of device owner, the wholesaler (who owns the Shasta 5000 BSN) can grant an ISP retailer (who owns a context on that box) ISP status or ISP status with device owner capacity. An ISP who is also a device owner can not only see his own context, but he can also see the state of the Shasta 5000 BSN. In no case is any ISP ever able to see the context of another ISP. A context owned by an ISP is entirely private. In fact, you could think of it as a separate physical entity in regard to privacy.
Consolidating dial and DSL

As new technologies such as DSL are deployed in conjunction with existing access through dial, service providers seek ways to optimize use of their existing equipment and infrastructure to enable them to easily scale their support. Today, many service providers support both DSL and dial services. Traditionally, these service providers were required to deploy two separate networks, one for broadband DSL and another for narrowband dial. The Shasta 5000 BSN removes this constraint, enabling the service provider to support both access methods on the same network by providing the following capabilities and features: A single platform for both DSL and dial The ability to offer DSL and dial subscribers selection from the same range of services The ability to use the same back-office infrastructure for both DSL and dial. The ability to consolidate all DSL and dial subscriber management and subscriber policies in one central location
214659-B
229
Dial retail
ISPs commonly begin offering their services based on a dial infrastructure. Internet access via dial access is usually offered along lines of the following two models: The ISP owns and maintains the remote access server (RAS) and provides the Internet peering. As the ISPs customer base grows, the ISP might purchase additional Remote Access Servers (RASs) to support the expansion. The ISP leases virtual modems from another service provider. This is called modem wholesaling. Modem wholesalers purchase large modem banks and outsource modems to the ISPs. The responsibility for physically terminating the data calls lies with the wholesaler who owns and operates the shared modem ports. The ISP still maintains control over its individual customers. This option became possible when RAS technology evolved to allow a chassis to be virtually segmented to support multiple ISPs. The physical resource pool is shared by multiple ISPs, but each ISP can control a virtual subset of modems. ISPs that have been in existence for three or more years commonly own the RAS equipment used for offering dial access. These service providers may have customized and optimized many of their services around the dial model. For instance, they might have extended the RADIUS server not only to provide authorization, authentication, and accounting (AAA), but also to perform additional functions such as modem reservation for certain customers. They may have modified billing systems and automated provisioning systems to work with RADIUS so that only a minimum amount of operator intervention is needed. The Shasta 5000 BSN makes extensive use of RADIUS to enable easy integration into existing backoffice operations while enabling you to turn on new services. Most service providers start out with a dial infrastructure. In such a configuration, the CVX 1800 would receive a dial call. Based on either the dialed number (commonly referred to as a DNIS) or the realm (either domain or prefix), the CVX 1800 would query a policy server to determine if the wholesale customer has available modem ports.
230
In the primary solution offered by Nortel Networks, the policy server is the CVX Policy Manager (CPM). The CPM has a view of all the virtual POPs across thousands of CVX 1800 platforms in various geographic locations. Based on the wholesale policy, the CPM determines whether resources are available and then informs the CVX 1800 to allow or deny access. Additionally, the CPM can be used to differentiate customers who receive premium or basic services based on the service level agreements between the wholesaler and the ISP. If the call is denied, the user would either get a busy signal or receive a message stating there are no modem resources available for the ISP. If the call is accepted, the CVX 1800 would tunnel the call using a tunneling protocol such as L2TP to the ISP. At the other end, an L2TP Network Server (LNS) would terminate the call and route or apply the appropriate IP services across the ISP data network. In this scenario, the Shasta 5000 BSN is deployed as an LNS. In another scenario, analog and ISDN dial subscribers would connect to a RAS (such as the CVX-1800 or Versalar 5399) which usually integrates layer 2 processing (such as PPP termination). In this case, a common RADIUS database would be used to service both dial and DSL subscribers, creating common service profiles. However, in some instances the RAS may be placed in a remote colocation (CO), offering only layer 2 services. In this case, all layer 3 termination for dial subscribers would take place on the Shasta 5000 BSN.
DSL retail
The Shasta 5000 BSN can be partitioned into multiple contexts (virtual routers) for client ISPs that retail services to subscribers. Retail ISPs commonly deploy the Shasta 5000 BSN for DSL aggregation and subscriber management, terminating subscriber DSL permanent virtual circuits (PVCs) or tunnels. Retail ISPs configure their own DSL (or dial) subscribers, and effectively control their own virtual partitions of the Shasta 5000 BSN. These client ISPs can offer their subscribers value-added services, based on the features provided by the Shasta 5000 BSN.
214659-B
231
Appendix A List of Acronyms

ABR ACK ACPS ADSL AF AH AIS ALC ANSI API ARP AS ATM BER BGP BOOTP BSN CA Available Bit Rate Acknowledge message AC Power Shelf Asymmetric Digital Subscriber line Assured Forwarding Authentication header Alarm Indication Signal ATM Line Card American National Standards Institute Application Programming Interface Address Resolution Protocol Autonomous Systems Asynchronous Transfer Mode Bit Error Rate Border Gateway Protocol Boot Protocol Broadband Service Node Certificate Authority
232
List of Acronyms
CBR CGI Cid CIDR CLEC CLI CMC CMTS CNM CORBA CPE CT3 DARPA DES, 3DES DH DHCP DIMM DNIS DNS DoS DP DSCP DSL
Constant Bit Rate Common Gateway Interface Connection Identifier Classless Inter-Domain Routing Competitive Local Exchange Carrier Command Line Interface Control and Management Card Cable Modem Termination System Customer Network Manager Common Object Request Broker Architecture Customer Premise Equipment Channelized T3 Department of Defence Advanced Research Projects Agency Data Encryption Standard, Triple DES Diffie Hellman (Group) Dynamic Host Configuration Protocol Dual in-line Memory Module Dialed Number Identification Service Domain Name Server Denial of Service Drop Priority DiffServ Code Point Digital Subscriber Line
214659-B
List of Acronyms
233
DSLAM E1 EF EGP ELC EMS ESP FA FCS FDDI FELC FIB FQDN FTP GELC GFR GRE GUI HA HDLC HiFn HMAC HN
Digital Subscriber Line Access Multiplexer E-carrier digital transmission at 2.048 Mb/s Expedited Forwarding Exterior Gateway Protocol Ethernet Line Card Element Manager System Enhanced Security Payload Foreign Agent Field Check Sequence Fiber-Distributed Data Interface Fast Ethernet Line Card Forwarding Information Base Fully Qualified Domain Name File Transfer Protocol Gigabit Ethernet Line Card Guaranteed Frame Rate Generic Routing Encapsulation Graphical User Interface Home Agent High Speed Digital Subscriber Line A processor circuit used for encryption Keyed Hashing for message encryption Home Network
234
List of Acronyms
HTML HTTP ICMP ICP ID IDL IEC IETF IGMP IGP IIOP IKE ILEC ILMI inARP IOR IP IP demux ISAKMP/Oakley IPsec ISDN IS-IS ISO
214659-B
Hypertext Mark-up Language Hypertext Transfer Protocol Internet Control Message Protocol Intelligent Cell Parser Identifier Interface Definition Language. Interexchange carrier Internet Engineering Task Force Internet Group Management Protocol Interior Gateway Protocol Internet Inter-ORB Protocol Internet Key Exchange Incumbent local exchange carrier Interim Local Management Interface Inverse ARP Interoperable Object Reference Internet Protocol Internet Protocol demultiplexer Internet Security Association and Key Management Protocol/Oakley Key Determination Protocol IP Security Integrated Service Digital Network Intermediate System - Intermediate System International Standards Organization
List of Acronyms
235
iSOS ISP Kb KB L2TP LAC LAN LCP LDAP LNS LSA MAC Mb MB MD-5 MIB MLPPP MN MPLS MRU MTU NAT NEBS
IP Services Operating System Internet Service Provider Kilobits Kilobytes Layer 2 Tunneling Protocol L2TP Access Concentrator Local Area Network Link Control Protocol Lightweight Directory Access Protocol L2TP Network Server Link State Advertisement Media Access Control Megabits Megabytes Message Digest 5 (A one-way hash function) Management Information Base Multilink PPP Mobile Node Multi-protocol Label Switching Maximum Receive Unit Maximum Transmit Unit Network Address Translation Network Equipment Building Standards
236
List of Acronyms
NFS OMG ORB OSPF PCMCIA PCP PDSN PHB PID PING POP PPP PPPoE PPTP PUPS PVC QoS QoTD RADIUS RFC RIP RPT RSVP
Network File System Object Management Group Object Request Broker Open Shortest Path First Personal Computer Memory Card International Association Personal Content Portal Packet Data Serving Node Per-Hop Behavior Process ID Packet Internet Groper Point of Presence Point-to-Point Protocol Point-to-Point Protocol over Ethernet Point-to-Point Tunneling Protocol Point of Use Power Supply Permanent Virtual Circuit Quality of Service Quote of the Day Remote Authentication Dial-in User Service Request for Comment Routing Information Protocol RADIUS Proxy Task Resource Reservation Protocol
214659-B
List of Acronyms
237
SA SCS SFC SHA-1 SLA SMTP SNMP SONET SPI SPM SQL SRTCM SSC SSM SSP SVC T1 T3 TCP ToS TRTCM TTL UBR
Security Association Service Creation System Switch Fabric Card Secure Hash Algorithm-1 Service Level Agreement Simple Mail Transfer Protocol Simple Network Management Protocol Synchronous Optical Network Security Parameters Index Subscriber Policy Manager Structured Query Language Single Rate Three Color Marker Subscriber Service Card Subscriber Service Module Subscriber Service Processor Switched Virtual Circuit T-carrier system digital transmission at 1.544 Mb/s T-carrier system digital transmission at 44.736 Mbps Transmission Control Protocol Type of Service Two Rate Three Color Market Time to Live Unspecified Bit Rate
238
List of Acronyms
UDP UNI VBR VC VCC VCI VLAN VoIP VP VPC VPDN VPI VPN VPRN WAN WFQ WINS WRED WWW XAUTH
User Datagram Protocol User-to-Network interface Variable Bit Rate Virtual Circuit Virtual Circuit Connection Virtual Connection Indicator Virtual LAN Voice over IP Virtual Path Virtual Path Connection Virtual Private Dialed Network Virtual Path Indicator Virtual Private Network Virtual Private Routed Network Wide Area Network Weighted Fair Queueing Windows Internet Name Service Weighted Random Early Detection World Wide Web Authentication software used for Contivity VPN Client termination
214659-B
239
Index
Symbols
/realm/user@domain. See FQDN PPPoE 80 RFC 1483 Bridged 74 RFC 1483 Routed 74 VLAN 95 activity logs 35, 48 agent ATMP 92 aggregation technologies. See access technologies ALC terminating 1483 routed and bridged 75 types supported 75 always-on broadband connection explained 34 security risks 29, 168 anti-spoofing 35 AS defined 99 exterior protocols between 99 Ascend tunnel management protocol 92 ATM line card. See ALC ATMP 92 authentication methods 1483 Bridged and Routed (PCPs) 45 end-user authentication PAP and CHAP 45 for VPNs IKE 46 Authentication, Authorization, and Accounting. See AAA Autonomous Systems. See AS autoprovisioning PCP 64 VPRNs 152 Shasta 5000 Broadband Service Node Concepts Guide
Numbers
2547bis 154, 155 3DES encryption. See IPsec 802.1Q 160
A
AAA authentication forms supported 45 bridging using PPPoE 125 L2TP tunnels for DSL PPP sessions 123 access control. See firewalls access layer defined 25 devices 26 subscriber management services 26 access side area 74 defined 97 routing protocols supported 97 static routing 98 access technologies broadband 73 DSL 120 IP Demux 84 IPSec 89 L2TP 86 narrowband 73 PPP 77, 120 PPPoA 82, 121
240 Index
B
backbone 158 bandwidth 157 BGP 101 BGP extended community 158 BGP/MPLS 155 Border Gateway Protocol. See BGP B-RAS defined 26 limitations 27 bridging ADSL 125 security problems 125 broadband access emergence of 24 broadband network, defined 25 broadband remote access server. See B-RAS broadband service node device, defined 28 bulk provisioning 35
Competitive Local Exchange Carrier. See CLEC compulsory tunnels LACs 164 connection, defined 74 container. See IP Demux content delivery networks 103 content filtering 49 contexts defined 33 Contivity VPN client termination 90 Contivity Server Farm client termination 163 configuration 163 feature 162 conventions, text 19 CPE 51 CT3 defined 79 terminating 1490 routed and bridged 75 customer premises equipment. See CPE customer support 22
C
cable aggregation device 168 CMTS headends 169, 171 DOCSIS compliant requirements 171 downstream channel 173 HFC 169 open access 168 security 168 upstream channels 172 Cable Modem Termination System. See CMTS cache Web caching 71 Channelized T3 line card. See CT3 CHAP 45 CLEC 136 client shim. See PPPoE CMTS 49 214659-B
D
Data Over Cable System Interface Specification. See DOCSIS Data Over Cable Systems Interface Specification 170 data plane. See subscriber data plane deployments cable 168 DOCSIS compliany cable deployment components 171 VPDN 164 VPN with Contivity Server Farm 161 VPRN constraints test 148 VPRN, intelligent meshing 141 VPRN, with Internet access 151 VPRN, without Internet access 150
Index 241 DES56/3DES encryption. See IPSec DHCP server bridged access method requirement 74 RFC 1483 (1490) Bridged protocol, used with 76 differentiated services. See DiffServ Diff-Serv 157 DiffServ QoS, defined 61 Digital Subscriber Line. See DSL distribution of labels 157 DOCSIS 49, 170 domain names 67 DSL 119 DSL Access Multiplexor. See DSLAM DSLAM 119 dynamic connections, types 74 dynamic data plane 58 dynamic membership discovery. See VPRN, intelligent meshing dynamic subscriber. See subscriber firewalls benefits to provider 37 benefits to subscriber 37 defined 35 maintenance 37 network-based 35, 36 performance 38 purpose 36 security rule, example 38 foreign agent 92 Forwarding Information Blocks. See FIB forwarding tables, per-VPN 136 FQDN defined 65 realms 66 Fully qualified domain name. See FQDN
H
half bridging 128 headends. See cable HiFn chip 144 high-touch services defined 28 examples 30 hijacking. See anti-spoofing HN (home network) 92 home network (HN) 92 HTTP requests. See PCP Hybrid Fiber COAX. See HFC
E
egress PE router 156 encapsulations. See access technologies encryption 35 ER-LSP 157 Ethernet 160 explicitly-routed LSP, see ER-LSP 157 export target list 158
I
IKE defined 89 IPSec 89 IKE handshake process 142 import target list 158 ingress PE router 156 Shasta 5000 Broadband Service Node Concepts Guide
F
FA (foreign agent), ATMP 92 Fast Ethernet Line Card/GigabitEthernet Line Card. See FELC/GELC FIB VPRNs 139
242 Index inner label 156 intelligent meshed VPRNs benefits of 142 defined 141 Intermediate System-Intermediate System. See IS-IS Internet Key Exchange. See IKE Internet Protocol Configuration Protocol. See IPCP Internet Protocol Security. See IPSec IP broadband network, defined 24 IP Demux container 85 described 84 Ethernet ports 67 multiple subscribers, single access 84 IP Services Operating System. See iSOS IPCP 120 IP-farm object 116 IPsec defined 89 tunnels 137 VLLs 135 VPRN scalability 144 IP-VPN 51 IS-IS 102 iSOS 32 label 155, 156 inner 156 outer 156 label distribution protocol, see LDP 157 label switched path 155 label switched path, see LSP 156 label switched path. See LSP Layer 2 Tunneling Protocol. See L2TP layer-2 155 LCP 78 PPP 120 LDP 157 line cards ALC 79 CT3 79 FELC/GELC 79 Link Control Protocol. See LCP L-LSP 158 LNS 50 logs. See activity logs LSP 155, 156
M
mass market network customer, defined 24 MLPPP 79, 82 MN (mobile node) 92 mobile node 92 MPLS 154, 155 labels 155 MPLS signaling protocols 157 MPLS-TE 157 Multilink PPP. See MLPPP Multi-protocol Label Switching 154 multiprotocol traffic bridging using RFC 1483 (1490) Bridged protocol 76
L
L2TP control messages 164 data messages 164 described 86 dial support 86 DSL PPP sessions 122 IPSec 87 uses 86 VPDN 164 L2TP Access Concentrator. See LAC L2TP Network Server. See LNS 214659-B
Index 243
N
narrowband, defined 73 network edge. See access layer node, mobile 92
PPPoA described 82 direct host connection 121 DSL 120 PPPoE client shim 76, 80 described 8081 DSL 120 process 80 RFC 1483 Bridged encapsulation 76 product support 22 protocol, Ascend tunnel management 92 provider edge 155 proxy cache servers 116 proxy server. See Web steering proxy services. See content filtering publications hard copy 21 related 20
O
Open Shortest Path First. See OSPF OSPF defined 100 VPRNs 139 outer label 156
P
packet header format 156 packet sniffing. See anti-spoofiing PAP 45 partial meshing. See VPRN, intelligent meshing PC connection, direct host 121 PCP defined modes process uses of
Q
63 106 106 104 QoS defined 58 DiffServ marking 61 for LSPs 155 QoS specification 157
PE router egress 156 ingress 156 personal content portal. See PCP Point-of-Presence. See PoP Point-to-Point Protocol over Ethernet. See PPPoE policy-based forwarding 60 policy-based provisioning VPRNs 152 PoP 31 PPP described 7782 FQDN use 79 PPP over AAL5. See PPPoA
R
RAC 80 RADIUS support for Contivity VPN client termination 90 RADUIS server. See AAA remote access concentrator. See RAC reserve resources 157 RFC 1483 Bridged encapsulation dedicated 76 defined 76 DSL 120 Shasta 5000 Broadband Service Node Concepts Guide
244 Index dynamic 76 over AALC 80 solution to layer 2 bridging problems 126 RFC 1483 Routed encapsulation DSL 120 for small business use 75 RFC 1490 Bridged encapsulation dedicated 76 defined 76 DSL 120 RFC 1490 Routed encapsulation DSL 120 LLC encapsulation multiprotocol VC 75 RFC 2547bis 154 RIP 100 route distribution using MP-BGP 155 route target community 158 route-target attribute 158 routing BGP 101 defined 99 IS-IS 102 OSPF 100 RIP 100 routing information protocol. See RIP RSVP-TE 157 anti-spoofing 35 bridging 125 cable 49, 167 CMTS for cable 49 defined 34 encryption 48 policies 35 RADIUS authentication 35 Security Associations. See SA security policies bulk provisioning 35 service classes 158 Service Creation System. See SCS service level agreements 58 services contexts 33 security 34 firewalls 35 Shasta 5000 BSN cable aggregation device 168 emergence of 28 integration with back-office systems 45 interoperating components 31 main services listed 32 scalability 31 services. See services subscribers 31 VPNs 136 signaling protocols MPLS 157 spoofing. See anti-spoofing SSC, VPRN scalability 144 SSM, VPRN scalability 144 SSP, VPRN scalability 144 static connections, types 74 static subscriber. See subscriber subscriber data plane 32 defined 31 dynamic 85
S
scalability modular 30 Shasta 5000 BSN platform 31 VPRNs 136 SCS defined 32 VPNs 54 SecureID cards 45 security activity logs 48 214659-B
Index 245 multiple subscribers, IP Demux 84 static subscriber 85 traffic, segmenting 39 subscriber aggregation. See universal subscriber aggregation subscriber edge capabilities 27 defined 26 Subscriber Service Card. See SSC Subscriber Service Module. See SSM Subscriber Services Processor. See SSP support, Nortel Networks 22 rule-based shapers 60 trunk side defined 97 routing protocols supported 97 tunnels DSL PPP sessions 122 IPSec 50, 89, 136, 137 VPRNs 55 VRPN scalability 144
U
universal subscriber aggregation access technologies supported 31 emerging technologies 23 illustrated 28
T
tags VLAN 160 technical publications 21 technical support 22 template subscriber VPRN 140 subscriber template defined 85 text conventions 19 throughput, problems addressed by broadband 24 topology discovery through routing protocols 97 ToS/DS byte 140 traffic engineering 155, 157 traffic management defined 58 drop priorities 62 ingress application of 61 policing 59 shaping 60 traffic policing 59 traffic shaping AF class-based shapers 60 defined 60
V
Virtual Leased Line. See VLL virtual local area network 160 Virtual Local Area Network. See VLAN Virtual Private Dial Network. See VPDN virtual private network. See VPN Virtual Private Routed Network. See VPRN virtual routing and forwarding instance, see VRF 158 VLAN 160 ID 160 tags 160 VLAN, defined 95 VLL defined 56 IPSec 57, 135 with and without IPSec 159 voluntary tunnels LACs 164 VPDN defined 57 L2TP 164 VPN 158 Shasta 5000 Broadband Service Node Concepts Guide
246 Index assurances made by 53 benefits 51 defined 50, 135 deployment scenario 137 forwarding tables 136 IKE 46 IP Demux 84 IP-VPN 51 network-based, defined 51 security encryption 48 IPSec 48 tunnels for 50 VPRN defined 54, 137 DiffServ marking 140 dynamic subscribers 165 dynamic topologies 142 FIB 139 HiFn chip 144 intelligent meshing 140 IPSec security 55 IPSec tunnels 143 policy-based provisioning 152 scalability 143 security 147 universal subscriber support 139 uses and advantages 138 with Internet access 151 with Internet access, firewall policy 152 without Internet access 150 VRF-VPN 155 ISP as wholesaler 69 WRED 61
W
Web steering applications 71 content filtering 49, 113 high availability (ha) 115 rule-based format 114 Weighted Random Early Detection. See WRED wholesalers capabilities with the BSN 68 214659-B

Shasta 5000 Broadband Service Node Concepts Guide, Release 4.0

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Shasta 5000 Broadband Service Node Concepts Guide, Release 4.0

Încărcat de

Drepturi de autor:

Formate disponibile

Part No.

214659-B September 2003 600 Technology Park Billerica, Massachusetts 01821

Shasta 5000 Broadband Service Node Concepts Guide, Release 4.0

Copyright 2002 Nortel Networks

Restricted Rights Legend

Nortel Networks Inc. Software License Agreement

Shasta 5000 Broadband Service Node Concepts Guide

Chapter 1 Emergence of the BSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Chapter 2 BSN: overview and features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Chapter 3 Access technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Chapter 4 Routing protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Shasta 5000 Broadband Service Node Concepts Guide

Chapter 5 Content technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Chapter 6 DSL aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Chapter 7 Virtual Private Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Chapter 8 Cable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Shasta 5000 Broadband Service Node Concepts Guide

Chapter 9 Wholesaling and the Shasta 5000 BSN . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Chapter 10 Retailing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

List of Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

Shasta 5000 Broadband Service Node Concepts Guide

Shasta 5000 Broadband Service Node Concepts Guide

Before you begin

New in this Document

Shasta 5000 Broadband Service Node Concepts Guide

angle brackets (< >)

Shasta 5000 Broadband Service Node Concepts Guide

Printed Technical Manuals

Shasta 5000 Broadband Service Node Concepts Guide

How to get help

Chapter 1 Emergence of the BSN

Emergence of the broadband network

Shasta 5000 Broadband Service Node Concepts Guide

Chapter 1 Emergence of the BSN

Chapter 1 Emergence of the BSN

Bringing high-speed connectivity to the mass market

The edge and the access layer

Shasta 5000 Broadband Service Node Concepts Guide

Chapter 1 Emergence of the BSN

The Broadband Remote Access Server (B-RAS)

Chapter 1 Emergence of the BSN

Shasta 5000 Broadband Service Node Concepts Guide

Chapter 1 Emergence of the BSN

Meeting the need for an intelligent access aggregator

Chapter 1 Emergence of the BSN Figure 1 Universal aggregation

Shasta 5000 BSN

Shasta 5000 Broadband Service Node Concepts Guide

Chapter 1 Emergence of the BSN

Chapter 2 BSN: overview and features

About the Broadband Service Node

Chapter 2 BSN: overview and features

Shasta 5000 BSN services

Chapter 2 BSN: overview and features

Shasta 5000 Broadband Service Node Concepts Guide

Chapter 2 BSN: overview and features

Chapter 2 BSN: overview and features

Shasta 5000 Broadband Service Node Concepts Guide

Chapter 2 BSN: overview and features

Using firewalls for security

Chapter 2 BSN: overview and features

Shasta 5000 Broadband Service Node Concepts Guide

Chapter 2 BSN: overview and features