320747-A 00 PDF

Part No.
320747-A September 2005 600 Technology Park Drive Billerica, MA 01821-4130
Configuring the Metro Ethernet Passport 8600 Switch using Device Manager
Metro Ethernet Passport 8600 Release 4.0
*320747-A
Copyright Nortel Networks Limited 2005. All rights reserved.

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 Inc.
Trademarks
Nortel, the Nortel logo, the Globemark, Unified Networks, OPTera, Passport, and BayStack are trademarks of Nortel. Microsoft, Windows, and Windows NT are trademarks of Microsoft Corporation. Netscape and Navigator are trademarks of Netscape Communications Corporation. IPX is a trademark of Novell Inc. UNIX is a trademark of X/Open Company Limited.
Statement of conditions
In the interest of improving internal design, operational function, and/or reliability, Nortel Inc. reserves the right to make changes to the products described in this document without notice. Nortel 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.
Nortel Inc. software license agreement

NOTICE: Please carefully read this license agreement before copying or using the accompanying software or installing the hardware unit with pre-enabled software (each of which is referred to as Software in this Agreement). BY COPYING OR USING THE SOFTWARE, YOU ACCEPT ALL OF THE TERMS AND CONDITIONS OF THIS LICENSE AGREEMENT. THE TERMS EXPRESSED IN THIS AGREEMENT ARE THE ONLY TERMS UNDER WHICH Nortel WILL PERMIT YOU TO USE THE SOFTWARE. If you do not accept these terms and conditions, return the product, unused and in the original shipping container, within 30 days of purchase to obtain a credit for the full purchase price. 1. License grant. Nortel Inc. (Nortel) grants the end user of the Software (Licensee) a personal, nonexclusive, nontransferable license: a) to use the Software either on a single computer or, if applicable, on a single authorized device identified by host ID, for which it was originally acquired; b) to copy the Software solely for backup purposes in support of authorized use of the Software; and c) to use and copy the associated user manual solely in support of authorized use of the Software by Licensee. This license applies to the Software only and does not extend to Nortel Agent software or other Nortel software products. Nortel Agent software or other Nortel software products are licensed for use under the terms of the applicable Nortel Inc. Software License Agreement that accompanies such software and upon payment by the end user of the applicable license fees for such software.
320747-A
3
2. Restrictions on use; reservation of rights. The Software and user manuals are protected under copyright laws. Nortel and/or its licensors retain all title and ownership in both the Software and user manuals, including any revisions made by Nortel or its licensors. The copyright notice must be reproduced and included with any copy of any portion of the Software or user manuals. Licensee may not modify, translate, decompile, disassemble, use for any competitive analysis, reverse engineer, distribute, or create derivative works from the Software or user manuals or any copy, in whole or in part. Except as expressly provided in this Agreement, Licensee may not copy or transfer the Software or user manuals, in whole or in part. The Software and user manuals embody Nortel and its licensors confidential and proprietary intellectual property. Licensee shall not sublicense, assign, or otherwise disclose to any third party the Software, or any information about the operation, design, performance, or implementation of the Software and user manuals that is confidential to Nortel and its licensors; however, Licensee may grant permission to its consultants, subcontractors, and agents to use the Software at Licensees facility, provided they have agreed to use the Software only in accordance with the terms of this license. 3. Limited warranty. Nortel warrants each item of Software, as delivered by Nortel and properly installed and operated on Nortel hardware or other equipment it is originally licensed for, to function substantially as described in its accompanying user manual during its warranty period, which begins on the date Software is first shipped to Licensee. If any item of Software fails to so function during its warranty period, as the sole remedy Nortel will at its discretion provide a suitable fix, patch, or workaround for the problem that may be included in a future Software release. Nortel further warrants to Licensee that the media on which the Software is provided will be free from defects in materials and workmanship under normal use for a period of 90 days from the date Software is first shipped to Licensee. Nortel will replace defective media at no charge if it is returned to Nortel during the warranty period along with proof of the date of shipment. This warranty does not apply if the media has been damaged as a result of accident, misuse, or abuse. The Licensee assumes all responsibility for selection of the Software to achieve Licensees intended results and for the installation, use, and results obtained from the Software. Nortel does not warrant a) that the functions contained in the software will meet the Licensees requirements, b) that the Software will operate in the hardware or software combinations that the Licensee may select, c) that the operation of the Software will be uninterrupted or error free, or d) that all defects in the operation of the Software will be corrected. Nortel is not obligated to remedy any Software defect that cannot be reproduced with the latest Software release. These warranties do not apply to the Software if it has been (i) altered, except by Nortel or in accordance with its instructions; (ii) used in conjunction with another vendors product, resulting in the defect; or (iii) damaged by improper environment, abuse, misuse, accident, or negligence. THE FOREGOING WARRANTIES AND LIMITATIONS ARE EXCLUSIVE REMEDIES AND ARE IN LIEU OF ALL OTHER WARRANTIES EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Licensee is responsible for the security of its own data and information and for maintaining adequate procedures apart from the Software to reconstruct lost or altered files, data, or programs. 4. Limitation of liability. IN NO EVENT WILL Nortel OR ITS LICENSORS BE LIABLE FOR ANY COST OF SUBSTITUTE PROCUREMENT; SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES; OR ANY DAMAGES RESULTING FROM INACCURATE OR LOST DATA OR LOSS OF USE OR PROFITS ARISING OUT OF OR IN CONNECTION WITH THE PERFORMANCE OF THE SOFTWARE, EVEN IF Nortel HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. IN NO EVENT SHALL THE LIABILITY OF Nortel RELATING TO THE SOFTWARE OR THIS AGREEMENT EXCEED THE PRICE PAID TO Nortel FOR THE SOFTWARE LICENSE. 5. Government licensees. This provision applies to all Software and documentation acquired directly or indirectly by or on behalf of the United States Government. The Software and documentation are commercial products, licensed on the open market at market prices, and were developed entirely at private expense and without the use of any U.S. Government funds. The license to the U.S. Government is granted only with restricted rights, and use, duplication, or disclosure by the U.S. Government is subject to the restrictions set forth in subparagraph (c)(1) of the Commercial Computer SoftwareRestricted Rights clause of FAR 52.227-19 and the limitations set out in this license for civilian agencies, and subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause of DFARS 252.227-7013, for agencies of the Department of Defense or their successors, whichever is applicable. 6. Use of software in the European Community. This provision applies to all Software acquired for use within the European Community. If Licensee uses the Software within a country in the European Community, the Software
4
Directive enacted by the Council of European Communities Directive dated 14 May, 1991, will apply to the examination of the Software to facilitate interoperability. Licensee agrees to notify Nortel of any such intended examination of the Software and may procure support and assistance from Nortel. 7. Term and termination. This license is effective until terminated; however, all of the restrictions with respect to Nortel copyright in the Software and user manuals will cease being effective at the date of expiration of the Nortel copyright; those restrictions relating to use and disclosure of Nortel confidential information shall continue in effect. Licensee may terminate this license at any time. The license will automatically terminate if Licensee fails to comply with any of the terms and conditions of the license. Upon termination for any reason, Licensee will immediately destroy or return to Nortel the Software, user manuals, and all copies. Nortel is not liable to Licensee for damages in any form solely by reason of the termination of this license. 8. Export and re-export. Licensee agrees not to export, directly or indirectly, the Software or related technical data or information without first obtaining any required export licenses or other governmental approvals. Without limiting the foregoing, Licensee, on behalf of itself and its subsidiaries and affiliates, agrees that it will not, without first obtaining all export licenses and approvals required by the U.S. Government: (i) export, re-export, transfer, or divert any such Software or technical data, or any direct product thereof, to any country to which such exports or re-exports are restricted or embargoed under United States export control laws and regulations, or to any national or resident of such restricted or embargoed countries; or (ii) provide the Software or related technical data or information to any military end user or for any military end use, including the design, development, or production of any chemical, nuclear, or biological weapons. 9. General. If any provision of this Agreement is held to be invalid or unenforceable by a court of competent jurisdiction, the remainder of the provisions of this Agreement shall remain in full force and effect. This Agreement will be governed by the laws of the state of California. Should you have any questions concerning this Agreement, contact Nortel Inc., 2375 N. Glenville Dr., Richardson, TX 75082. LICENSEE ACKNOWLEDGES THAT LICENSEE HAS READ THIS AGREEMENT, UNDERSTANDS IT, AND AGREES TO BE BOUND BY ITS TERMS AND CONDITIONS. LICENSEE FURTHER AGREES THAT THIS AGREEMENT IS THE ENTIRE AND EXCLUSIVE AGREEMENT BETWEEN Nortel AND LICENSEE, WHICH SUPERSEDES ALL PRIOR ORAL AND WRITTEN AGREEMENTS AND COMMUNICATIONS BETWEEN THE PARTIES PERTAINING TO THE SUBJECT MATTER OF THIS AGREEMENT. NO DIFFERENT OR ADDITIONAL TERMS WILL BE ENFORCEABLE AGAINST Nortel UNLESS Nortel GIVES ITS EXPRESS WRITTEN CONSENT, INCLUDING AN EXPRESS WAIVER OF THE TERMS OF THIS AGREEMENT.
320747-A
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Before you begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Text conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Hard-copy technical manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 How to get Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Getting Help from the Nortel Web site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Getting Help over the phone from a Nortel Solutions Center . . . . . . . . . . . . . . . . 24 Getting Help from a specialist by using an Express Routing Code . . . . . . . . . . . . 24 Getting Help through a Nortel distributor or reseller . . . . . . . . . . . . . . . . . . . . . . . 24
Chapter 1 Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
(Nortel) Metro Ethernet Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 (Nortel) Metro Ethernet Solutions overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Enhanced capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Enhanced Ring Resiliency Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 ESM 8668 Metro Ethernet Services Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 ESU ring port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 ESU standalone port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 ESM local (TLS) port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 ESM server port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Ethernet UNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 TDIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 One-to-one . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Many-to-one . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Prerequisites to creating a customer endpoint . . . . . . . . . . . . . . . . . . . . . . . . 34
6 Creating a customer endpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 SP VPN VLAN overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Optical Ethernet Layer 2 overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 TLS Frame Check Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 TLS multicast address for TDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 TLS IP header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 TLS header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Packet destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Multicast and broadcast traffic for any-to-any connection types . . . . . . . . . . . 40 ATM PVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 ATM PVC endpoint rules and limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 ATM module scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 ATM throughput performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 (Nortel) Metro Ethernet QoS Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Device descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Multicast Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Metro Ethernet Passport 8600 Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Access connection types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Direct-access mode connection types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Ring-access node connection type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Dual home ring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Virtual LACP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Metro Ethernet Passport 8600 repeater function . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Ethernet UNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Multi Service Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 TLS-transparent UNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 TLS-switched UNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 TLS switched q-tag classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 VLAN remapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Many-to-one . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 QinQ(1) UNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 QinQ(2) UNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Connection types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Point-to-point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 320747-A
7 Point-to-multipoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Any-to-any . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 TD continuity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Multiple spanning tree protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Interoperability with legacy STP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Port roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Differences in port roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Master port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Edge port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Path cost values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Root forwarding port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Designated forwarding port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Alternate blocking port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Rapid convergent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Negotiation process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Regents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 RSTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 MSTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Chapter 2 Triple Play Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Triple Play overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Customer premise topology (ESU ring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Access network topology (local) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Ring protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Ring topology protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Ring resiliency protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Traffic types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Tagged and untagged traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Traffic direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 IP subnet and VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 ESU ring topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Access network topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 IP address spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
8 IP multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Metro 8600 IGMP (Level 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 IGMP Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 IGMP host membership reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 IGMP queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Metro Ethernet Passport 8600 as a multicast router . . . . . . . . . . . . . . . . . . . 102 Host leave messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 IP multicast in the ESU ring topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 ESU as an IGMP proxy/snoop device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Fast-leave feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 IP Multicast Routing service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Protocol-independent multicast-sparse mode (PIM-SM) . . . . . . . . . . . . . . . 104 Protocol-independent multicast-source specific multicast (PIM-SSM) on the ring ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 SSM and IGMPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 SSM and IGMPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Packet replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 IP multicast in the access-network topology . . . . . . . . . . . . . . . . . . . . . . . . . 107 IP-based services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 IP-based services in the ESU ring topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Metro Ethernet Passport 8600 as an IP router . . . . . . . . . . . . . . . . . . . . . . . 108 ESU in mux/demux mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 ARP broadcast in the ESU ring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 IP address learning on the Metro Ethernet Passport 8600 . . . . . . . . . . . . . . 111 DHCP and BootP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 IP-based services in the access-network topology . . . . . . . . . . . . . . . . . . . . . . . 112 Metro Ethernet Passport 8600 as an IP router . . . . . . . . . . . . . . . . . . . . . . . 112 ARP broadcast in the access-network topology . . . . . . . . . . . . . . . . . . . . . . 113 IP address learning on the Metro Ethernet Passport 8600 . . . . . . . . . . . . . . 113 DHCP and BootP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 QoS support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 IGMP access control list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Policing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
320747-A
9 IP aging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 IP multicast processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Existing support for IP multicast in the Metro Ethernet Passport 8600 . . . . . . . . 115
Chapter 3 Configuration considerations and limitations . . . . . . . . . . . . . . . . . . . . . 117

Metro Ethernet Services configuration rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Mapped NNI VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 SP IP VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 User-to-network interface (UNI ID) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Switch UNI ID address range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 UNI configuration rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 UNI QinQ configuration rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 UNI customer IP VLAN rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Transparent domain ID (TDI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Rules for TDIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 TDI mux mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 BPDU forwarding feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Endpoints default COS profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Q-tag 4096 - default VLAN for TLS-switched UNI . . . . . . . . . . . . . . . . . . . . . 136 Hub and spoke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Local switching endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Destination MAC table size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 NNI ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Static destination UNIs and endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Predefining static UNIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Any-to-any static destination tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 UNI-MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Destination-UNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 User-MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Static destination UNI and ring access ports . . . . . . . . . . . . . . . . . . . . . . . . 144 Point-to-point UNIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Configuring a remote UNI ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Remote MAC address rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
10 Defining a remote MAC address for a remote UNI . . . . . . . . . . . . . . . . . . . . 146 Legacy access port and services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 ESM server port (new port-type) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Legacy access port setup and rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Legacy access ports and spanning tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 MAC aging for legacy access ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Managing the Metro Ethernet switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Edge-device management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Out-of-band L2 VPN management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Metro ESU port rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Valid UNI port numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 Ring port connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 IP management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 Standalone configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 Metro Ethernet Passport 8600 Switch QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Metro Ethernet services configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 General QoS rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Metro Ethernet services DiffService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 802.1q p-bit override option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Override disabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Override enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Override option for QinQ ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 TLS-priority override attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Metro 8600 QoS mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Endpoint priority mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 QoS remapping on egress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 ESU default mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Metro ESU QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Metro ESU egress queueing for untagged packets . . . . . . . . . . . . . . . . . . . . . . . 162 Metro Ethernet Switch policing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Summary of policing enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Metro Ethernet Switch policier functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Configurable token buckets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Policing rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Classification rules for policing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 320747-A
11 Default policing values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Changing profile settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Rate setting rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 COS level burst rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 IP address spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Troubleshooting with TD continuity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Diagnosing problems using TDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Testing options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Round-trip time option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Priority option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Flooding (multicast)/unicast option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Limits and rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Enhanced RRP considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 VLACP considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Chapter 4 Configuring the Metro Ethernet Passport 8600 Switch using Device Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Configuring TD continuity testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Running a currently configured TDC test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 Displaying test history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 Configuring a new TDC test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Configuring an ESU Ring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Displaying ESU ring RRP statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Displaying ESU ring RDP statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Configuring a Dual Home ring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Displaying ESU Dual Home ring RRP statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 Displaying ESU Dual Home ring RDP statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Displaying ESU ring records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Displaying ESU ring port states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Configuring ESU standalone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Configuring a class of service profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 Configuring a user-to-network interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Configuring a UNI MAC address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Configuring transparent domain identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
12 Configuring a general TDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Displaying TDI statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Configuring a destination UNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Configuring a TDI endpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Displaying TDI endpoint statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Configuring a TDs User MAC address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Displaying Metro ESM 8668 server-port statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Displaying current Metro ESM 8668 information . . . . . . . . . . . . . . . . . . . . . . . . . 245 Displaying ESM port statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Displaying ESM port statistics for the last 15 minutes . . . . . . . . . . . . . . . . . . . . . 248 Displaying ESM port statistics for the last hour . . . . . . . . . . . . . . . . . . . . . . . . . . 249 Displaying daily ESM port statistics for all ports . . . . . . . . . . . . . . . . . . . . . . . . . 250 Clearing ESM port statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Configuring the Metro Ethernet Passport 8600 repeater feature . . . . . . . . . . . . . . . . 252 Configuring a UNI Customer IP VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Creating an SP VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 Configuring a Customer IP VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Showing UNI IP Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Configuring a VLAN TLS-IPMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 Configuring a VLACP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
320747-A
13
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 Figure 29 (Nortel) Metro Ethernet Solutions example . . . . . . . . . . . . . . . . . . . . . . . 27 VPN VLAN example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 OEL2 frame header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 TLS IP header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 TLS header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Locally switching two ATM PVCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Two PVCs located on different ELANs . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Supporting multiple PVCs on the same ATM port . . . . . . . . . . . . . . . . . . 44 Optical Ethernet QoS solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Direct access (local access) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Direct access (local server) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Ethernet access ring example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Dual home rings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Regenerating MAC traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 TLS transparent UNI example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 TLS switched UNI example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 TLS switched q-tag example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 VLAN remapping example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Many-to-one classification example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 QinQ(1) service type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 QinQ(2) service type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Point-to-point service type example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Point-to-multipoint service type example . . . . . . . . . . . . . . . . . . . . . . . . . 71 Any-to-any service type example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Root Forwarding Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Designated Forwarding Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Alternate Blocking Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 MSTP example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Customer premise topology ESU ring . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Configuring the Metro Ethernet Passport 8600 Switch using Device Manager
14 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 Figure 43 Figure 44 Figure 45 Figure 46 Figure 47 Figure 48 Figure 49 Figure 50 Figure 51 Figure 52 Figure 53 Figure 54 Figure 55 Figure 56 Figure 57 Figure 58 Figure 59 Figure 60 Figure 61 Figure 62 Figure 63 320747-A Access network topology - local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Traffic types generic case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Traffic types different IP traffic on different IP subnets . . . . . . . . . . . . . . 97 Traffic types All IP traffic on the same IP subnet . . . . . . . . . . . . . . . . . . 97 Example IP multicast configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Tagged packet egressing from an ESU 1850 to the switch . . . . . . . . . . 109 ESU ring topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Tagged packet from the switch to the ESU . . . . . . . . . . . . . . . . . . . . . . . 111 Ethernet Access Rings and Mapped NNI VLANs example . . . . . . . . . . 120 Direct access local server example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 QinQ UNIs service interworking and rules . . . . . . . . . . . . . . . . . . . . . . . 125 Different customer IP-VLANs map to different SP-IP-VLANs . . . . . . . . . 128 Same customer IP-VLAN maps to different SP-IP-VLANs on different ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Same customer IP-VLAN maps to same SP-IP-VLANs on different ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 ESU Ring8668 ESM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 TDI types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 VLAN translation of the TLS-switched application . . . . . . . . . . . . . . . . . 134 TDC dialog boxTD Continuity tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 TD Continuity History dialog boxHistory tab . . . . . . . . . . . . . . . . . . . . 186 TDC, Insert TD Continuity dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 ESU_Ring dialog boxESU Ring dialog box . . . . . . . . . . . . . . . . . . . . . 194 ESU_Ring, Insert ESU Ring dialog box . . . . . . . . . . . . . . . . . . . . . . . . . 195 Statistics, RRPRing ID dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Statistics, RDPRing ID dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 ESU_DualHoming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 ESU_Dual Homing, Insert dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Ring Records tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Ring Port State tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 ESU_Standalone dialog boxESU Standalone tab . . . . . . . . . . . . . . . . 209 ESU_Standalone, Insert, ESU Standalone dialog box . . . . . . . . . . . . . . 210 COS dialog boxCOS Profile tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 COS, Insert COS Profile dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 UNI dialog box UNI tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 UNI, Insert UNI dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
15 Figure 64 Figure 65 Figure 66 Figure 67 Figure 68 Figure 69 Figure 70 Figure 71 Figure 72 Figure 73 Figure 74 Figure 75 Figure 76 Figure 77 Figure 78 Figure 79 Figure 80 Figure 81 Figure 82 Figure 83 Figure 84 Figure 85 Figure 86 Figure 87 Figure 88 Figure 89 UNI_Mac dialog box UNI Mac tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 TDI dialog boxGeneral tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Statistics, TLS TDI tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 TDI dialog boxDest UNI tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 TDI dialog box Endpoint tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 TDI, Insert Endpoint dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 Statistics, TLS Endpoint tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 TDI dialog box User MAC tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 ESM dialog boxESM tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 Stats dialog boxESM Statistics tab . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Stats: Last-15minutes dialog boxStatistics: Last15minutes tab . . . . . 248 Stats: Hour-Level dialog boxStatistics: Hour-Level tab . . . . . . . . . . . . 249 Statistics: Daily For All Ports tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 Clear Port Stats tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Repeater dialog boxRepeater tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 VLAN Basic tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 VLAN Insert Basic dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 VLAN Basic showing PortNumbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 VLAN UNI tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 VLAN Cust IP Vlan tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 UNI, Insert Cust IP Vlan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 VLAN UNI Cust IP Vlan showing details . . . . . . . . . . . . . . . . . . . . . . . . . 261 Statistics, UNI IP Services window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 VLAN Basic tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 MLT_VLACP dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 VLACP tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
16
320747-A
17
Tables
Table 1 Table 2 Table 3 Table 4 Table 5 Table 6 Table 7 Table 8 Table 9 Table 10 Table 11 Table 12 Table 13 Table 14 Table 15 Table 16 Table 17 Table 18 Table 19 Table 20 Table 21 Table 22 Table 23 Table 24 Table 25 Table 26 Table 27 RSTP Port states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Differences in port roles for STP and RSTP . . . . . . . . . . . . . . . . . . . . . . . 78 Recommended Path Cost Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 UNIs on a Metro Ethernet PP8600 summary table . . . . . . . . . . . . . . . . 123 Default priority mapping and queue assignments . . . . . . . . . . . . . . . . . . 158 Default ESM internal QoS to SP priority markings . . . . . . . . . . . . . . . . . 159 Passport 8600 default DSCP internal QoS to SP priority markings . . . . 160 VLAN 802.1p bit mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Default TB maximum values in kilobytes . . . . . . . . . . . . . . . . . . . . . . . . 167 Endpoint priority mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Egress statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 TD Continuity History field descriptions . . . . . . . . . . . . . . . . . . . . . . . . . 186 Error bitmask code descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 TDC, Insert TD Continuity dialog box fields . . . . . . . . . . . . . . . . . . . . . . 192 ESU Ring tab and Insert, ESU Ring dialog box field descriptions . . . . . 196 RRP StatisticsRing Id dialog box field descriptions . . . . . . . . . . . . . . . 198 RDP StatisticsRing Id field descriptions . . . . . . . . . . . . . . . . . . . . . . . 200 ESU Dual Homing tab and ESU_Dual Homing, Insert tab field descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Ring Records tab fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Ring Port State tab fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 ESU Standalone tab and Insert, ESU Standalone dialog box field descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 COS, Insert COS Profile dialog box field descriptions . . . . . . . . . . . . . . 214 UNI tab and UNI, Insert UNI dialog box field descriptions . . . . . . . . . . . 220 TDI, Insert General dialog box field descriptions . . . . . . . . . . . . . . . . . . 226 Statistics dialog box field descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Endpoint tab and TDI, Insert Endpoint dialog box field descriptions . . . 235 TDI, Insert User MAC dialog box field descriptions . . . . . . . . . . . . . . . . 242
18 Table 28 Table 29 Table 30 VLAN, Inset Basic dialog box field descriptions . . . . . . . . . . . . . . . . . . . 258 Cust IP Vlan tab and UNI, Insert Cust IP Vlan dialog box field descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 VLACP tab field descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
320747-A
19
Preface
This guide provides instructions for configuring the Nortel* Metro Ethernet Passport 8600 Switch as an aggregation device for Metro Ethernet Services. Note: If you upgrade your Passport 8600 Switch (release 4.x) with the Nortel Metro Ethernet Services 4.0 software image, the switch can operate as a Metro Ethernet aggregation device in the Metro Ethernet Network (MEN). The switch is thereafter referred to as the Metro Ethernet Passport 8600 Switch. For details about upgrading your Passport 8600 Switch (release 4.x), see Upgrading to Metro Ethernet Passport 8600 4.0 Software. This guide includes information for using the Device Manager graphical user interface (GUI) to configure and manage Metro Ethernet Services on the switch. To use the command line interface (CLI), see Configuring the Metro Ethernet Passport 8600 Switch using CLI. Two other key components are also discussed in this guide, which are used along with the Metro Ethernet Passport 8600 Switch to provide a full complement of Metro Ethernet Services: Nortel Metro Ethernet Services Unit 1800 (Metro ESU 1800) The Metro ESU 1800 is positioned as an access device in the Metro Ethernet Network (MEN). For more information about using the Metro ESU 1800, refer to the following publications: Configuring Ethernet VPN and IP VLAN Services using the CLI Configuring Layer 2 Switch Mode using the CLI Configuring Ethernet VPN and IP VLAN Services using Device Manager Configuring Layer 2 Switch Mode using Device Manager Metro ESU 1800 Concepts Getting Started with the Metro Ethernet Services Unit 1800 Software
20 Preface
Installing the Metro Ethernet Services Unit 1800 Nortel Metro Ethernet Services Unit 1850 (Metro ESU 1850) The Metro ESU 1850 is positioned as an access device in the Metro Ethernet Network (MEN). For more information about using the Metro ESU 1850, refer to the following publications: Installing the Metro Ethernet Services Unit 1850 Configuring the Metro Ethernet Services Unit 1850 using the CLI Configuring the Metro Ethernet Services Unit 1850 using Device Manager Getting Started with the Metro Ethernet Services Unit 1850 Software Nortel ESM 8668 Metro Ethernet Services Module 8668 (Metro ESM 8668) The Metro ESM 8668 provides service encapsulation for VPN-based services in the MEN. For more information about using the Metro ESM 8668, refer to the following publications: Installing and Maintaining the Metro Ethernet Passport 8000 Series Chassis Installing the Metro Ethernet Passport 8600 Modules Note: Nortel is constantly adding new models and features to existing product lines. Refer to your Release Notes or see your Nortel sales representative for other ESM models that may be available at a later time.
Before you begin

This guide is intended for network administrators with the following background: Basic knowledge of networks, Ethernet bridging, and IP routing Familiarity with networking concepts and terminology Basic knowledge of network topologies Experience with windowing systems or GUIs
320747-A
Preface 21
Organization
This guide has four chapters, one appendix, and an index:
To learn about: (Nortel) Metro Ethernet Solutions concepts and the role of the Metro Ethernet Passport 8600 Switch as an aggregation switch List of new features for this release. Triple Play concepts Go to: Chapter 1 Chapter 2
Important configuration limitations and interoperability issues that you should consider when configuring your Metro Ethernet Passport 8600 Switch Chapter 3 Using Device Manager to configure and manage Metro Ethernet Services on your Passport 8600 Switch Terms or acronyms The topics and subtopics in this guide, with cross-references to relevant information Chapter 4 Glossary Index
Text conventions
This guide uses the following text conventions: angle brackets (< >) 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
Indicates command names and options and text that you need to enter. Example: Use the dinfo command. Example: Enter show ip {alerts|routes}.
22 Preface
braces ({})
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 show ip {alerts|routes}, you must enter either show ip alerts or show ip routes, but not both. Indicate optional elements in syntax descriptions. Do not type the brackets when entering the command. Example: If the command syntax is show ip interfaces [-alerts], you can enter either show ip interfaces or
show ip interfaces -alerts.
brackets ([ ])
ellipsis points (. . . )
Indicate that you repeat the last element of the command as needed. Example: If the command syntax is
ethernet/2/1 [<parameter> <value>]... , you enter ethernet/2/1 and as many
parameter-value pairs as needed. italic text Indicates new terms, book titles, and variables in command syntax descriptions. Where a variable is two or more words, the words are connected by an underscore. Example: If the command syntax is show at <valid_route>, valid_route is one variable and you substitute one value for it. Indicates command syntax and system output, for example, prompts and system messages. Example: Set Trap Monitor Filters Shows menu paths. Example: Protocols > IP identifies the IP option on the Protocols menu. 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 show ip {alerts|routes}, you enter either show ip alerts or show ip routes, but not both.
plain Courier text
separator ( > )
vertical line ( | )
320747-A
Preface 23
Hard-copy technical manuals

You can print selected technical manuals and release notes free of charge, directly from the Internet. Go to the www.nortel.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 Adobe Systems at the www.adobe.com URL to download a free copy of the Adobe Acrobat Reader. Note: The list of related publications for this manual can be found in the release notes that came with your software.
How to get Help

This section explains how to get help for Nortel products and services.
Getting Help from the Nortel Web site

The best way to get technical support for Nortel products is from the Nortel Technical Support Web site: http://www.nortel.com/support This site provides quick access to software, documentation, bulletins, and tools to address issues with Nortel products. More specifically, the site enables you to: download software, documentation, and product bulletins search the Technical Support Web site and the Nortel Knowledge Base for answers to technical issues sign up for automatic notification of new software and documentation for Nortel equipment open and manage technical support cases
24 Preface
Getting Help over the phone from a Nortel Solutions Center

If you dont find the information you require on the Nortel Technical Support Web site, and have a Nortel support contract, you can also get help over the phone from a Nortel Solutions Center. In North America, call 1-800-4NORTEL (1-800-466-7835). Outside North America, go to the following Web site to obtain the phone number for your region: http://www.nortel.com/callus
Getting Help from a specialist by using an Express Routing Code

To access some Nortel Technical Solutions Centers, you can use an Express Routing Code (ERC) to quickly route your call to a specialist in your Nortel product or service. To locate the ERC for your product or service, go to: http://www.nortel.com/erc
Getting Help through a Nortel distributor or reseller

If you purchased a service contract for your Nortel product from a distributor or authorized reseller, contact the technical support staff for that distributor or reseller.
320747-A
25
Chapter 1 Concepts
This chapter provides a conceptual overview of the Metro Ethernet Passport 8600 Switch as an aggregation switch in the (Nortel) Metro Ethernet Solutions. The current solutions include Ethernet VPN, Triple Play, and IP-based services. See Chapter 2 for detailed information about the Triple Play and IP-based services solution.The role of an aggregation switch, which is normally located at the Service Provider (SP) Central Office, is to provide service encapsulation for Virtual Private Network (VPN)-based services. For configuration limitations and interoperability issues to consider when configuring your Metro Ethernet Passport 8600 Switch, refer to Chapter 3, Configuration considerations and limitations, on page 117. For information about configuring your switch using Device Manager, refer to Chapter 4, Configuring the Metro Ethernet Passport 8600 Switch using Device Manager, on page 181. For information about configuring your switch using the Command Line Interface (CLI), refer to Configuring the Metro Ethernet Passport 8600 Switch using CLI.
This chapter includes the following topics:

Topic (Nortel) Metro Ethernet Solutions (Nortel) Metro Ethernet QoS Solution Metro Ethernet Passport 8600 Switch Ethernet UNI Connection types TD continuity Multiple spanning tree protocol Page 26 45 49 59 68 74 75
26 Concepts
(Nortel) Metro Ethernet Solutions

The (Nortel) Metro Ethernet Solutions is based on a multi-layered network infrastructure that uses an Optical Ethernet Switching Solution (OESS). (Nortel) Metro Ethernet Solutions supports distributed and centralized Ethernet user-to-network interfaces (UNI) and is based on Ethernet MAC address encapsulation provided by the SP. This section includes the following topics: (Nortel) Metro Ethernet Solutions overview Enhanced capabilities on page 28 Enhanced Ring Resiliency Protocol on page 29 ESM 8668 Metro Ethernet Services Module on page 30 Ethernet UNI on page 31 TDIs on page 32 Endpoints on page 33 SP VPN VLAN overview on page 36 Optical Ethernet Layer 2 overview on page 37 ATM PVC on page 41
(Nortel) Metro Ethernet Solutions overview

The OESS network architecture allows an SP to build a scalable metro Ethernet network for the purposes of delivering Ethernet services for connectivity services (E-Line, E-LAN), and infrastructure services such as IP VPN and internet access, or Digital Subscriber Line Access Multiplexer (DSLAM) backhaul. The key element that makes OESS suitable for these purposes is its ability to define user-to-network Interfaces (UNI), transparent domains (TD), or VPN instances, endpoints (EP), and network-to-network interfaces (NNI). In addition, OESS leverages an SP encapsulation of all customer packets to allow scalable switching of traffic within the metro core, and enhanced security by hiding end customer MAC addresses from metro core switches. This encapsulation is called OEL2 (Optical Ethernet Layer 2) encapsulation and is sometimes referred to as a MAC-in-MAC encapsulation because the SP header consists of a full Ethernet
320747-A
Concepts 27
MAC header upon which metro core switches make their switching decisions. The OEL2 encapsulation scheme is a precursor to a Nortel proposed standard called Provider Backbone Bridging or 802.1ah. See the network concepts example in Figure 1.
Figure 1 (Nortel) Metro Ethernet Solutions example
NNI S1 OE Access ring S2 S3
OEL2 OEL2
OE Access ring MPLS
Service provider managed devices (CLE) Metro ESU 1800 Passport 8600 Layer 2 switches
Stacked-tag Q-in-Q or VLAN
BayStack 425 switches
Service provider unmanaged devices (CPE) generic L2/L3 switches
Q-in-Q or VLAN Legend Metro Ethernet Passport 8600 Switch Passport 8600 switch (No ESM 8668 installed) Generic switch
11243FA
Metro Ethernet Services Unit 1800 (Metro ESU 1800)
UNIs provide a clear demarcation point between the customer's network and the SPs network: an SP encapsulation is applied to packets arriving at a UNI to transport them over the SPs metro core. UNIs can support multiple services (through multiple instances of EPs), which allows an SP to offer greater value to an end customer through a single physical link.
28 Concepts
TDs allow the SP to create separate logical networks for different customers, so that all traffic is well contained with no possibility of one customer's traffic being received by another customer. EPs link TDs to UNIs to provide service endpoints. Each EP has its own parameters that define how packets are handled, so that multiple services on a single UNI can each receive its own unique and appropriate Quality of Service (QoS) treatment and connectivity configurations. This concept provides maximum flexibility for the SP to deliver multiple, distinct services to a customer through a single physical link. NNIs carry SP-encapsulated customer packets into the metro core. The SP encapsulation used in OESS has the same format as a standard tagged Ethernet frame, which allows the carrier to build out the metro core using standards-based Ethernet switching equipment. At edges of the metro core, devices must be aware of the SP-encapsulation scheme in order to remove the encapsulation and hand off pure customer packets back to a customer device through a UNI. Additional features such as Mapped NNI allow the metro core to be logically separated into zones to limit broadcast and multicast traffic, and allow for greater scalability of the metro core. All of these concepts are described in greater detail in the sections that follow. Currently, the following products are part of the OESS portfolio: Metro Ethernet Passport 8600 Metro Ethernet Services Metro Ethernet Services Module (ESM) 8668 Metro Ethernet Services Unit (ESU) 1800 Metro Ethernet Services Unit (ESU) 1850 Optical Metro 1000 Series (OM1200, OM1400, OM1450)
All of these products support the UNI, TD, and NNI concepts and are fully interoperable with each other.
Enhanced capabilities
(Nortel) Metro Ethernet Solutions provides the following enhanced capabilities:
320747-A
Customer separation End-to-end QoS
Concepts 29
Policing Scalability Easy-to-administer Ethernet infrastructure
(Nortel) Metro Ethernet Solutions operates within existing Ethernet access technologies: Virtual LAN Access Networks (VLAN tagging) Stacked VLANs (QinQ) Ethernet MAC address encapsulation (MAC-in-MAC, also known as OEL2)
Enhanced Ring Resiliency Protocol

Enhanced Ring Resiliency Protocol (RRP) provides a new level of failover protection for single-home ESU rings. Using Layer 2 signaling (RRP hello messages), enhanced RRP can prevent the single-home ring from failing for conditions such as a software or hardware failure on an ESU or ESM module. For example, RRP detects failure within a non-dark fiber optical transport mechanism. The Enhanced RRP hello feature is enabled on both the Metro Passport 8600 and the Metro ESUs within the ring. The ESU on the ring is responsible for sending RRP hello messages to detect an ESU neighbor failure. You can configure the time interval at which the ESU port transmits a hello message. If the ESU neighbor doesnt receive three consecutive hello message replies, the ESU notifies the Metro Passport 8600 that the ring is broken and identifies the location of the ring break. The Metro Passport 8600 maintains the RRP hello timers, and the ESU maintains the log files indicating when RRP hello messages have triggered a ring failure. See Metro ESU 1800 Concepts for more information on ESU rings. Caution: Enhanced RRP is not supported in dual home ring topologies. Avoid transport networks for ESU ring port connections. Only use native fiber connections between each ESU ring port. ESUs in dual home ring configurations rely on link state changes to detect ring failure. If the transport network does not support end-to-end link state conditions, a failure within the transport network can result in the loss of customer data traffic as the ring can go down if a proper link states do not occur on the ESU ring ports.
30 Concepts
ESM 8668 Metro Ethernet Services Module

The ESM 8668 module enables carrier class Ethernet services with 8 Gigabit Ethernet (GE) ports that are SFP-based with a flexible Network Processor behind each port. Each of the Metro ESM 8668 ports can be configured as one of the following port types: ESU ring port ESU standalone port on page 30 ESM local (TLS) port on page 31 ESM server port on page 31
ESU ring port

An ESM port is called an ESU ring port when it is used to terminate an ESU ring. Each end of an ESU ring terminates on an ESM port one of the ESM ports is called the Primary ring port, and the other ESM port is called the Secondary ring port. Conceptually, UNIs are defined and linked to ports on the ESUs on the ring, which become the physical demarcation point to the customer. However, all the UNI functionality actually occurs at the Primary and Secondary ring ports. You can refer to the ESU ports as virtual UNIs. Refer to Metro ESU port rules on page 151 for more information about rings.
ESU standalone port

An ESM port is called an ESU standalone port when it is used to terminate a single ESU. Conceptually, UNIs are defined and linked to ports on the ESU, which become the physical demarcation point to the customer. However, all the UNI functionality actually occurs at the Primary and Secondary ring ports. You can refer to the ESU ports as virtual UNIs. Refer to Metro ESU port rules on page 151 on page 151 for more information about standalone connections.
320747-A
Concepts 31
ESM local (TLS) port

In this mode, UNIs are defined and linked to the physical ESM port. The ESM port itself is the physical demarcation point. This configuration also applies to the case where a Layer 2 switch is placed on the customer premise by the service provider and connected to the ESM with dark fiber. In this case the Layer 2 switch becomes the physical demarcation between the CPE and the service provider however the service still begins at the ESM. Refer to Ethernet UNI on page 31 for more information about demarcation points.
ESM server port

The ESM server port is a 3.6 feature and is not supported in this release. The commands remain for backwards compatibility for ESUs configured in a dual home ring.
Ethernet UNI
The Ethernet user-to-network interface (UNI) separates the customer environment from the SP environment, clearly delineating the point of responsibility between the SP network and the attached customer network. In this way, the Ethernet UNI securely isolates customer traffic and ensures data privacy across the shared Ethernet infrastructure. Ethernet UNI IDs define the location of a logical demarcation point. Each logical customer connection within the SP network has a unique ID, which uses an IP-notation numbering scheme. A UNI is linked to a physical port, which forms the physical demarcation point. A physical port can be a Metro ESU port attached to a ring; a Metro ESM 8668 port designated as a ESM local port; a standalone port connection through a Metro ESU that is configured in standalone mode; or a legacy port connection (such as a 10/100 switch port) that is designated as a legacy access port (no longer supported in Release 4.0). In the case of ESU access devices, the UNI functionality is defined on the ESM, however, the customer connection or physical demarcation is on the ESU. There is the concept of a virtual UNI on the ESU.
32 Concepts
In addition to defining the demarcation point, the Ethernet UNI defines the physical port's service type. There are four service types that used to identify and classify customer traffic (refer to Ethernet UNI on page 59 for information about supported service types). Each Ethernet UNI port requires a unique, 32-bit UNI ID address within the entire SP network domain (the UNI ID uniquely defines a physical demarcation point). Assign only one UNI ID for each physical Ethernet port.
TDIs
The Metro Ethernet Passport 8600 Switch allows SPs to configure, or provision, individual virtual private networks (VPNs) for each customer. The customers are assigned one, or more, transparent domain identification (TDI) number(s), which are used to transport the customer traffic between endpoints, within the same transparent domain (TDs). A TDI is equivalent to a VPN ID. A TD is a Metro Ethernet Forum (MEF) of Ethernet virtual circuit (EVC) or a VPN instance. Each TD supports multiple endpoints and endpoint connection types (such as, any-to-any, point-to-multipoint, and point-to-point). For more information about connection types, refer to Connection types on page 68. All unknown unicast, multicast, and broadcast traffic that belong to a given TDI travel as OEL2 multicast traffic within the associated transparent domain so that the packets can be replicated and broadcast to each endpoint (refer to Endpoints on page 33). Note: If you configure point-to-point endpoints and point-to-multipoint endpoints within a transparent domain (TD), you can significantly reduce the impact of unknown unicast, multicast, and broadcast traffic that exists within the TD. After a point-to-point connection learns the remote UNI ID, all unknown unicast, multicast, and broadcast traffic forwards only to the known destination UNI ID for the point-to-point connection. Transparent domains support two TDI Mux-modes: One-to-one, next Many-to-one on page 33
320747-A
Concepts 33
One-to-one
TDs defined as one-to-one (also known as, VLAN remapping domains) support endpoints with only one classification-type assignment (for example, a transparent or TLS-switched endpoint with only one q-tag assignment). If you assign the TDI endpoint as one-to-one, the customer VLAN q-tag remaps on egress, before exiting the endpoint.
Many-to-one
TDs defined as many-to-one support endpoints with one, or more, q-tags assignment(s) for traffic classification. On egress, endpoints with one or more q-tags assigned to many-to-one TDs do not remap the customer VLAN q-tag on egress. Note: Many-to-one classification applies only to Ethernet UNI ports defined as TLS-switched service types (refer to Ethernet UNI on page 59 for information about supported service types).
Endpoints
Endpoints designate the end users connection type, and receive assignment to a customer through the TDI. Endpoints classify and transfer customer traffic onto the customer-assigned TD. Endpoints also define QoS rules and apply policers to the customer traffic. An endpoint classification rule consists of an Ethernet UNI ID and a TDI. For endpoint assigned to Ethernet UNI ports with service type TLS-switched or QinQ, one or more q-tags are included in the classification rule. An endpoint connection type is similar to a virtual leased line (VLL). An endpoints connection type might define a point-to-point connection, a point-to-multipoint or even define a full mesh VLAN within the assigned TD, also known as any-to-any connection type. This remainder of this section describes how to create a customer endpoint and includes the following topics:
34 Concepts
Prerequisites to creating a customer endpoint, next Creating a customer endpoint on page 34
Prerequisites to creating a customer endpoint

To create a customer endpoint, you need to meet the following prerequisites: The SP NNI-mapped VLAN must be created, or known. A customer TDI must be assigned. The TDI must be defined as one-to-one or many-to-one mode. An Ethernet port-type for the customer connections must be known, and assigned as: ESU 1800 or 1850 port (through ESU-ring or ESU-standalone ports) If an ESU is connected to Ring, you must know the Ring ID and the MOD ID of the ESU switch. ESM local ports (ESM 8668 Gigabit port) Legacy access port (Passport 8600 legacy port, such as 10/100 ports) A UNI ID must be known, or created with the appropriate service type: TLS-Switched TLS-Transparent QinQ(1) QinQ(2)
Creating a customer endpoint

This section assumes the mapped NNI, mapped VLAN, and designated NNI ports are in place: 1 Create the Ethernet UNI port: a Create a unique 32-bit UNI ID, using IP address notation.
320747-A
Concepts 35
Assign a service type, as required. Note: If the service type is QinQ(1) or QinQ(2), the default ethertype number is 0x8020. If the SPs QinQ service uses a different ethertype number (other than the default shown here), you must change the ethertype on the ESM port to match the SP network for QinQ.
Assign one of the following port types: Metro ESM 8668 port Ring info, or standalone port information
d 2
Enable the Ethernet UNI ID.
Create the customer TDI: a b c d Create a unique transparent-domain ID for the customer. Define the TDI type as one-to-one or many-to-one. Assign the SPs mapped NNI VLAN ID. Enable the TDI.
Create the customer endpoint: a b Assign the Ethernet UNI ID to the TDI (this is the port UNI ID that the customer physically connects to, within the SP network). Define the connection type: If the connection type is point-to-point or spoke, define the remote UNI ID (the destination MAC address is optional). c d e f g Apply the desired COS profile for policing of traffic. Add q-tags if the Ethernet UNI port is QinQ(2) or TLS-switched. If the Ethernet UNI port is QinQ, add outer q-tag. Define and set optional QoS parameters, such as priority mapping and p-bit override. Define and set optional MAC table size, MAC table watermarks and MAC aging timers. Enable the customer endpoint.
36 Concepts
SP VPN VLAN overview

NNI ports on the Metro Ethernet Passport 8600 Switch legacy ports provide connectivity between the switch and the rest of the SP network (see Figure 2).
Figure 2 VPN VLAN example
Seattle
Service provider Ethernet tunnel (VLAN 10) Customer Qtags V4, V5
Blue network TDI 1
Service provider Ethernet tunnel (VLANs 10, 20)
Customer Qtags V4, V5
Boston 1
Branch
TDI 2
TDI 1 TDI 2
Red network
TDI 3
Data center
TDI 3
Branch
Customer Qtag V6 Service provider Ethernet tunnel (VLAN 20)
Boston 2
Customer Qtag V6
San Francisco
Legend Metro Ethernet Passport 8600 Switch Customer premise equipment (CPE)

11244FA
As shown in Figure 2, the customer network is never connected to the NNI port; therefore, NNI ports cannot be configured to provide VLAN bridging and routing services between customer and SP networks. NNI ports can be assigned IP addresses for management purposes, but the IP addresses are not required for VPN-type services. NNI ports can also comprise multiple ports for resiliency, and to separate TDI domains between metro environments. Conceptually, the TDs are mapped to the SP VPN VLAN for transport purposes between the two NNI ports (for example, the trunks within the Ethernet network).
320747-A
Concepts 37
Optical Ethernet Layer 2 overview

The Metro Ethernet Passport 8600 Switch encapsulates the user data packet with an Optical Ethernet Layer 2 (OEL2) header. OEL2 is the precursor to Nortel's proposed 802.1ah standard. The transparent LAN service (TLS) OEL2 header is prepended to the user data packet and consists of the following three parts: TLS Layer 2 header TLS IP header TLS header
The OEL2 header components are discussed in this section, which includes the following topics: TLS Frame Check Sequence, next TLS multicast address for TDI on page 38 TLS IP header on page 38 TLS header on page 39 Packet destination on page 39 Multicast and broadcast traffic for any-to-any connection types on page 40
TLS Frame Check Sequence

The Frame Check Sequence (FCS) is appended to the original user data packet. This TLS FCS replaces the existing FCS section on the original user data packet. As shown in Figure 3, the total length of the entire OEL2 header is 44 bytes plus 4 bytes for TLS FCS.
Figure 3 OEL2 frame header
DA SA Mapped Type NNI tag length
4 Bytes 2 Bytes
TLS header IP
TLS header
Data customer packet

~~~
TLS FCS
6 Bytes
6 Bytes
20 Bytes
6 Bytes
4 Bytes
11245EA
The destination address (DA) is the MAC address is the next hop MAC address to the destination UNI port (the remote endpoint of the network).
38 Concepts
If the end-user MAC DA is known, the forwarding database (FDB) for the local endpoint matches the DA to the destination UNI port. The FDB of the Metro Ethernet Passport 8600 Switch ESM ports dynamically updates the association among the end-user MAC DA and the remote destination UNI ID address for a given TDI.
TLS multicast address for TDI

If the end user MAC DA is unknown, the Metro Ethernet Passport 8600 Switch uses a broadcast or multicast MAC address that is derived from the TDI value. The TDI is 24 bits. To derive a multicast MAC address from the assigned TDI, the most significant bit is ignored and the least significant 23 bits of the TDI are placed into the lower order three bytes of the MAC address. For example, a TDI of 8253 is converted into hexadecimal and placed into the destination MAC address as 01-00-5E-00-20-3D.
TLS IP header
There is a one-to-one mapping between the SP IEEE 802.1p value and the class selector DSCP of the TLS IP header. The IP Source is the IP address (the UNI ID) assigned to the specific UNI port from which the user data packet entered the Metro Ethernet Passport 8600 Switch port. The IP destination is determined from the FDB for the given end-user MAC DA and TDI (see Figure 4).
Figure 4 TLS IP header
TLS L2 DSCP/TOS IP source IP destination TLS header Data customer packet TLS FCS
11246EA
Known customer destination MAC addresses use the IP destination address (the destination UNI ID) associated with the endpoint MAC address FDB. The system maps unknown unicast, broadcast, and multicast traffic to a multicast IP address based on the TDI. To convert to an IP multicast address, the system splits the 24-bit TDI value into three bytes, converts these three bytes into dotted-decimal notation, and uses the resultant values to fill in the last three portions of the destination IP multicast address.
320747-A
Concepts 39
For example, the TDI 8253, when broken into three bits and put into dotted-decimal notation yields the values of 0, 32, and 61. Thus, the TDI value of 8253 becomes the multicast IP address of 234.0.32.61.
TLS header
The TLS header TDI field is 24 bits (see Figure 5.) The TDI field is from the user-configure TDI associated with the specific transparent service type UNI port of the Metro Ethernet Passport 8600 Switch that received the user data packet.
Figure 5 TLS header
TLS L2 TLS IP header TLS version TLS flags Reserved TDI Data customer packet TLS FCS
11247EA
When the UNI port is configured as service type TLS-Switched, the TDI is associated with the UNI endpoint based on the customer packets q-tag (VLAN ID). Therefore, when a user data packet enters a TLS-Switched service type UNI port, the system maps the configured VLAN to its associated TDI and places that TDI in the TDI field of the TLS header. The end-user configures UNI IDs and then configures a TDI that is global to the chassis. UNI endpoints are then assigned to the TDI. Note: If an untagged packet enters a UNI endpoint, which is configured as a TLS-Switched service type, the untagged packet is discarded unless you configure the endpoint to classify on a q-tag of 4096.
Packet destination
After the customer data packet with the prepended OEL2 header traverses the network, it arrives at the destination UNI endpoint on the destination Metro Ethernet Passport 8600 Switch port. At this point, the system removes the OEL2 header from the user data packet, and the packet emerges as it originally entered at the source UNI port.
40 Concepts
The egress Metro Ethernet Passport 8600 Switch system directs the packet to the appropriate UNI port based on the received destination IP address (the destination UNI ID). Assuming that the egress UNI port is configured as a TLS-switched service type, and the TDI is one-to-one, then all customer frames egressing that endpoint (UNI ID, TDI) are tagged with the preconfigured endpoint-specific q-tag value. If the endpoint is assigned q-tag 4096, the customer's original 802.1q shim is removed prior to egressing the port as an untagged frame. If the customer packet was originally received untagged, and the TDI is one-to-one, an 802.1q shim is added to the customer packet with the VLAN ID assigned to the endpoint. Note: Q-tag 4096 is a special tag ID, for classifying untagged packets.
Multicast and broadcast traffic for any-to-any connection types

A multicast user packet is always multicast out of the Metro Ethernet Passport 8600 Switch, based on the TDI assignment at the receiving UNI port, and emerges at the endpoint UNI port exactly as it entered. Also, a broadcast user packet broadcasts from the receiving UNI endpoint based on the TDI and emerges exactly as it entered. Note: Connection types, defined with static-UNI IDs, transport multicast user packets using unicast OEL2 packets.
For more information about: Configuration rules for the (Nortel) Metro Ethernet Solutions Common terms used with the (Nortel) Metro Ethernet Solutions
See: Chapter 3, Configuration considerations and limitations, on page 117 TD continuity on page 74
320747-A
Concepts 41
ATM PVC
Overview
At the access side, a PVC can be considered as a single customer access port. During provisioning PVCs are associated with VLANs. A PVC that is providing new services is associated with a unique VLAN on the Metro Ethernet Passport 8600. This VLAN association with the PVC is defined as the q-tag for the endpoint. Note: A PVC that is used to provide new VPN based services is not bridged directly to another ATM PVC or with another legacy port. With release Release 3.6, it is possible to terminate PVCs on VPN-based endpoints. Standard port association and q-tag classification is used. When you create a UNI for a PVC, you assign both the ATM port to the ELAN. Then, assign the ATM port to the UNI port attribute, assign the ESM server port and define the service type as TLS-switched. Note: Only TLS-switched service type is supported for ATM PVC UNIs.
ATM PVC endpoint rules and limitations

Every VPN-based PVC must have a unique VLAN or ELAN ID. In network environments where two PVCs terminate into the same ELAN, the traffic will be bridged between each PVC, bypassing the ESM server port for VPN classification. For this release, in network environments where two or more PVCs terminate at the same ELAN, you can now configure multiple PVCs from different ATM ports. The ATM ports can be within the same ELAN and each PVC can be considered an endpoint. To locally switch two ATM PVCs as any-to-any within a customer TDI (VPN), each PVC must be on a separate physical ATM port, as shown in Figure 6 on page 42.
42 Concepts Figure 6 Locally switching two ATM PVCs

ATM Port and UNI Port ELAN end-point ESM Server Port TDI 100 end-point ATM UNI ID A
Provisioned VLAN 100
A2AA
PVC ID PVC ID
ELAN ELAN
Provisioned VLAN ID 200
ATM UNI ID B A2AD A2AE PVC ID PVC ID ELAN ELAN

PVC ID
ELAN
Switch Fabric TDI 100 end-point
Figure 7 on page 43 shows an invalid configuration scenario where two PVCs on different ELANs attempt to locally switch from the same ATM port.
320747-A
Concepts 43 Figure 7 Two PVCs located on different ELANs

Provisioned VLAN/ELAN ID 100
A2AA A2AB
PVC ID PVC ID
ELAN ELAN
ATM UNI ID C
Provisioned VLAN/ELAN ID 200 Per aTM Rules, Local switching not allowed between PVS's on same ATM port.
TDI 100 end-point A2AD A2AE PVC ID PVC ID ELAN ELAN

TDI 200 ATM UNI ID B Switch Fabric
TDI 200 ATM UNI ID D
Note: Local switching for PVC attached to the same ELAN is not supported. However, it is possible to support multiple PVCs on the same ATM port in a point-to-multipoint environment where the ATM PVC endpoints are designated as spokes, as shown in Figure 8 on page 44.
44 Concepts
Figure 8 Supporting multiple PVCs on the same ATM port

Spoke A Spoke B
PVC ID PVC ID
ELAN ELAN
ATM UNI ID C
TDI 100 end-point PVC ID Hub E PVC ID ELAN ELAN

TDI 200 ATM UNI ID B Switch Fabric
TDI 200 ATM UNI ID D
Note: Multiple PVCs on the same ATM port must be configured as spokes when assigned to the same TDI.
ATM module scalability

The maximum number of Passport 8672 modules supported per chassis is as follows: In a 10-slot chassis, 6 modules In a 6-slot chassis, 3 modules
The maximum supported non-VPN based ELANs, PVCs, and VLANs are as follows (per Release 3.6 design guidelines): 256 ELANs per MDA, 512 ELANs per module 256 PVCs per ATM MDA, 512 PVCs per module 64 PVCs per ELAN Note: Scaling numbers for VPN activated PVCs is not available for release 3.6.
320747-A
Concepts 45
ATM throughput performance

The Passport 8672 ATM interface exhibits throughput of less than 50% of link bandwidth when handling a continuous stream of small packet sizes (less than 512 bytes). However, variations may occur in a more realistic network scenario; that is, in those instances where the traffic stream comprises different packet sizes with large packet sizes contributing more to the link bandwidth than the small packet sizes. In such instances, the Passport 8672 ATM interface throughput may demonstrate throughputs close to line rate.
(Nortel) Metro Ethernet QoS Solution

The (Nortel) Metro Ethernet Solutions QoS solution (see Figure 9 on page 47) comprises the following devices: The Metro Ethernet Passport 8600 Switch, positioned as an aggregation switch. SP-managed devices (edge devices): Metro Ethernet Service Unit Passport 8600 Switch (with no Metro ESM 8668 installed) as a Layer 2 Transport switch. BayStack 4xx series switches. Any switch, router or CLE device that is manageable through SNMP and IP services.
This section includes the following topics: Device descriptions, next Multicast Rate Limiting on page 48
Device descriptions
As shown in Figure 9 on page 47, each of these devices plays a different role in the overall QoS solution. The (Nortel) Metro Ethernet Solutions QoS solution incorporates two QoS network domains, in one network: the customer network is in one domain, while the SP network is the VPN domain. The customer network
46 Concepts
queues on customer p-bits and TOS bits, whereas the OEL2 SPVID p-bits (or TOS bits) in the SP network, are used to determine per-hop behavior (note that, as shown in Figure 9 on page 47, the customer DiffServ environment overlaps the Metro Ethernet Service Unit). The Metro ESU can trust or remark the customer p-bits as required. The remarking of the p-bits is permanent, and when the customer packet egresses the VPN, the new markings are still present (refer to Metro 8600 QoS mapping on page 157 for known limitations). When a customer packet enters the Metro Ethernet Passport 8600 Switch, the customer packet QoS tag determines the SLA for the SP network. When the Metro Ethernet Passport 8600 Switch receives the customer packet, the entire packet, including the QoS tags, is encapsulated into an OEL2 Layer 2 packet type, which is then forwarded to the packets intended destination UNI. Note: For endpoints defined as QinQ, the SP tag (outer tag) is used to map the OEL2 QoS settings, not the original Customer QoS settings encapsulated in the QinQ tag (refer to Metro 8600 QoS mapping on page 157, for exceptions and QinQ configuration rules).
320747-A
Concepts 47 Figure 9 Optical Ethernet QoS solution

Customer QoS with optional remarking Service provider OEL2 SPVID remarking Service provider OEL2 SPVID remarking Customer QoS with optional remarking
Service provider network and DiffServ access point
Customer DiffServ access point

Legend Metro Ethernet Passport 8600 Switch Passport 8600 switch (No ESM 8668 installed) Generic switch Metro Ethernet Services Unit 1800 (Metro ESU 1800) OPTera Metro 8000 switch OPTera Metro 1200
11262FA
Each of the ingress endpoints has a default profile mapping that defines the SPVID p-bits and TOS bits. After classification and OEL2 encapsulation, the customer QoS setting numerical value (or QinQ setting) is matched to a QoS value defined in the profile mapping (refer to Metro 8600 QoS mapping on page 157, for more information).
48 Concepts
For (Nortel) Metro Ethernet Solutions where no edge device is used (for example, when you are using an endpoint assigned to a Metro ESM 8668 ESM Local Port), the following rules apply: Data packets that enter the network through local access ports are considered to be properly marked (customer QoS marking is trusted). The markings translate to a service priority mapping that is defined for the endpoint. By default, 802.1q p-bits map service priority level. Use 802.1q override for customer TOS bits to OEL2 QoS mapping (refer to 802.1q p-bit override option on page 155, for limitations and configuration rules). Service priority mapping is controlled per endpoint.
Multicast Rate Limiting

With Multicast Rate Limiting, you can assign a rate limit to any endpoint to control the forwarding rate of ingress multicast, broadcast and unknown unicast traffic. Ingress traffic is defined as data flow from the access (user) side of the network to the core. If the limit is reached, all frames received that exceed the limit are dropped. This feature is useful for suppressing potential multicast or broadcast storms. This feature is disabled by default, which means no multicast, broadcast or unicast data traffic, traverses the ingress path to the core of the network. The default rate is set to 1Gbps of data traffic for each endpoint, and the default unit is set to 1000. This means that if the multicast rate limit feature is enabled without any other change, the default late limit is 1 Gbps of data (1 Mbps x 1000 = 1Gbps) for each UNI or TDI. The network administrator must know and understand the impact of QoS and the COS profile before enabling this feature. The multicast rate limiting feature abides by the QoS rules. If the standard PIR is set to a lower limit than the multicast rate limit, the lower rate is used. To configure Multicast Rate Limiting, go to Configuring a class of service profile on page 212.
320747-A
Concepts 49
Metro Ethernet Passport 8600 Switch

This section describes some important (Nortel) Metro Ethernet Solutions-related Metro Ethernet Passport 8600 Switch feature concepts. This section includes the following topics: Access connection types, next Virtual LACP on page 57 Metro Ethernet Passport 8600 repeater function on page 57
Access connection types

The Metro Ethernet Passport 8600 Switch aggregates multiple customer services (using SP encapsulation from within the SP central office or at a customer premise site), which comprise the following access connection types: Direct-access mode connection types, next Ring-access node connection type on page 52 Dual home ring on page 53
Direct-access mode connection types

You can use the direct-access mode where the carrier located equipment (CLE) or customer premise equipment (CPE) is a single trunk, attached to a local-access port or legacy access port. There are two direct-access connection types: Local access, next Local server on page 51
Local access
Local-access connections are ports that are defined as ESM local ports (see Figure 10 on page 50). CLE and CPE devices are directly attached to the Metro ESM 8668 ports. Local-access connections comprise one UNI ID per Metro ESM 8668 port.
50 Concepts
Local-access connections support the following customer services: SP managed CLE (GE-to-GE) with Metro ESU 1850 in standalone mux tag node. SP managed CLE with Layer 2 device, with untagged or tagged VLAN packets. Unmanaged dedicated CPE with Layer 2 devices, with untagged or tagged VLAN packets.
Figure 10 Direct access (local access)
Direct access CLE device Metro Ethernet Services Unit 1800 (Metro ESU 1800)
Metro Ethernet Passport 8600 Switch (chassis view)
MLT 1
UNI
Direct access CPE device

BayStack 450-24T Switch or Metro ESU 1800 in Layer 2 Switch mode
UNI
Passport 86xx legacy modules or R modules as NNI Metro ESM 8668
11248EA
320747-A
Concepts 51
Local server
Local-server connections are Metro ESM 8668 ports that share customer access connections through Passport 8600 legacy ports such as the Passport 8608 and Passport 8648 modules (see Figure 11). Legacy access ports are assigned to server-enabled Metro ESM 8668 ports. The legacy access ports are assigned to default VLANs that tunnel customer traffic to the Metro ESM 8668 port. Multiple legacy ports can be assigned to one Metro ESM 8668 port, allowing the SP to spread customer connections across multiple 10/100 Ethernet ports or Gigabit Ethernet ports. Local server connections support the following customer services: SP managed CLE with Layer 2 device, with untagged or tagged VLAN packets through 10/100 Ethernet or Gigabit Ethernet legacy ports. Unmanaged dedicated CPE with Layer 2 devices, with untagged or tagged VLAN packets through 10/100 Ethernet or Gigabit Ethernet legacy ports.
Figure 11 Direct access (local server)

MLT 1
Dedicated Ethernet connection BayStack 450-24T switch
UNI
Passport 86xx Legacy modules Metro ESM 8668 Passport 86xx Legacy modules
11249EA
52 Concepts
Ring-access node connection type

Ring-access node is used with multiple Metro ESU device (SP managed CLE devices that are connected together to form a ring configuration). The ring connects to two separate Metro ESM 8668 ports that are defined as Primary and Secondary ring ports (see Figure 12). The ring-access node connection type supports a ring-resiliency protocol, which manages the ring, detects failures, and recovers and redirects traffic to avoid failed links within the ring. The Metro ESU serves as a CLE mux/demux device. As traffic ingresses the Metro ESU port, it performs policing and then forwards customer packets to the next Metro ESU within the ring until it reaches the Metro ESM 8668 module. For packets that egress the ring, the Metro ESM 8668 module determines the destination Metro ESU port, and forwards the packet onto the ring. Then, each Metro ESU on the ring compares the destination switch ID, embedded in the packet. If the IDs do not match, it forwards the packet to the next Metro ESU. Otherwise, it forwards the packet to the intended Metro ESU destination port, which resides in the Metro ESU switch, and stops forwarding the packet to the next Metro ESU.
Figure 12 Ethernet access ring example
Primary port Secondary port
MLT 1
Metro Ethernet Services Unit 1800 (Metro ESU 1800) (14 units, maximum allowed in ring)
Passport 86xx legacy modules Metro ESM 8668s

11250EA
320747-A
Concepts 53
Dual home ring

You can configure a dual home ring between two Metro Ethernet Passport 8600 Switches (see Figure 13 on page 54). Note: This feature has limited functionality and restrictions. Please refer to General Configuration Issues and Considerations in the 4.0 Release Notes. Each end of the ring terminates on one of the two switches (S1 and S2). The Primary ring port is on one switch, referred to as the Primary BAN, or BAN (P), while the Secondary ring port is on the other switch, referred to as the Secondary BAN, or BAN (S). As shown in Figure 13 on page 54, MLT 10 is an ESU ring trunk that must be configured between S1 and S2 before you configure the dual home ring between S1 and S2. The ESU ring trunk must be configured with a dedicated VLAN ID assignment. Note: CLI currently uses the older term for IBT (intra-BAN trunk) in place of ESU ring trunk.
54 Concepts Figure 13 Dual home rings
The assigned VLAN ID of the ESU ring trunk cannot be a member of other Layer 2 services, including mapped NNI services. The ESU ring trunk is either a single-link trunk, or part of an MLT group. In networks where the Metro Ethernet Passport 8600 Switch has multiple rings, each ring must be assigned a separate ESU ring trunk path. Therefore, each ESU ring trunk path must have a different VLAN ID. When you set up a dual home ring topology on your network, you must configure the feature on both the Primary and Secondary Metro Ethernet Passport 8600 Switches (for example, the Primary Metro [P] and Secondary [S] switches). In Figure 13 on page 54, S1 and S2 represent the Metro Ethernet Passport 8600 switches. You can arbitrarily choose either switch as the Primary or Secondary switch when you configure the switches.
320747-A
Concepts 55
Dual Home ring provides the Service Provider with enhanced ESU ring protection and NNI protection: Dual home ring protects the ESU ring against Metro Ethernet Passport 8600 nodal failure. When one of the two nodes fails, the ring transitions to a cut state and protects customer access. Dual home ring protects the Service Provider NNI trunk against Metro Ethernet Passport 8600 nodal failure. You can deploy and enable the Mapped NNI VLANs on each node. Spanning tree protects against service provider bridge loops when the services are normal. In the event one of the two nodes fail, spanning tree ensures the NNI traffic switches over to the remaining node and protect against NNI trunk failures. Note: ESU ring trunk VLAN must be on a direct point-to-point link between the Metro Ethernet Passport 8600 pair. No intermediate switches are allowed. Nortel recommends that you configure MLT on an NNI link and additionally you add parallel links to that link for load-sharing and failure. For Release 4.0, a unique set of commands allows you to configure the dual home ring. Each dual home ring configuration includes the following settings: Ring ID Ring name Discovery interval Ring port Ring port type (Primary or Secondary) Partner port MAC address IBT-MLT IBT port IBT VLAN Id Note: Each Metro ESU ring ID must be unique, regardless of the ring-type (regular ESU ring or dual home ESU ring).
56 Concepts
There is one ESU ring trunk per ring; the trunk passes all (ring) control messages between the Primary and the Secondary port. ESU ring trunk VLAN is like any VLAN can be on any legacy GE ports including MLT ports. Multiple ESU ring trunks can share the same physical link or MLT group. Differentiation is performed by the associated VID, for example MLT A -VID/10, MLT B - VID/20.
Considerations
The following considerations apply to dual-homing: Dedicated physical links can be required for ESU ring trunks handling important traffic, but local switching between multiple rings with dedicated ESU ring trunk links for each ring is not supported. Dual home rings cannot span across SMLT aggregation switches or operate with SMLT NNI uplinks. When using multiple ESU ring trunks to aggregate more traffic bandwidth, a spanning tree must be considered. Each ESU ring trunk must be in its own VLAN. VLANs are created and assigned to spanning tree groups. Each ESU ring trunk must be in a separate spanning tree group to separate the Layer 2 domains, or one ESU ring trunk is blocked, resulting in ring failure. To locally switch, SP VLAN must span both ESU ring trunks. However, since the SP VLAN is assigned to one STG group, one of the links is blocked, resulting in loss traffic between each ring. Rings are assigned peer-MAC addresses to define the destination Primary ring port. The peer-MAC is specifically associated with the MLT path, regardless of the fact the SP VLAN may span multiple virtual or physical links. Make sure STG for the MLT VLANs does not block either side of the MLT path or the rings will fail to come up or the rings will go down when a block occurs. Also, protect SP VLAN from STG blocking, or traffic forwarded from the Secondary Metro Ethernet Passport 8600 Switch to the Primary Metro Ethernet Passport 8600 Switch will be blocked. Nortel recommends that you configure the Primary Metro Ethernet Passport 8600 Switch to be the root bridge for all SP VLAN spanning tree groups.
320747-A
Concepts 57
If more than one ESU ring shares a single ESU ring trunk, then all the Primary ring ports should be on the same Metro Ethernet Passport 8600. Note: ESU management requires that the ESU management interface be configured through the Primary port node off the dual home ring.
TDC tests can only be imitated from the Primary dual home Metro Ethernet Passport 8600 Switch.
Virtual LACP
Virtual LACP is an extension to the Link Aggregation Control Protocol (LACP) that detects end-to-end failure. VLACP works only in a port-to-port scenario when there is a guarantee of a logical port-port match through service provider cloud. It does not work in a port-to-multiport scenario when there is no guaranteed point-point match through the service provider cloud. Note: On the Metro Ethernet 8600 CPU expansion mezzanine card, VLACP is only used on directly connected links.
Metro Ethernet Passport 8600 repeater function

The Metro Ethernet Passport 8600 Switch supports a repeater functionality that allows for MAC regeneration of data traffic over long-haul connections (see Figure 14 on page 58). MAC regeneration is supported on 8608GBIC Gigabit links using any supported GBIC interface (for example, 1000SX, 1000LX, 1000T, and so on.). All GBIC series modules are supported. Each repeater function comprises one pair of Gigabit ports, with a unique VLAN Id for each repeater. You can assign a total of 32 repeaters per chassis. See Installing SFP and XFP Transceivers and GBICs. As shown in Figure 14 on page 58, if the distance between S1 and S3 exceeds the maximum attenuation limits for your GBIC interface, you can configure the Metro Ethernet Passport 8600 repeater feature on S2 to regenerate the signal.
58 Concepts Figure 14 Regenerating MAC traffic
OE Access ring S1
Original signal
GBIC interface VLAN 8/1 8/2 S2 Maximum attenuation distance exceeded
Regenerated signal
S3
Legend OE Access ring Metro Ethernet Passport 8600 Switch
Metro ESU 1800

11350FA
320747-A
Concepts 59
Ethernet UNI
The Ethernet user-to-network-interface (UNI) is generally the demarcation between the customer network and the SP network. The UNI can be thought of as the entrance point into the Ethernet VPN it is at the UNI, where mapping occurs from the customer MAC domain into the SP MAC domain. Note: In the case of ESU access devices, the Ethernet UNI is defined on the ESM, but the customer connection is on the ESU. There is a concept of a virtual UNI on the ESU customer separation is achieved on ESU access links or rings through a separate multiplexing protocol between the ESM and the ESU. The UNI interface supports four service types: TLS-transparent UNI TLS-switched UNI QinQ (1) UNI QinQ (2) UNI
Multi Service Port

In this release, multi-service types are supported on the same ESM local port. Multiservice Port allows TLS switch QinQ1, and QinQ2 traffic to be forward through a common ESM 8668 port. The Multiservice Port allows many logical UNIs of the various service types to be associated with one ESM port. If you define a TLS transparent UNI, you cannot assign any other service type to that port. Note: For ESU access devices, each ESU UNI only supports one service type. Multi Services are not supported on ESU ports.
60 Concepts
The four UNI service types are: TLS-transparent UNI on page 60 TLS-switched UNI on page 61 QinQ(1) UNI on page 66 QinQ(2) UNI on page 67
The UNI service type defines how customer packets are mapped to one or more TDs. These service types are explained in the following sections. Note: The UNI service types do not have to be the same for all UNI endpoints that are part of a given TD. However, there are compatibility rules for certain combinations.
TLS-transparent UNI
When you configure a UNI ID as TLS-transparent service type, the UNI ID assigns all traffic to its associated transparent domain, based on the transparent domain identifier (TDI). A transparent UNI is similar to the IEEE802.1ad's port-based service interface. When configured for TLS-transparent service type, all traffic received from that UNI port is associated with one TD (see Figure 15 on page 61). Also, all traffic that enters the TLS-transparent service type UNI endpoints is associated with the same TDI, and all customer VLAN IDs, including untagged frames, are associated with that one TDI. Note: You can use TLS-transparent UNIs to interconnect customer networks that use stacked VLANs from one transparent UNI to another transparent UNI.
320747-A
Concepts 61 Figure 15 TLS transparent UNI example
customer
service provider
Customer VLAN 20 Customer VLAN 30 Customer Untagged traffic
TDI 101
UNI
TLS-switched UNI
When configured for TLS-switched service type, the UNI can assign traffic to various TDs based on the VLAN Ids of the customer packets. You can configure a one-to-one, or a many-to-one VLAN-to-TDI mapping relationship. When traffic enters a switched service type UNI port, the customer VLAN IDs are used to identify the UNI endpoints that are associated with the ingress port as shown in Figure 16. The same switched UNI ID can be associated with multiple TDs. Note: If an untagged packet enters a UNI port configured as a TLS-switched service type, that packet is considered to have a q-tag of 4096. Such packets are discarded unless you configure an endpoint with q-tag 4096.
Figure 16 TLS switched UNI example
TDI MUX Mode Customer VLAN 20 Customer VLAN 50 Customer VLAN 30 Customer Untagged traffic (4096)
Many to 1
customer
service provider
TDI 301
1:1
TDI 201 TDI 333
UNI
62 Concepts
The (Nortel) Metro Ethernet Solutions supports the following switched UNI types: TLS switched q-tag classification, next VLAN remapping on page 64 Many-to-one on page 65
TLS switched q-tag classification

This section provides a TLS-switched q-tag example (see Figure 17 on page 63). In this example, four endpoints are defined within the network: S1 has a UNI defined as service type TLS-switched. Two endpoints are assigned to the UNI, one for VLAN 10 and one for VLAN 20. Each endpoint is assigned to a different TDI: TDI 100 for the endpoint with q-tag VLAN 10, and TDI 200 for the endpoint with q-tag VLAN 20. S2 has one UNI defined as service type TLS-switched with one endpoint assigned to TDI 100. S3 has one UNI defined as service type TLS-switched with one endpoint assigned to TDI 200.
320747-A
Concepts 63 Figure 17 TLS switched q-tag example

TDI 100 VLAN 20 VLAN 10 S1 S2 VLAN 10 VLAN 10
VLAN 10
VLAN 20 TDI 200 VLAN 20 S3
VLAN 20
11252FA
As customer packets enter the UNI at S1, the UNI verifies the customer q-tag and hands-off the packet to the endpoint with the matching q-tag. The endpoint classification processes the packet (assigns QoS levels, meters and remarks per endpoint configuration) and forwards the packet to the intended destination UNI (for the TDI assignment within the SPs NNI network). On egress, if the endpoint is assigned to a UNI that is TLS-switched, the original customer packet is de-encapsulated and the VLAN q-tag is added to the packet on egress.
64 Concepts
VLAN remapping
TLS-switched service type UNIs use q-tags to classify and define endpoints that a physical port is using. The classified endpoints are then associated with specific TDIs. Note: A TLS-switched endpoint comprises a UNI ID, a TDI, and a VLAN ID. One-to-one TDIs support remapping of customer VLANs. All switched UNI endpoints remap the customer packet upon egress. When a packet egresses a TDI TLS-switched endpoint, the customer packet VLAN is remapped to be the same as the q-tag assignment for the endpoint (see Figure 18).
Figure 18 VLAN remapping example
TDI 200 VLAN 10 VLAN 10 VLAN 10
Traffic flow
VLAN 20
Qtag remapped
11253FA
320747-A
Concepts 65
Many-to-one
As shown in Figure 19, many-to-one is a special case where more that one q-tag can be associated with the same TLS-switched UNI endpoint.
Figure 19 Many-to-one classification example
Enterprise LAN
VLAN 100, 200, 300, 400 ( mapped to TDI 1020 )
Enterprise LAN
VLAN 200, 300, 400 VLAN 200, 300, 400
Provider OE "Bridge" network
TDI 1020 TDI 1020

Mapped NNI (VLAN) pipes VLAN 100
VLAN 100
TDI 1020
VLAN 100 Legend
Internet
Metro Ethernet Passport 8600 Switch Enterprise router Only VLAN 100 mapped to TDI 1020
Internet router
11254FA
66 Concepts
In this case, two or more q-tags are assigned to the same endpoint for traffic classification. Because endpoints can have multiple q-tag classifications, VLAN remapping is not supported for many-to-one. When a packet egresses a TDI endpoint where the TDI is defined as many-to-one, the customer q-tag must match one of the assigned q-tags for the endpoint or the packet is dropped.
QinQ(1) UNI
The QinQ(1) service type (see Figure 20) is a specific UNI-type, which uses an outer q-tag, provided by the SP, to classify and define the endpoint to use.
Figure 20 QinQ(1) service type
Stacked VLAN service provider
Service Provider VLAN 20, Any C-VID
TDI 900
UNI
Legend Service Provider Aggregation Switch Customer premise equipment (CPE)
When a customer sends packets into an SP domain, the SP can add a q-tag for further classification of this customer traffic. This SP q-tag is used to identify a service instance in the QinQ network. When the QinQ frame enters the Metro Ethernet Passport 8600 Switch, this SP q-tag is used to identify the TDI in the OEL2 domain. Note: QinQ(1) UNI types are not supported on ESU ports.
After the packet is classified, the SP q-tag is stripped from the customer packet, before it is forwarded into the core OEL2 network. For QinQ(1) classification, only the outer tag is used for classification, regardless of what the customer can, or can not have, added to their packets.
320747-A
Concepts 67
The selection of the TDI for a particular ingress frame is based on the frame outer-VLAN ID and the physical ingress port. For QinQ(1) endpoints assigned to the same physical port, each endpoint must have a unique outer-q-tag VID assigned for proper classification. Note: QinQ endpoints can not be assigned to TDI's where muxmode is many-to-one. QinQ(1) is useful where an OEL2 network is used as the interconnecting medium for QinQ islands (for example, handoff network configurations to an ISP). QinQ(1) UNI-types allow the SP to scale the interconnecting network as the 4K outer VLAN ID only has significance within each QinQ island. The OEL2 TDI acts as the network to translate provider VLAN IDs between various QinQ access network islands. It is also useful in scenarios where a long haul carrier wants to classify and consolidate all customer traffic from different local SPs. Note: QinQ(1) UNIs should not be provisioned with switched UNIs in the same TDI.
QinQ(2) UNI
The QinQ(2) service type (see Figure 21 on page 68) is a specific UNI-type that relies on two q-tags: an outer SP tag (added by SP prior to packet entering endpoint), and an inner customer q-tag for endpoint classification. In this case, all outer tags can be common (from a single local SP), but the inner tag provides for further classification (for example, to identify particular customer packets requiring different SLA levels). The combination of the outer AND inner tag determines which TDI the frame belongs to. Note: QinQ(2) UNIs should not be provisioned with transparent UNIs in the same TDI.
68 Concepts Figure 21 QinQ(2) service type

Stacked VLAN C-VIDs SP-VID
Service Provider VLAN 20, C-VID=100
service provider
TDI 555 TDI 555

Service Provider VLAN 20, C-VID=200
Legend Service Provider Aggregation Switch Customer premise equipment (CPE)
UNI
For QinQ(2), only two q-tags are supported on ingress into the TD domain; both are used for endpoint classifications. If the UNI type is QinQ(2), the inner tag must be assigned ethertype 8100, otherwise the packet drops on classification. Both, the inner and the outer tag combinations must be unique. All outer tags can be the same, as long as the inner tag is different for each endpoint classification within the TDI. This rule applies for the same inner tag, as long as the outer tag is different. Note: Many-to-one TDI mux-type is not supported with QinQ Service Types.
Connection types
The (Nortel) Metro Ethernet Solutions supports the following service types: Point-to-point, next Point-to-multipoint on page 71 Any-to-any on page 73
Point-to-point
Point-to-point VPNs are unique throughout the network and can have only one endpoint at each end of the VPN. As shown in Figure 22 on page 70, each point-to-point circuit has two unique end points. One advantage for point-to-point endpoints assigned to Metro ESU ports or to local TLS ports is the endpoints do
320747-A
Concepts 69
not learn the customer destination end-user MAC addresses. Only the remote UNI mac-addresses are learned on ESM 8668 based access ports (this includes ESU ring, ESU standalone, and local TLS ports). For legacy access ports, customer destination MAC learning is required on both the legacy port and associated ESM port to maintain continuity between the ESM ports and legacy access ports. Point-to-point UNIs within a transparent domain (TD) significantly reduces the impact of unknown unicast, multicast, and broadcast traffic that exists within the TD. After a point-to-point connection learns the remote UNI ID, all unknown unicast, multicast, and broadcast traffic is forwarded using unicast packet headers to the known destination UNI ID for the point-to-point connection. A point-to-point endpoint must have a remote UNI ID defined before enabling the endpoint. To change the remote UNI ID, disable the endpoint first. To remove the remote UNI ID, the delete the endpoint first. Note: These same rules apply to spoke connection types. You need to: 1 2 3 Configure both TDI endpoints connection type as point-to-point. Configure remote-UNI. Optionally configure the remote UNI MAC address as the UNI MAC address of the remote UNI.
Point-to-point and spoke connection types do not learn customer MAC entries. All circuits are assigned to the remote UNI ID defined when the endpoint is created. MAC aging, table size, and watermarks for the endpoint do not apply for point-to-point and spoke connection types. When assigning a remote UNI ID, the remote UNI MAC address provision is optional. If no address is defined, the OEL2 packet broadcasts using a multicast Layer 2 record, but the destination UNI field within the OEL2 record is the same as the remote UNI ID defined. Although the packet is broadcast throughout the network, the packets only forward out the ports that match the destination UNI in the OEL2 header. When the endpoint with the defined remote UNI responds, the local endpoint statically learns the remote UNI MAC address and uses the MAC address as the unicast destination MAC for the all packets forwarded to the defined remote UNI. Once the MAC address is learned, all learning is disabled and the MAC address for the remote UNI does not age.
70 Concepts Figure 22 Point-to-point service type example

Transparent domain multiplexing Multiple Ethernet Virtual Lease Line (VLL) connections TDI 1
Branch
Ethernet tunnel bridging
TDI 2
Ethernet tunnel bridge
Data center
Branch

11257FA
320747-A
Concepts 71
Point-to-multipoint
In a point-to-multipoint configuration, also known as a hub-and-spoke service, all the remote endpoints terminate at a central hub (see Figure 23). The hub is the central point of connectivity to all spokes (remote endpoints). Although a hub can have one or more spokes, no communications can take place between spokes.
Figure 23 Point-to-multipoint service type example
Branch (Spoke)
Single Ethernet Virtual Lease Line (VLL) connections
Single TDI domain
TDI 1
Branch (Spoke)
Data center (Hub)

Ethernet tunnel bridge (mapped NNI)
Branch (Spoke)
Legend Metro Ethernet Passport 8600 Switch
Customer premise equipment (CPE)

11258FA
72 Concepts
In a point-to-multipoint environment, only one hub is defined within the TDI. There is no limit to the number of spokes that can be configured for the TDI. Endpoints defined as spokes on Metro ESU and Local TLS ports do not learn customer destination MAC addresses, but the hub still learns all the remote customer destination end-user MAC addresses. For spokes assigned to legacy access ports, customer destination MAC learning is required on both the legacy port and associated ESM port to maintain continuity between the ESM ports and legacy access ports. To configure point-to-multipoint: 1 2 3 4 Configure hub sites TDI endpoint connection type as hub. Configure spoke sites TDI endpoint connection type as spoke. Configure remote-UNI to be hubs UNI ID at spoke endpoints. Optionally configure remote UNI MAC address as the hub sites UNI MAC address.
The point-to-multipoint MAC learning rules are: If the MAC address is not configured, the source MAC of the first received packet is learned as the remote end MAC. Until a MAC is learned, packets are multicast. Once learned, a learned UNI MAC does not age. Once learned, all packets from the spoke are unicast. No customer MAC address learning occurs at the spoke. Normal customer MAC address learning occurs at the hub, with MAC ageing. Multiple hubs (and any-to-any connections) within a point-to-multipoint. circuit with dynamic learning is not supported. There can only be one hub in a TDI domain; if a network environment has more than one hub, the spoke could become disjointed. A spoke does not verify remote UNI IDs on egress.
Example 1 - The spoke has already learned the correct remote hub MAC address for its specified remote UNI ID: If any other hub or any-to-any endpoint sends a packet to the spoke, the spoke forwards out the endpoint. If the device on spoke endpoint responds back to incorrect hub or any-to-any connection, it forwards to the remote UNI ID and MAC address learned by the spoke, not the originating endpoint.
320747-A
Concepts 73
Example 2 - The spoke is dynamically learning the remote hub MAC address and the incorrect hub or an any-to-any connection responds first: The spoke assumes this is the correct hub and learn and load its MAC address. All packets originating from the spoke are lost as packets are destined to the wrong remote hub MAC address with a destination UNI ID that does not exist on the assumed remote hub.
Any-to-any
With any-to-any services, all endpoints are configured for connectivity, which allows all endpoints to communicate within the same TDI (see Figure 24 on page 74.) There is no limit to the number of any-to-any endpoints within a TDI. To establish an any-to-any configuration, configure all TDI endpoint connection types as any-to-any. Some rules for any-to-any MAC learning are: Normal customer destination MAC address learning (according to the reverse path learning already seen in UNIT 2), with MAC aging. There is an independent destination MAC table per endpoint with an aging timer that can be set (300 seconds by default).
74 Concepts Figure 24 Any-to-any service type example

Single Ethernet virtual lease line connection
(Full mesh)
Branch Data center

Ethernet MAC bridging Ethernet MAC bridging
Branch Branch
Mapped NNI (VLAN tagged) Legend Metro Ethernet Passport 8600 Switch Metro Ethernet Services Unit 1800 (Metro ESU 1800) OE Access ring
11259FA
TD continuity
TD continuity (TDC) provides end-to-end data packet path validation per transparent domain (TD) in the SP networks. Using TDC, you can test the data flow from the Metro Passport 8600 Ethernet Switch through the SP network to another Metro Passport 8600 Ethernet Switch, or to a UNI on an OM1000 ESM module, or to a UNI or NNI interface on the OPTera Metro 3500 multiservices platform with the OPTera Packet Edge System. TDC end-to-end connectivity testing capability includes the following testing:
320747-A
Concepts 75
Path learning validation (multicast test) Path validation (unicast test) Data path round-trip delay
The Metro Ethernet Passport 8600 TDC testing includes: Test naming Test duration (one-time or periodic) SNMP-based configuration and traps Round-trip time Storage of test configurations in non-volatile memory Test history
See Chapter 1, Concepts, on page 25 for more information.
Multiple spanning tree protocol

The current IEEE 802.1d spanning tree standard provides loop protection and recovery, but it is slow to respond to a topology change in the network (for example, a dysfunctional link in a network). The Rapid Spanning Tree Protocol (RSTP or IEEE 802.1w) reduces the recovery time after a network breakdown. It also maintains a backward compatibility with the IEEE 802.1d, which is the legacy spanning tree implementation prior to RSTP. Typically, the recovery time of RSTP is less than one second. RSTP also reduces the amount of flooding in the network by enhancing the way the Topology Change Notification (TCN) packet generates. The Multiple Spanning Tree Protocol (MSTP or IEEE 802.1s) allows you to configure multiple instances of RSTP on the same switch. Each RSTP instance can include one or more VLANs. The operation of the MSTP is similar to the current Nortel proprietary Spanning Tree Group (STG), with the exception of faster recovery time. RSTP and MSTP enable the switch to achieve the following:
76 Concepts
Reduce converging time from 30 seconds to less than a second for most scenarios when there is topology change in the network (that is, a port going up or down). Eliminate unnecessary flushing of the MAC database and flooding of traffic to the network, with a new topology change mechanism. Backward compatibility with other switches that are running legacy 802.1d Spanning Tree Protocol (STP) or Nortel STG (STP group 1 only). Under MSTP mode, with the Passport 8600, you can configure 64 instances, of which only 25 can be active at one time. Instance 0 or CIST is the default group, which includes default VLAN 1. Instances 1 to 7 are called MSTIs 1-7. The user can configure the switch to run Nortel MSTP, RSTP, or default STP configuration.
Interoperability with legacy STP

RSTP provides a new parameter, ForceVersion, for backward compatibility with legacy STP. You can configure a port in either STP-compatible mode or RSTP mode. An STP compatible port transmits and receives only STP BPDU. Any RSTP BPDU that the port receives in this mode are discarded. An RSTP port transmits and receives only RSTP BPDU. If an RSTP port receives a STP BPDU it becomes an STP port. User intervention is required to bring this port back to RSTP mode. This process is called port protocol migration.
RSTP provides a faster convergence time than the traditional STP. RSTP is an evolution of the spanning tree protocol (802.1D standard) and provides for faster spanning tree convergence after a topology change. MSTP allows VLANs to be grouped into a spanning tree instance. This is the standardized evolution of the Nortel proprietary STG, which allows the building of networks with multiple spanning tree domains or STGs. This is important for resiliency (one failure in one domain does not impact other domains, as is the case for the regular spanning tree protocol), and provides other advantages, such as load-balancing.
320747-A
Concepts 77
MSTP is an IEEE standard that allows several VLANs to be mapped to a reduced number of spanning-tree instances. This is possible since most networks do not need more than a few logical topologies. Each instance handles multiple VLANs that share the same Layer 2 topology. The following is a summary of RSTP versus STP: STP convergence has similar results when a port or root bridge fails. STP timers modification has a significant impact on convergence time, reducing it from 32 to 10 seconds. RSTP is faster for port failure, but not for root bridge failure since it takes 2 to 28 seconds to recover. RSTP timer modification does not improve convergence for port failure, but it does improve for bridge failure. Recovery time takes from 2 to 7 seconds. RSTP is faster than STP, but not in all scenarios.
Port roles
The 802.1d terminology remains primarily the same as STP. The 802.1d is has four different port states: listening, learning, blocking, and forwarding. There are only three port states left in RSTP, corresponding to the three possible operational states: Discarding Learning Forwarding.
See Table 1, for more information.

Table 1 RSTP Port states
STP Port State Administrative MAC Bridge Port Operational State Disabled Enabled Enabled Enabled FALSE FALSE TRUE TRUE RSTP Port State Discarding Discarding Discarding Discarding Active Topology (Port Role) Excluded (Disabled) Excluded (Disabled) Excluded (Alternate, Backup) Included (Root, Designated)
DISABLED DISABLED BLOCKING LISTENING
78 Concepts Table 1 RSTP Port states (continued)

STP Port State Administrative MAC Bridge Port Operational State Enabled TRUE TRUE RSTP Port State Learning Forwarding Active Topology (Port Role) Included (Root, Designated) Included (Root, Designated)
LEARNING
FORWARDING Enabled
Differences in port roles

RSTP is an enhanced version of STP. These two protocols have almost the same set of parameters. Table 2 lists the differences in port roles for STP and RSTP. STP supports two port roles while RSTP supports four port roles.
Table 2 Differences in port roles for STP and RSTP
Port Role
Root Designated Alternate
STP
Yes Yes No
RSTP
Yes Yes Yes
Description
This port is receiving a better BPDU than its own and it has the best path to reach the root. Root port is in Forwarding state. This port has the best BPDU on the segment. Designated port is in forwarding state. This port is receiving a better BPDU than its own BPDU and there is a root port within the same switch. Alternate port is in discarding state. This port is receiving a better BPDU than its own BPDU and this BPDU is from another port from the same switch. Backup port is in discarding state.
Backup
No
Yes
Master port
The port role master is introduced for MSTIs for a port where the CIST port role is a root port and the spanning tree information received is from another MST region. An MSTI master port forms part of the stable active topology for frames allocated for that MSTI, just as the CIST root port forwards frames allocated to the CIST. The port state for each MSTI may differ for each MSTI as required to suppress temporary loops.
320747-A
Concepts 79
Edge port
Edge port is a new parameter supported by RSTP. When a port connects to a non-switch device such as a PC or a workstation, it must be configured as an edge port. An active edge port goes directly to forwarding state without any delay. An edge port becomes a non-edge port if it receives a BPDU. You can also manually configure the edge port.
Path cost values

RSTP and MSTP recommend new path cost values that support a wide range of link speeds. Table 3 lists the recommended path cost values.
Table 3 Recommended Path Cost Values
Link speed Less than or equal 100Kb/s 1 Mb/s 10 Mb/s 100 Mb/s 1 Gb/s 10 Gb/s 100 Gb/s 1 Tb/s 10 Tb/s Recommended value 200 000 000 20 000 000 2 000 000 200 000 20 000 2 000 200 20 2
Root forwarding port

A root forwarding (RF) port is the port receiving the best BPDU on the switch (see Figure 25 on page 80).
80 Concepts Figure 25 Root Forwarding Port
This is the port that is the closest to the root bridge in terms of path cost. The spanning tree algorithm elects a single root bridge in a bridged network per spanning tree instance. The root bridge is the only bridge in a network that does not have root ports; all ports on a root bridge are designated forwarding (DF). There can only be one path towards a root bridge on a given segment, otherwise there are loops.
Designated forwarding port

All bridges connected on a given segment listen to each others BPDUs and agree on the bridge sending the best BPDU as the root bridge for the segment. The corresponding port on the bridge is referred to as a designated forwarding port (see Figure 26).
Figure 26 Designated Forwarding Port
Alternate blocking port

A blocked port is a port not designated as the root port. An alternate blocked port is a port that becomes blocked when receiving more useful BPDUs from another bridge (see Figure 27 on page 81).
320747-A
Concepts 81 Figure 27 Alternate Blocking Port
Rapid convergent
In RSTP and MSTP, the environment root port or the designated port can ask its peer for permission for going to the forwarding state. If the peer agrees, then the root port moves to the forwarding state without any delay. This procedure is called the negotiation process. RSTP and MSTP also allow information received on a port to be sent immediately if the port becomes dysfunctional instead of waiting for the maximum age time.
Negotiation process
After power up, all ports assume the role as designated ports. All ports are in the discarding state except edge ports. Edge ports go directly to forwarding state without delay. The RSTP convergent time depends on how quickly the switch can exchange BPDUs during the negotiation process, and the number of switches in the network. The convergent time depends on the hardware platform, and number of active applications running on the switch.
Regents
STP only supports one regent, so you can not change regents. For a set of nodes to belong to the same regents, all such nodes must have all VLANs identically configured to the same VLANs for all MSTIs even if the VLAN is not mapped to the port on the node. This is the same way legacy STP operates. Root node selection operates the same as legacy STP. Here, the lowest value bridge MAC is chosen and this bridge (or node) becomes the root node, if all priorities are the same. If another bridge has a higher priority (lower value), the lower value is chosen.
82 Concepts
Root port selection also operates the same as legacy STP. The port with the best BPDU gets chosen. If two ports receive the same best BPDU, the one with the lower MAC or the one with the higher priority (lower value) is chosen.
RSTP
This section describes the rapid recovery of connectivity following the failure of bridge or bridge port in a LAN with loops. RSTP significantly reduces the time it takes to reconfigure the active topology or for its configuration parameters to occur. A new root port can transition rapidly to the forwarding port state, and the use of explicit acknowledgements between bridges allows designated ports to transition to the forwarding state. RSTP allows switch port configuration so the ports can transition directly to forwarding when the switch re-initializes. RSTP works in STP-compatible mode when peer bridges are legacy bridges operating in STP mode. This module performs the following major functions: Processes the incoming messages and updates the port information. Selects the role of the bridge port. Performs transition to the selected port role. Updates the port status as per port role. Transmits RST BPDUs (in RSTP Mode) and configuration and topology change notification BPDUs (in STP-compatible mode). Propagates the topology changes to all ports.
This module also handles the expiry of the following timers: Hello timer Topology change timer Forward delay timer Hold timer Protocol migration delay timer Recent root while timer Recent backup while timer Received info while timer
320747-A
Concepts 83
MSTP
This section describes how to configure a spanning tree on a per-VLAN basis or multiple VLAN basis per spanning tree. MSTP provides greater control than RSTP over the network traffic and also allows for load balancing through the use of multiple spanning trees. MSTP is an extended implementation of RSTP, providing all the functionality of RSTP in addition to greater network control. MSTP allows you to build multiple spanning trees over VLAN trunks. VLANs can be grouped or associated to spanning tree instances. The topology of one instance can be independent of the other instances. This architecture provides multiple forwarding paths for data traffic and enables load balancing. The failure in one instance does not affect the other instances. This allows VLAN bridges to use multiple spanning trees, providing for traffic belonging to different VLANs to flow over potentially different paths. In MSTP, some or all bridges participate in two or more spanning trees, and each VLAN is allocated to one of the spanning trees. Multiple VLANS can coexist over any given spanning tree. Each instance of the spanning tree can operate either in STP-compatible or RSTP/ MSTP mode. The MSTP module performs the following functions: Processes the incoming messages and updates the port information. Selects the role of the bridge port. Performs transition to the selected port role. Updates the port status as per port role. Transmits RST BPDUs (in MSTP mode) and configuration and topology change notification BPDUs (in STP compatible mode). Maps the VLAN to the spanning tree instances.
This module also handles the expiry of the following timers: Hello timer Topology change timer Forward delay timer Hold timer Protocol migration delay timer
84 Concepts
Recent root while timer Recent backup while timer Received info while timer
The following is an example of the MSTP operation: 1 2 3 4 MSTP Instance 1 selects switch 1 (SW1) as the root and blocks link between SW 2 and SW 3 (see Figure 28 on page 85). MSTP Instance 2 selects SW2 as root and blocks link between SW 1 and SW 3. Traffic on VLAN 100 transverses the link between SW1 and SW3. Traffic on VLAN 200 transverses the link between SW2 and SW3.
320747-A
Concepts 85 Figure 28 MSTP example
PC2 Root Bridge Instance 1 for SP-V100 UNI 2 TDI 100
SW1 All Network Links TDI 100 SP-V100 TDI 200 SP-V200 (3) Metro 8600 Instance 2 Block PC2 UNI 3 TDI 200 SW2 (1) Root Bridge Instance 2 for SP-V200 Instance 2 Block SW3 UNI 4 TDI 200 (4) PC2 (2) UNI 3 TDI 100
PC2
Note: Before configuring Metro Ethernet Services on the Metro Ethernet Passport 8600 Switch, be sure to review the configuration considerations described in Chapter 3, Configuration considerations and limitations, on page 117.
86 Concepts
320747-A
87
Chapter 2 Triple Play Services

This chapter provides a conceptual overview of the Metro Ethernet Passport 8600 Switch Triple Play feature as a part of the aggregation switch in the (Nortel) Metro Ethernet Solutions. For configuration limitations and interoperability issues to consider when configuring your Metro Ethernet Passport 8600 Switch, refer to Chapter 3, Configuration considerations and limitations, on page 117. For information about configuring your switch using Device Manager, refer to Chapter 4, Configuring the Metro Ethernet Passport 8600 Switch using Device Manager, on page 181. For information about configuring your switch using the Command Line Interface (CLI), refer to Configuring the Metro Ethernet Passport 8600 Switch using CLI.
This chapter includes the following topics:

Topic Triple Play overview Topologies Traffic types Tagged and untagged traffic Traffic direction IP subnet and VLAN IP address spoofing IP multicast IP-based services Function IP multicast processing Page 88 91 94 98 98 98 100 101 108 114 115
88 Triple Play Services
Triple Play overview

The Triple Play feature allows a network to carry video, data, and voice to network customers by using Layer 3 multicasting. IP Multicast extends the benefits of Layer 3 multicasting on LANs to the WANs and Metropolitan Area Networks. IP multicasting provides services such as the delivery of information to multiple destinations with a single transmission and the solicitation of servers by clients. The source enjoys considerable efficiencies while saving a significant amount of bandwidth. These services benefit applications such as audio/video conferencing, interactive TV, video distribution, surveillance, and distance learning. The Metro Ethernet Passport 8600 is capable of replicating and forwarding multicast packets to the ports on the switch. The Metro Ethernet Passport 8600 also has the capability to implement Layer 3 routing multicast. Triple play works on either a customer premise topology using a series of ESUs to form a ring or on an access network topology by connecting a Metro Ethernet Passport 8600 Switch ESM 8668 module directly to a Layer 2 switch or a DSLAM. IP Multicast and IP VLAN are used in the ESU ring topology and the access network topology. With IP Multicast, in the ESU ring topology, Layer 3 activities occur in the Metro Ethernet switch, and Layer 2 activities occur in the ESU. The switch acts as a multicast router, while the ESU carries out Internet Group Management Protocol (IGMP) proxy and snoop functions. In the network access topology, IP multicast occurs in the same way as legacy Metro Ethernet Passport 8600 access modules. With IP Multicast and the ESU ring topology, all Layer 3 multicast activities occur within the Metro Ethernet Passport 8600 Switch, and Layer 2 Internet Group Management Protocol (IGMP) activities occur within the ESU. The Metro 8600 switch acts as the multicast router, while the ESU carries out (IGMP) snoop functions. When using Local ESM 8668 ports for IGMP access topology, IP multicast forwarding occurs in the same way as legacy Metro Ethernet Passport 8600 access modules.
320747-A
Triple Play Services 89
With IP VLAN and the ESU ring topology, all IP Layer 3 activities occur within the Metro Ethernet PAssport 8600 Switch. The ESU ring topology acts as a layer 2 transport between the Metro Ethernet Passport 8600 and the assigned end-points on each ESU. When IP broadcasts enter the ring topology, only one packet is sent into the ring and the ESU acts as the broadcast device for all ports assigned to the IP VLAN that broadcast packet belongs to. The ESU classifies packets as either IP or VPLS, depending on the customer qtag and the IP VLAN assigned to each ESU port. If the ESU port is a member of an IP VLAN that matches the customer qtag, the packet is classified as IP and sends the IP traffic seamlessly to the Primary port. If an Address Resolution Protocol (ARP) packet is sent, and if the ARP packet has a VLAN tag that matches the ESU ports IP VLAN assignment, the packet is sent to the Metro Ethernet Passport 8600 for processing and then the Metro Passport 8600 broadcasts the packet to all ports that are a member of the same IP VLAN. When using Local ESM 8668 ports for IP access topology, the IP VLAN services perform the same way as a legacy Metro Ethernet Passport 8600 access module. Features involved in Triple Play support over an ESU ring are as follows: Ethernet VPN versus IP traffic path selection per C-VID VoIP, Internet Access (& Management traffic) - IP Unicast Ring IP VLAN VID to internal PP8600 VLAN VID translation Video Distribution (Egress) IP Multicast IPMC: PIM-SM; IGMPv2 support PIM-SSM IGMPv2 Static mode supported with channel table for SSM Ring Egress IP Multicast (Ingress IP Multicast not supported on Ring) Standalone ESU uses similar concepts a mux tag is used for example Multiple services per port IGMP access list IGMP proxy/snoop Fast leave
ESU ports participating in a certain service (such as VoIP) can share the same IP VLAN Id. It is possible to create separate service domains for example, Gold Internet versus Silver Internet access. VLAN translation is possible: for example, IP VLAN/1000 translates to (PP8600) Routed VLAN/10. Broadcast, Multicast (mux) stack tags provide efficient distribution of this traffic through the ring. Triple play has just one flow sent around the ring, allowing the ESUs to absorb and distribute the packets as required. There is a one-to-one customer q-tag relationship with routed IP-VLANS per ESM port. Support per ESM port and ring is one customer q-tag ID per routed SP IP-VLAN. IP services on a ring is shared between UNIs, but the customer q-tag must be common for each UNI on the ring. Note: It is possible to use different customer q-tags across different rings and local TLS ports for mapping to a common IP-VLAN. The restriction is on ring ports where multiple UNIs reside on the same ring. Management traffic can now pass through a UNI without being OEL2 encapsulated. Also, an ESU 1800/1850 can now use the same routed Customer IP VLAN. CPE attached to ESU 1800/1850 can also be managed on the same Customer IP VLAN with the ESU 1800/1850 for management purposes. Note: The Triple Play solution only supports unique IP VLANs per ring and Standalone ESU. Global IP VLANs across multiple rings and standalone ESUs are not supported. This chapter describes: the adaptation of multicast capabilities of the Metro Ethernet Passport 8600 and the implementation of additional features and functions are implemented in the ESM module in order to support IP Multicast service as part of the OESS product offering. the architecture to provide converged IP-based voice, Internet access, and device management along with IP Multicast video over the OE infrastructure.
Delivery of Ethernet VPN services was available in the Metro Ethernet 3.5 release. This chapter does not describe mechanisms to deliver Ethernet VPN services; however, as and when required, the chapter discusses Ethernet VPN.
320747-A
Topologies
This section contains the following topology types: Customer premise topology (ESU ring) on page 91 Access network topology (local) on page 92
Customer premise topology (ESU ring)

The ports on the ESM module are grouped in pairs (see Figure 29 on page 92). It is not necessary that the ports be configured as shown in the figure. The ports in each pair belong to different ESM modules to eliminate single point of failure. The ports in each pair, called ring ports, connect to the two ends of an ESU daisy-chain respectively so as to form a ring. CPEs, like the set-top device, are connected to the 10/100 ports on the ESUs. These CPEs are typically triple-play devices supporting video, phone and Internet access. DSLAMs can be connected directly to the ESU 1850 in the ring configuration. Each ESU ring is associated with a pair of Metro Ethernet Passport 8600 ring ports and is given a ring ID. Each pair consists of a Primary and a Secondary ring port. Both the Primary and Secondary ring ports need configuring. For example, when the ring ports are added to or removed from an SP VLAN, the Primary and Secondary ring ports are added or removed together.
92 Triple Play Services Figure 29 Customer premise topology ESU ring
Access network topology (local)

The ports on the ESM module connect directly to the access devices, such as DSLAMs and Layer 2 ethernet switches, which are part of the access network (see Figure 30 on page 93).
320747-A
Triple Play Services 93 Figure 30 Access network topology - local
Ring protocols
To ensure the ESU ring performs to the 50ms standard, two protocols are employed: Ring topology protocol, next Ring resiliency protocol on page 94
Ring topology protocol

The ring topology protocol (RTP) protocol control packet consists of two types of messages: discovery message and assignment message. Under normal conditions, the RTP discovery message packet is sent from the Primary ESU ring port onto the ring periodically (30 seconds default; manually configurable from 1 to 255 seconds), and the packet is received by the Secondary ESU ring port after it transverses the ESU ring. If any one of the ESUs on the ring has the factory default module ID, or there is change on the ring, the assignment message is sent immediately after the discovery message is received by Metro Ethernet Passport 8600.
The RTP is developed to: Enable the ESU units to determine which uplink port to forward video multicast traffic and which port is to forward all other traffic (plug and play) Monitor the ESU ring configuration changes and ESU port state by the Metro Ethernet Passport 8600 Automatically assign a module ID to a new ESU 1850 inserted onto the ring
Considerations for configuration include: RTP uses the Stack Module ID of 27 (To Local CPU Msg) in the STACK-TAG header. Each ESU is identified through a module ID; therefore, on a ring, a module ID must be unique. The factory default module ID on all ESU units is set to zero.
Ring resiliency protocol

The ring resiliency protocol (RRP) guarantees failover on an ESU ring to less than 50 ms when a fiber cut or an ESU failure occurs. In the event of link or node failure in the ring, traffic will be directed to an alternate path. The failure detection is based on physical mechanisms so that no end-to-end signaling limits the extension of the ring. It is also based on RRP messages.
Traffic types
This section describes IP multicast and other IP-based services. Figure 31 on page 95 illustrates the generic set of services supported over the OE infrastructure in this release.
320747-A
Triple Play Services 95 Figure 31 Traffic types generic case

IP Multicast TV and Voice traffic Internet Access traffic Management traffic VID Y1 Enterprise Ethernet VPN traffic VID Yn
UNI
VID W VID X VID M
IP Network
Pt2Mpt Ethernet VPN Any2Any Ethernet VPN Eth ernet VPN
Note 1: W is alwa ys an IP VLAN - VoIP and IPMC are always via IP network Note 2: X is NOT an IP VLAN - Internet Access is via PPPoE through Ethernet VPN Note 3: M is NOT an IP VLAN - Management is through Ethernet VPN Note 4: VID Yns must always be tagged frame
Delivery of any of the services over an Ethernet VPN was available in the Metro Ethernet 3.5 release. Mechanisms to deliver Ethernet VPN services are not described here. See Chapter 1, Concepts, on page 30 for a description of the ESM 8668 module. The DSLAMs or STBs or directly attached access devices typically use different IP addresses for different services such as VoIP, video (IP multicast (IPMC)), Internet access and management. Also, these different traffic types typically travel over different VLANs one each for each subnet. The following IP-based services are supported and their respective traffic travels over the OE architecture in both the ESU ring and the access network topologies: Internet data (IP Unicast) VoIP (IP Unicast) IP Multicast TV (IPMC for channel distribution and IP unicast/multicast for middleware and STB management communication)
Management traffic to/from SP-owned devices (for example, DSLAM, and BayStack Ethernet switches) off OE UNI ports
Internet access data also uses a different encapsulation, which is PPP over Ethernet (PPPoE). The PPPoE traffic maps to a point-to-multipoint Ethernet VPN over the OE infrastructure to the Broadband Remote Access Server (BRAS). The Ethernet VPN based Internet access is not discussed in this document. See Chapter 1, Concepts, on page 37 for a description of the Ethernet VPN. Management traffic also travels over the OE infrastructure through a point-to-multipoint Ethernet VPN. The implementation details for the Ethernet VPN-based management are discussed in this chapter for the same reason. See Chapter 1, Concepts, on page 37 for a description of the Ethernet VPN management. This chapter describes only the case where W, X, M (see Figure 31 on page 95) are configured as IP-VLANs. In this case, all IP multicast, voice, Internet access and management traffic travel through different IP subnets and would be tagged with appropriate IP VLAN IDs. These services on separate networks in Figure 31 on page 95 merge as seen in Figure 32 on page 97.
320747-A
Triple Play Services 97 Figure 32 Traffic types different IP traffic on different IP subnets
UNI
IP Multicast TV and Voice traffic Internet Access traffic Management traffic IP Sub Network C VID W VID X VID M IP Sub Network A
IP Sub Network B
Note: W, X and M are distinct IP V LAN s Services are via different IP subnets
Figure 33 Traffic types All IP traffic on the same IP subnet
UNI
Video, Voice, Internet Access and Management traffic W=X=M IP Network
Note 1: W = M = X all services are via a single IP subnet Note 2: W = M = X (un tagged) all services are via a single IP subnet
In the special case where W = X = M (in Figure 33), all IP multicast, voice, Internet access and management traffic travels on the same IP subnet and this merges the networks in Figure 31 on page 95 to Figure 33.
Tagged and untagged traffic

In the ESU ring, all IP multicast, VoIP and IP-based Internet access and management traffic, control and data either carries the customers 802.1q VLAN tag or the default 4094 (for untagged traffic). Apart from this tag, the packet header also contains a mux tag. See Configuring the Metro Ethernet Services Unit 1850 Using the CLI or Metro ESU 1800 Concepts for a description of the mux tag. In the access network topology, all IP multicast, VoIP and IP-based Internet access and management traffic, control and data, flowing between the access device and the Metro Ethernet Passport 8600 ESM port, either carries the 802.1q VLAN tags or are untagged.
Traffic direction
In an access network topology, all traffic ingresses and egresses through the same access port. In an ESU ring topology, IP multicast control and data traffic flows in the ring in the direction from the Secondary to the Primary ring port. This is opposite to the direction taken by the VPLS traffic. VoIP and IP-based Internet access and management ingress traffic also take the direction of unicast IPVLAN traffic in the down stream direction goes in the same direction as VPLS traffic. However, on egress, VoIP and IP-based Internet access and management traffic take the direction of VPLS traffic. This balances bandwidth usage in the ring and leaves half the bandwidth for egress IP multicast traffic.
IP subnet and VLAN

This section contains the following topics: ESU ring topology, next Access network topology on page 100
320747-A
ESU ring topology

The ESUs and the SP devices connected to them (like DSLAMs, STBs) would typically use different IP addresses for different IP-based applications. That is, one address for VoIP and IPMC, a different address (public address) for IP-based Internet access, and another address (private address) for IP-based management traffic. See Figure 34 for an example configuration.
Figure 34 Example IP multicast configuration
The ESU ring supports multiple IP subnets. To accomplish the requirements, each pair of Metro Ethernet Passport 8600 ring ports is configured to be part of one or more SP VLANs and IP subnet, with the appropriate subnet classification assigned to those VLANs. Each UNI associated with the ESU in the ring is configured with one or more customer IP VLAN IDs which are associated with the IP multicast, VoIP, IP-based Internet access and management traffic flowing in the ring. There is a one-to-one association between customer IP VLAN IDs in the ESU ring and the SP IP VLAN IDs at the Metro Ethernet Passport 8600 ring ports. At the Metro Ethernet Passport 8600 ring port, a translation is done from the customer VLAN ID to the SP VLAN ID to which the Metro Ethernet Passport 8600 ring ports belong to before further processing.
Access network topology

The directly attached SPs access devices (such as DSLAMs, STBs) would typically use different IP addresses for different IP-based applications. That is, one address for VoIP and IPMC, a different address (public address) for IP-based Internet access, and another address (private address) for IP-based management traffic. In order to support this triple need for IP addresses, multiple IP subnets are supported on the ESM port. The Metro Ethernet Passport 8600 ESM module port in the access network topology is configured to be part of one or more SP VLANs and IP subnet, with the appropriate subnet classification assigned to those VLANs. There is a one-to-one association between customer IP Vlan IDs and the SP IP Vlan IDs at the Metro Ethernet Passport 8600 ESM ports. At the Metro Ethernet Passport 8600 ESM port a translation is done from the customer VLAN ID to the SP VLAN ID to which the Metro Ethernet Passport 8600 ESM port belongs to before further processing.
IP address spoofing
IP address spoofing is the intentional misrepresentation of the source IP address in an IP packet. IP address spoofing conceals the identity of the sender or impersonates another computing system. To prevent spoofing of IP addresses within a VLAN, you can configure the ability to detect duplicate IP addresses and block any packet to or from that Media Access Control (MAC) by discarding the MAC record. This configuration can occur on a single port basis. Duplicate IP addresses are addresses that are the same as the switchs VLAN IP address. The Address Resolution Protocol (ARP) translates MAC addresses into IP addresses and detects duplicate IP addresses. If an ARP packet has the same source IP address as the switchs VLAN IP address, then all traffic entering on any port of the switch in that VLAN with this MAC as a source or destination is discarded. A static MAC address record overwrites the learned MAC address record with the source/destination discard mask set for all ports in the switch.
320747-A
After detecting a duplicate IP address, the switch sends a gratuitous ARP notification to notify other devices on the VLAN about the correct MAC address for that IP. This prevents other devices from sending packets for this IP to the malfunctioned device. An Auto-Recovery option is available per port using a configurable global Auto-Recovery timer to specify when an IP Spoofed MAC discard record will be deleted to allow the switch to start accepting packets from the MAC address with the IP Spoofed entry. This is to allow time for an offending device to correct its IP address due to a mistake in the config.
IP multicast
This section contains the following topics: Metro 8600 IGMP (Level 2) on page 101 IP multicast in the ESU ring topology on page 103 IP Multicast Routing service on page 104
Metro 8600 IGMP (Level 2)

The IP multicast router on the Metro Ethernet Passport 8600 uses IGMP to learn the existence of host group members on its directly attached ESU rings. Hosts on the ring communicate their desired group memberships to the Metro Ethernet Passport 8600 in order to receive any multicast traffic sent to this router and targeted to a group with a specific IP multicast address. The Metro Ethernet Passport 8600 communicates with the hosts on the ring by sending IGMP queries. Hosts respond by issuing IGMP reports. The Metro Ethernet Passport 8600 supports all versions of IGMP.
IGMP Proxy
If the Metro 8600 switch receives multiple reports for the same multicast group, it does not transmit each report to the multicast upstream router. Instead, it forwards only the first report. If there is new information that another multicast group has been added or that a query has been received since the last report was transmitted upstream, then the report is forwarded onto the multicast router ports.
IGMP host membership reports

End points have hosts/receivers attached to their ports. These hosts/receivers announce their intention to join or leave IP multicast groups through IGMP messages/reports. The end points relay these reports to the upstream multicast router running on the Metro Ethernet Passport 8600.
IGMP queries
Periodically, the Metro Ethernet Passport 8600 sends IGMP host membership queries into the end points to see if hosts still belong to the groups to which they originally subscribed. The ESUs relay these queries out on their ports to the hosts and in turn relay the response/reports from the hosts back to the Metro Ethernet Passport 8600.
Metro Ethernet Passport 8600 as a multicast router

The composition of multicast groups changes as hosts subscribe and unsubscribe to them. The Metro Ethernet Passport 8600 tracks group memberships by using these queries and reports to maintain a group subscription table that maps hosts to multicast groups. Also, the multicast router on the Metro Ethernet Passport 8600 keeps track of these groups dynamically and builds distribution trees that chart paths from each sender to all receivers. When the Metro Ethernet Passport 8600 receives traffic for a multicast group, it refers to the specific tree that it built for the sender, and forwards the traffic only to those end points. It knows that hosts subscribe to that specific group.
320747-A
If at least one host on the end point specifies that it is a member of a given group, the Metro Ethernet Passport 8600 forwards all datagrams bearing the groups multicast address to that end point. When the ESU, DSLAM, or Layer 2 switch receive this multicast stream, they forward it from their ports to the hosts that subscribe to this group.
Host leave messages

When the host that issued the most recent report leaves the group, the host issues a leave-group message. The multicast router on the Metro Ethernet Passport 8600 issues a group-specific query to determine whether there are other group members attached to the end point. If no host responds to the query, the router stops forwarding traffic destined for that multicast group. Note: If one host is active on the an ESU Ring, the multicast stream continues to forward in the ring until the last host sends a Leave Message.
IP multicast in the ESU ring topology

IP multicast in the ESU ring topology involves the interworking of a Layer 3 component in the Metro Ethernet Solutions switch and a Layer 2 component in the ESU device. The Metro Ethernet Passport 8600 device performs the functions of a multicast router while the ESU device performs the functions of an IGMP snoop device. Note: Only one IP VLAN can carry multicast traffic over the ESU ring.
ESU as an IGMP proxy/snoop device

Since the ESU is a broadcast medium, it broadcasts the multicast traffic to all its ports. However, this broadcast to all ports is not efficient. Additionally, hosts on some ports that did not subscribe to certain multicast groups still receive traffic for that group, which is undesirable.
The ESU prunes group membership per port. This feature, called IGMP snoop, allows the ESU to optimize the multicast data flow for a group to only those ports that are members of the group. The ESU builds a database of group members by snooping IGMP reports from hosts on each port. It suppresses the reports heard by not forwarding them out to ports other than the one receiving the report, forcing the members to continuously send their own reports. Based on the group membership database that it has built, it forwards multicast data only to ports that have participating group members. For more information about how the ESU performs these functions, refer to Configuring the Metro Ethernet Services Unit 1850 using the CLI or Metro ESU 1800 Concepts.
Fast-leave feature
The ESU supports a fast-leave feature that is useful for multicast-based TV distribution applications. The ESU stops sending traffic out its access port for a multicast group immediately after receiving a leave message. Fast leave alleviates the network from additional bandwidth demand when changing TV channels.
IP Multicast Routing service

The IP Multicast Service for the Triple Play is a Layer 3 Service only. The ESM 8668 and ESU Rings do not support bridging of multicast packets. You must enable a multicast routing protocol on the NNI VLAN or SP VLAN for proper multicast forwarding. In this release, PIM-SM and PIM-SSM is supported.
Protocol-independent multicast-sparse mode (PIM-SM)

Protocol independent multicast-sparse mode (PIM-SM), as defined in RFC 2362, supports multicast groups spread out across large areas of a company or the Internet. Unlike dense mode protocols, such as DVMRP, which initially flood multicast traffic to all routers over an entire Internet work, PIM-SM sends multicast traffic only to routers that have specifically joined a multicast group. This technique reduces traffic flow over WAN links and overhead costs for processing unwanted multicast packets.
320747-A
Dense-mode protocols use a flood-and-prune technique, which is efficient where receivers are densely populated. However, for sparsely populated networks, PIM-SM is more efficient because it sends multicast traffic only to those routers that belong to a specific multicast group and that choose to receive the traffic. PIM-SM is independent of any specific unicast routing protocol, but it does require the presence of a unicast routing protocol, such as RIP or OSPF. PIM-SM uses the information from the unicast routing table to create and maintain multicast trees that enables PIM-enabled routers to communicate. In Release 3.6, PIM-SM is supported on both the core facing ports and the UNI facing ports. Typically, a PIM-SM network consists of several multipoint data streams, each targeted to a small number of LANs in the Internet work. For example, customers whose networks consist of multiple hosts on different LANs can use PIM-SM to simultaneously access a video data stream, such as a video teleconference, on a different subnet.
Protocol-independent multicast-source specific multicast (PIM-SSM) on the ring ports

Source-specific multicast (SSM) optimizes PIM-SM by simplifying the many-to-many model. Since most multicast applications distribute content to a group in one direction, SSM uses a one-to-many model that only uses a subset of the PIM-SM features. This model is more efficient than PIM-SM and decreases the load on multicast routing devices. SSM only builds source-based shortest path trees. Where PIM-SM always joins a shared tree first and then switches to the source tree, SSM eliminates the need for starting with a shared tree by immediately joining a source through the shortest path tree. This method enables SSM to avoid using a rendezvous point (RP) and RP-based shared trees, which can be a potential bottleneck. For hosts that belong to an SSM group. the members can only receive from a single source. This is ideal for applications like TV channel distribution and other content-distribution businesses. Banking and trade applications can also use SSM because it provides more control over the hosts receiving data and sending data into their networks. PIM-SSM architecture requires routers and edge devices to:
Support IGMPv3 source-specific host membership reports and queries at the edge routers. Initiate PIM-SSM (S,G) joins directly and immediately after receiving an IGMPv3 join report from the designated router. Restrict forwarding to shortest-path trees within the SSM address range by all PIM-SSM routers.
SSM and IGMPv2

The ESU 1800 and ESU 1850 support IGMPv2 with ESU release 2.1.0.0. SSM-configured Metro Ethernet Passport 8600 Switches can accept reports from IGMPv2 hosts on IGMPv2 interfaces, such as the ESU 1850, if the group has an SSM channel table entry. However, the IGMPv2 host groups must be in the SSM range defined on the Metro Ethernet Passport 8600 Switch, which is 232/8 by default. IGMPv2 introduces the leave concept and last member query. When the SSM switch receives an IGMPv2 report for a group that is in the SSM channel table, it joins the specified source immediately. When the SSM switch receives an IGMPv2 report for a group that has an enabled static SSM channel table entry, it triggers PIM-SSM processing as if it received an equivalent IGMPv3 report. When the SSM switch receives an IGMPv2 report for a group out of the SSM range, it processes the report as if it were in PIM-SM mode. Note: Do not put sources on an ESU. Only put receivers on an ESU.
SSM and IGMPv3

The Metro PP8600 supports IGMPv3 for SSM on local TLS ports (ESM 8668 customer-facing port). IGMPv3 enables a host to selectively request or filter traffic from sources within the multicast group. IGMPv3 is an interface-level configuration. Note: IGMPv3 functions only with ESM 8668 local TLS ports with PIM-SSM or SSM snoop enabled on the interface.
320747-A
The following rules apply to IGMPv3-enabled interfaces: Send only IGMPv3 (source-specific) reports for addresses in the SSM range. Accept only IGMPv3 reports. Drop IGMPv2 reports received on an IGMPv3-enabled port. Discard any IGMP packets with a group address out of the SSM range.
Note that the IGMPv2 report mentioned in the SSM and IGMPv2 on page 106 was processed because it was an IGMPv2 report received on an IGMPv2 interface. If it were an IGMPv3 report received on an IGMPv2 interface, it would have been dropped even if PIM-SSM was enabled and the entry was in the SSM channel table. The IGMP version must match first.
Packet replication
The key to carrying IP multicast traffic efficiently from the sender to the receivers is to move all the replication as close to the receivers as possible. This greatly reduces the bandwidth requirement in the SPs backbone. The Metro Ethernet Passport 8600 sends only one copy of a multicast data stream out into one ESU ring, irrespective of the number of host members for that group. Each ESU in the ring has the responsibility to replicate this stream to hosts that are connected to its ports and which have subscribed to this group. As a result, the bandwidth utilization in the ring is kept to a minimum.
IP multicast in the access-network topology

IP multicast on the Metro Ethernet Passport 8600 ESM module in the access network topology functions in exactly the same way as legacy Metro Ethernet Passport 8600 access modules.
PIM-SSM on the ESU ring

Ports on the Metro Ethernet Passport 8600 ESM module connect directly to access devices like a DSLAM or a Layer 2 Ethernet switch. PIM-SSM in the access network topology functions the same as in the ESU ring topology.
IP-based services
This section contains the following topics: IP-based services in the ESU ring topology IP-based services in the access-network topology on page 112 QoS support on page 113 IGMP access control list on page 114
IP-based services in the ESU ring topology

IP in the ESU ring topology involves the interworking of a Layer 3 component in the Metro Ethernet Passport 8600 Switch and a Layer 2 component in the ESU device. The Metro Ethernet Passport 8600 Switch performs the functions of a Layer 3 router while the ESU device either acts as a mux/demux device or performs the functions of a Layer 2 broadcast device when required.
Metro Ethernet Passport 8600 as an IP router

Each pair of ESU ring ports is part of an SP VLAN with an IP subnet defined for that VLAN. This initiates an IP router instance on each pair of ESU ring ports. The ESU ring ports obeys all the IP subnet and VLAN rules. See Existing support for IP multicast in the Metro Ethernet Passport 8600 on page 115. The router instance, with the help of its associated routing table manager in the form of RaptARU IP records, routes all IP ingress traffic coming from the ring. All the existing legacy routing functions of the Metro Ethernet Passport 8600 device are used for this purpose. The ESU ring port removes the mux tag and perform any necessary VLAN remapping (see Existing support for IP multicast in the Metro Ethernet Passport 8600 on page 115) and sends the packet for a RaptARU lookup to be routed appropriately. IP traffic coming from the NNI destined for the ring is routed by the legacy Metro Ethernet Passport 8600 modules and R modules for NNI towards the ESU ring ports. On egress, when an IP packet is to exit the ESU ring port and enter the ring, the destination IP address is looked up in a learned IP database and is used to identify the egress ESU, its access port, and the egress customer-VLAN. The ESU
320747-A
ring port adds the mux tag and performs any VLAN remapping (as described in Existing support for IP multicast in the Metro Ethernet Passport 8600 on page 115) and sends the packet into the ESU ring. Figure 35 shows how the packet is organized.
Figure 35 Tagged packet egressing from an ESU 1850 to the switch
The learned IP database and its creation is described in Existing support for IP multicast in the Metro Ethernet Passport 8600 on page 115. Figure 36 on page 110 is an example configuration of IP-based services in the ESU ring topology.
110 Triple Play Services Figure 36 ESU ring topology
ESU 2
Mod-ID=2
Port 25 Port 26
ESU 1
Mod-ID=1
Port 25
Primary Ring Port
Port 26
Protocols handling the resiliency and efficiency on the ring: RTP & RRP
Port 25 Port 25 Port 26 Port 26 Secondary Ring Port
ESU 3
Mod-ID=3
ESU 4
Mod-ID=3
Note: An ESU in standalone mode will always have Mod-ID=1.
Customer premise equipment (CPE) Packet
ESU in mux/demux mode

The ESUs in the ring forward the customers IP-based unicast traffic seamlessly to the ESU ring ports. All IP-based unicast traffic from the customer is forwarded by the ESUs to the Primary ring port on the Metro Ethernet Passport 8600, as illustrated in Figure 30 on page 93 and Figure 31 on page 95, in the normal and broken ring cases respectively. All IP-based unicast traffic from the Metro Ethernet Passport 8600 to the customer goes out of the Primary ring port on the Metro Ethernet Passport 8600 as illustrated in the Figure 30 on page 93 and Figure 31 on page 95. The packet is illustrated in Figure 37 on page 111.
320747-A
Triple Play Services 111 Figure 37 Tagged packet from the switch to the ESU
For details on the mux/demux mode of the ESU and its functioning, see Configuring the Metro Ethernet Services Unit 1850 Using CLI.
ARP broadcast in the ESU ring

The mux/demux mode in the ESUs does not provide an efficient way to transport and broadcast ARPs in the ESU ring. To broadcast ARPs in the ring efficiently, that is, with only one copy of the ARP packet entering the ring, some Layer 2 broadcast functionality of the ESU is turned on. For this purpose, the ESUs at the time of configuration build a port map based on the VLAN and are configured to carry all IP/ARP traffic in the ring. Ports on the ESU that carry IP traffic are added to this VLAN. Whenever the IP router instance on the Metro Ethernet Passport 8600 ESU ring ports needs to send an ARP broadcast to any of the ESUs or devices attached to their access ports, it sends only one copy of the ARP into the ring. Each ESU, on receiving this packet, replicates this ARP based on the 802.1q VLAN ID contained in the ARP packet and sends the ARP out only those of its access ports belonging to that VLAN. Each ESU also relays this ARP to the next upstream or downstream ESU in the ring. For more details, see Configuring the Metro Ethernet Services Unit 1850 Using CLI.
IP address learning on the Metro Ethernet Passport 8600

The Metro Ethernet Passport 8600 learns customer IP addresses on a per UNI per customer IP VLAN basis.
The number of IP addresses learned is governed by the IP table size and IP table watermark attributes. The validity period of the learned IP addresses is governed by the age-timer attribute. SNMP traps are sent once the number of learned IP addresses crosses the IP table watermark and learning stops once the number of learned IP addresses reaches the IP table size for that customer IP VLAN on that UNI. Thus, the IP table watermark acts as a monitoring tool while the IP table size is used as an effective tool to stop DOS attacks from a rogue customer trying to spoof multiple IP addresses and swarm the CP.
DHCP and BootP

Devices like the set-top-devices connected to the ESUs in the ring may have static IP addresses and use dynamic host configuration protocol (DHCP) to get their IP addresses assigned by a DHCP server at the MCN. Also, these devices, on power-up, use BootP followed by TFTP to get the boot-image and config files. When DHCP is used, the Metro Ethernet Passport 8600 device acts as a DHCP relay agent. The device passes the DHCP queries upstream towards the DHCP server and relays back the DHCP responses downstream into the ESU ring.
IP-based services in the access-network topology

IP-based services on the Metro Ethernet Passport 8600 ESM module in the access network topology function in exactly the same way as legacy Metro Ethernet Passport 8600 access modules.
Metro Ethernet Passport 8600 as an IP router

Each Metro Ethernet Passport 8600 ESM module port is part of a service-provider VLAN with an IP subnet defined for that VLAN. This initiates an IP router instance on each ESM port. The ESM port obeys all the IP subnet and VLAN rules as described in Existing support for IP multicast in the Metro Ethernet Passport 8600 on page 115.
320747-A
The router instance routes all IP ingress traffic coming into the ESM port. All the existing legacy routing functions of the Metro Ethernet Passport 8600 device are used for this purpose. The ESM port would perform any necessary VLAN remapping (as described in Existing support for IP multicast in the Metro Ethernet Passport 8600 on page 115) and sends the packet for a RaptARU lookup to be routed appropriately. IP traffic coming from the NNI destined for the ring is routed by the legacy Metro Ethernet Passport 8600 modules towards the ESM port. The ESM port performs any VLAN remapping (see Existing support for IP multicast in the Metro Ethernet Passport 8600 on page 115).
ARP broadcast in the access-network topology

Whenever an ESM port needs to send an ARP broadcast for the MAC address of the directly attached access device or devices thereof, it sends an ARP request out. All existing legacy Metro Ethernet Passport 8600 ARP mechanisms are used. However, prior to sending the ARP out, the SP VLAN in the packet is remapped to the customer VLAN for that ESM port.
IP address learning on the Metro Ethernet Passport 8600

In order to perform VLAN mapping, the switch learns IP addresses on ingress on the access port. On egress, when an IP packet is to exit the ESM port toward the access device, the destination IP address is looked up in the learned IP database and is used to identifies the egress customer VLAN. The SP VLAN tag in the packet replaces with the customer VLAN.
DHCP and BootP

DHCP and BootP function the same way as in the ring configuration. See DHCP and BootP on page 112.
QoS support
See Configuring QoS and IP Filter for the details about this feature.
IGMP access control list

There is an IGMP access control list on the ESU 1850. See Configuring the Metro Ethernet Services Unit 1850 Using CLI or Metro ESU 1800 concepts for more details There is also an IGMP access control list on the Passport 8600. See Configuring IP Multicast for more details
Function
This section contains the following topics: Statistics, next Policing on page 114 IP aging on page 114
Statistics
IP ingress and egress traffic statistics, in terms of packet count and octet count, are maintained for both transmitted and dropped traffic per customer IP VLAN per UNI.
Policing
IP ingress and egress traffic is policed per customer IP VLAN per UNI and non-confirming traffic is dropped. Policer parameters for IP ingress and egress traffic are configurable through ingress and egress COS profiles associated to the UNI supporting IP-based services. See Configuring the Metro Ethernet PAssport 8600 Using CLI.
IP aging
The learned IP address in the IP database would have associated aging timers. IP addresses that age past their aging time, and thus expire, are removed from the IP learning database.
320747-A
IP age times are configurable for UNIs that provide IP-based services.See Configuring the Metro Ethernet PAssport 8600 Using CLI.
IP multicast processing
The Metro Ethernet Passport 8600 can replicate and forward multicast packets to the ports on the switch. The Metro Ethernet Passport 8600 can implement Layer 3 multicast routing. The Metro Ethernet Passport 8600 supports IP multicast in the ESU ring configuration through the mux tag mode of operation.
Existing support for IP multicast in the Metro Ethernet Passport 8600

The Metro Ethernet Passport 8600 provides a unique architecture that handles IP multicast in an efficient and optimized manner. A packet is duplicated only when needed. At the ingress side, hardware IP multicast records are used to determine the destination ports of the packet. A packet that matches a hardware record is forwarded to the switch fabric, based on a pointer that points to the information on the destination modules in the chassis and the destination ports on these modules. The switch fabric uses this information to determine the required number of and sends one copy per board that has receivers attached to it. At the board level, a received multicast packet is duplicated to send to the receiver ports at the forwarding engine level. An egress forwarding pointer forwards the multicast packet to the destination ports.
320747-A
117
Chapter 3 Configuration considerations and limitations

This chapter describes configuration limitations and interoperability issues that you need to consider when configuring your Metro Ethernet Passport 8600 Switch. This chapter includes the following topics:
Topic Metro Ethernet Services configuration rules Metro ESU port rules Metro Ethernet Passport 8600 Switch QoS Metro 8600 QoS mapping Metro Ethernet Switch policing IP address spoofing Troubleshooting with TD continuity Enhanced RRP considerations VLACP considerations Page 117 151 153 157 163 173 174 179 179
Metro Ethernet Services configuration rules

This section describes configuration rules that apply to the Metro Ethernet Passport 8600 Switch when it is configured for Metro Ethernet Services. This section includes the following topics: Mapped NNI VLANs, next User-to-network interface (UNI ID) on page 121 Transparent domain ID (TDI) on page 132
118 Configuration considerations and limitations
Endpoints on page 135 NNI ports on page 139 Static destination UNIs and endpoints on page 140 Point-to-point UNIs on page 144 Legacy access port and services on page 147 Managing the Metro Ethernet switch on page 150 Edge-device management on page 151
Mapped NNI VLANs

A mapped NNI VLAN assigned to a customer TD is considered a Layer 2-only VLAN and cannot participate in any routing policies within the SP and customer network. Although multiple mapped NNI VLANs can appear to overlap a customer network when you use Metro ESM 8668 ports for local TLS services, the mapped NNI VLAN remains internal to the chassis and cannot be accessed by customers (even if the customer q-tags are the same as the mapped NNI VLAN IDs). You cannot configure mapped NNI VLANs for routing. When configuring mapped NNI VLANs, only the assigned NNI ports and the ESM ports associated with the assigned TDI for the mapped NNI can reside within the mapped NNI VLAN. You cannot configure mapped NNI VLANs for routing.
SP IP VLANs
A SP IP VLAN is considered a Layer 3 VLAN and does not support customer-based TD endpoints. You can use IP management VLANs to intranet-manage Metro Ethernet Passport 8600 Switches within an SP network. Although you can assign any legacy ports as management ports, if the VLAN assigned to these ports are mapped NNI ports to a customer TD and if the SP wants to manage the device through these ports to reduce costs, the SP must assign another VLAN as a member of these ports, and then assign the IP address to this VLAN or MLT group.
320747-A
Configuration considerations and limitations 119
When using a single port as a single interface, you can configure the port as a tagged brouter port, and the VLAN that is assigned to the brouter port becomes the IP management VLAN. You may associate this same single port with other mapped NNI VLANs for use as customer TDs.
VLAN rules
The following VLAN rules apply: You cannot configure access ports as members of an IP port-based VLAN if the NNI port is a member of the same IP port-based VLAN. You cannot configure an NNI port as a member of an IP port-based VLAN if the access ports are members of the same IP port-based VLAN. It is good practice to always assume that the Metro ESM 8668 ports are tagged (perform tagging is enabled). To support mapped NNI VLANs, you must enable the perform-tagging parameter on the NNI port(s). When you assign an endpoint to a TDI, the endpoints that are associated with the Metro Ethernet Passport 8600 ports are added to that TDIs mapped NNI-VLAN. If the ports in the endpoint are tagged, the ports remain in any previous VLAN assignments that existed, prior to being assigned to the TDI. You cannot remove port members from the TDIs mapped NNI-VLAN that are associated with assigned and active endpoints (for example, endpoints assigned to TDI) until the endpoint is deleted.
Figure 38 on page 120 shows how you can extend NNI VLANs between ESM local ports.
120 Configuration considerations and limitations Figure 38 Ethernet Access Rings and Mapped NNI VLANs example
Mapped NNI VLAN (no IP address) Management mapped VLAN (with IP address)
Mapped NNI (MLT)

1/1 Ring 1 1/2 1/3 1/4 1/5 1/6 1/7 1/8 8/1 8/2 8/3 8/4 8/5 8/6 8/7 8/8
Passport 8608 module
Passport 8608 module Metro ESM 8668
Legend Metro Ethernet Services Unit 1800 (Metro ESU 1800)

11260FA
Figure 39 on page 121 shows how you can extend server access VLANs between access ports and Metro ESM 8668 ports.
320747-A
Configuration considerations and limitations 121 Figure 39 Direct access local server example
Mapped NNI VLAN (no IP address) Management mapped VLAN (with IP address)
Server access VLAN A for legacy access port 1/1 Server access VLAN B for legacy access port 1/3
Mapped NNI (MLT)

1/1 1/2 1/3 1/4 1/5 1/6 1/7 1/8 8/1 8/2 8/3 8/4 8/5 8/6 8/7 8/8
Passport 8608 module
Passport 8608 module Metro ESM 8668
Legend Metro Ethernet Services Unit 1800 (Metro ESU 1800)

11261FA
User-to-network interface (UNI ID)

The UNI ID defines the physical demarcation point on the Metro Ethernet Passport 8600 Switch. The UNI ID also defines the service type that is associated with the current port. The ESU 1800 and the ESU 1850, and legacy module ports support only one UNI ID for each Port. Local TLS Ports support multiple UNI IDs for each ESM 8668 Port. Each UNI ID can be (either or all) Service Type, QinQ1, or QinQ2 on TLSSwitched. Note: If a UNI with service type TLS-Transparent is assigned to a Local TLS Port, another UNI ID cannot be assigned to the port. UNI IDs use IP notations, but for the Metro Ethernet Passport 8600 Switch, the UNI IDs are not used for routing packets.
This section includes the following topics: Switch UNI ID address range, next UNI configuration rules on page 122 UNI QinQ configuration rules on page 123 UNI customer IP VLAN rules on page 127
Switch UNI ID address range

The Metro Ethernet Passport 8600 Switch supports a 32-bit UNI ID address range. The supported UNI ID range is: 0.0.0.1 to 255.255.255.255
UNI configuration rules

Mixed UNI types are supported within the same Metro Ethernet network environment; however, the Optical Metro 1000 switch does not support mixed UNI types within the same network domain. For example, a transparent UNI on the Metro Ethernet Passport 8600 Switch cannot communicate with a mapped TDI on the Optical Metro 1000 switch if the Optical Metro 1000 switch is within the same Metro Ethernet network environment. Note: The Optical Metro 1000 switch uses the term "mapped UNI" to reference a UNI-type that switches customer traffic between TD domains, based on the packets q-tag. The term "mapped UNI" is equivalent to the term TLS-switched UNI on the Metro Ethernet Passport 8600 Switch. Mapped UNI is similar to IEEE802.1ad's customer-tagged service interface. You cannot assign a transparent-UNI and a switched-UNI to the same physical port, within the same Metro Ethernet Passport 8600 Switch. Also, you cannot change a UNI ID service type until you delete all instances of the UNI ID endpoints from all assigned TDIs. You must disable the endpoint, before you can make any of the following changes:
320747-A
Changes to class of service.
Changes to connection types. Changes to remote UNI (if connection type is point-to-point or spoke). Changes to USER-MAC entries static destination UNI MAC address Changes to default priority mappings. Changes to q-tags for TLS-switched UNI endpoints
Table 4 summarizes the maximum number of UNIs on a Metro Ethernet Passport 8600 Switch.
Table 4 UNIs on a Metro Ethernet PP8600 summary table
ESM port types Access Mode UNI service type QinQ(1) QinQ(2) TLS-switched TLS-transparent ESU ring ESU standalone Server Mode TLS-switched TLS-transparent Number of UNI 1 x GE SFP per ESM port 1 x GE SFP per ESM port 1 x GE SFP per ESM port 1 x GE SFP per ESM port Up to 336 TLS-transparent or 128 TLS-Switched UNI ports per ring 1x GE SFP per ESM port (Legacy GE can be used too.) Up to 128 TLS-switched UNI ports Up to 336 TLS-transparent See Note 1 See Note 1 See Note 2 See Note 2 Comments
Note 1: UNI ports are on the ESU. You need two ESM ports to terminate the ring. Note 2: All number based on Tested limit including up to 8 x GE port per Server port and/or 42 x 10/100 port per Server port.
UNI QinQ configuration rules

This section describes UNI QinQ configuration rules.
As a classification service
As a classification service, the QinQ UNI outer tag is not preserved. The following configuration rules apply: Connecting customer SVLAN networks together, between two TLS-switched UNI endpoints, is not supported.
Connecting customer SVLAN networks together, between two transparent UNI endpoints, is supported. For both QinQ types, the TDI mux configuration setting must be one-to-one before you can assign the QinQ endpoint to the TDI (many-to-one mux mode is not supported for this release).
Configurable SVID ethertype per port with SVID remarking on egress

The following configuration rules apply: The ethertype for SVID is configurable. The default ethertype for the outertag is 8020. On ingress, the customer outer tag ethertype must match the configured SVID ethertype, or the packet is dropped.
QinQ service types

Two QinQ service types are supported: QinQ(1) QinQ(1) is useful where an OEL2 network is used as the interconnecting medium for QinQ islands. This allows the SP to scale the QinQ network, as the 4K VLAN ID only has significance within each QinQ island. The OEL2 TDI acts as the network to translate provider VLAN IDs between various QinQ access network islands. QinQ(1) is also useful in scenarios where a long-haul carrier wants to classify and consolidate all customer traffic from different local SPs. Classification is made on first VLAN mux tag only (outer tag SVID). All other tags except the outer most tag, are ignored. QinQ(2) Classification is based on two tags. Both an inner-tag and outer-tag are required for packet classification. For QinQ(2) endpoints associated with same TDI and the same physical ESM 8668 port, inner-tag and the outer-tag must be unique. The following rules apply to the muxed VLAN tags for QinQ(2):
320747-A
The inner VLAN tag (CVID) must be Level 0 (8100 ethertype) or it is dropped. The outer VLAN tag must be the SVID (for provider VLANs). All outer tags can be the same, as long as the inner tag is different for each endpoint classification within the TDI. Figure 40 shows a graphic representation of QinQ UNIs service interworking and rules.
Figure 40 QinQ UNIs service interworking and rules
UNI UNI SP Network
Data CQtag Ethernet
Data CQtag PQtag Ethernet
Data CQtag MinM Ethernet
P-Qtag is stripped!!
Data CQtag Ethernet
Q-inin-Q(1) Q-inin-Q(2)
TDI 555
TlsTls-Transparent TlsTls-Switched TlsTls-Switched TlsTls-Transparent
TDI 766
Metro Ethernet Passport 8600 Switch Customer premise equipment (CPE)
SP Aggregation Switch (DSLAM)
QinQ classification rules

The following rules apply: The QinQ SVID and its associated ethertype is queried on ingress. The SVID is not transported across network. QinQ tags do not support q-tag 4096 (untagged or priority tagged SVID). All packets must be properly tagged with the outer q-tag for QinQ.
On egress of QinQ(2) endpoints, the customer q-tag ethertype must equal 8100 or the packet is dropped.
QinQ re-mapping rules on egress

The following rules apply: Q tag remapping: QinQ(1) Remapping of the customer VID is not supported for QinQ(1). The SVID is remapped on egress using the outer tag that is assigned to the egress endpoint. QinQ(2) The SVID is remapped on egress using the outer tag that is assigned to the endpoint. VID (or customer VID) remapping is supported and is remapped based on the endpoint q-tag setting. The SVID ethertype is remapped based on the egress ports endpoint outer tag ethertype setting. QoS mappings On egress, the OEL2 p-bits are transferred to the QinQ SPVID p-bits.
QinQ classification (for both Q1 and Q2 types)

ESM local ports that are directly connected to the Metro ESM 8668 module are capable of QinQ classification for both Q1 and Q2 types).
QinQ VLAN classification

QinQ VLAN classification is supported only on the Metro ESM 8668 module local access ports. QinQ traffic is not supported on the Metro ESU.
QinQ and Non-QinQ port combinations

The following rules apply:
320747-A
The following combinations are not supported:
Transparent to QinQ(2) QinQ(1) to TLS-switched Passport 8600 TLS-switched to QinQ(2): Untagged packets (q-tag classification 4096) are dropped on the egress QinQ(2) ports. The customer tag must exist with ethertype 8100 to egress QinQ(2) port. Untagged BPDUs are dropped at the egress UNI. One-to-one TLS-switched UNI ports must follow remapping rules for egress tagging. QinQ(1) to transparent: The outer QinQ tag is popped on ingress (the packet egresses the transparent port without changing the customer frame). Packets that egress the QinQ(1) port are tagged with the assigned SVID and Ethertype.
UNI customer IP VLAN rules

There is a one-to-one relationship between customer IP VLAN and SP IP VLAN on the same ESM local TLS port or standalone ESU port or pair of ESU ring ports on the Metro Ethernet Passport 8600. See Figure 41 to Figure 44 for various configuration. You can configure Ports 1/1 and 1/2 as local TLS or standalone ESU ports. To configure as local TLS or standalone ESU ports, replace port 1/1 and 1/2 with a pair of ports. For example: use 1/1 and 2/1 in any of the figures shown.
128 Configuration considerations and limitations Figure 41 Different customer IP-VLANs map to different SP-IP-VLANs
1/1
HOST: 10.10.10.10 CUST-IP-VLAN 100 HOST: 20.20.20.20 CUST-IP-VLAN 200 GW: 10.10.10.1 SP-IP-VLAN 10 GW: 20.20.20.1 SP-IP-VLAN 20
HOST: 30.30.30.30 CUST-IP-VLAN 300 HOST: 40.40.40.40 CUST-IP-VLAN 400
GW: 30.30.30.1 SP-IP-VLAN 30 GW: 40.40.40.1 SP-IP-VLAN 40
1/2 Local TLS and Standalone ESU Ports 8668 ESM

In Figure 42 on page 129, Customer IP-VLAN 100 maps to SP-IP-VLAN 10 on port 1/1 and maps to SP-IP-VLAN 30 on port 1/2.
320747-A
Configuration considerations and limitations 129 Figure 42 Same customer IP-VLAN maps to different SP-IP-VLANs on different ports
1/1
HOST: 10.10.10.10 CUST-IP-VLAN 100 HOST: 20.20.20.20 CUST-IP-VLAN 200 GW: 10.10.10.1 SP-IP-VLAN 10 GW: 20.20.20.1 SP-IP-VLAN 20
HOST: 30.30.30.30 CUST-IP-VLAN 100 HOST: 40.40.40.40 CUST-IP-VLAN 400

Figure 43 on page 130 and Figure 44 on page 131 illustrate the configuration where an SP-IP-VLAN (IP Subnet) spans more than one port.
130 Configuration considerations and limitations Figure 43 Same customer IP-VLAN maps to same SP-IP-VLANs on different ports
1/1
HOST: 10.10.10.10 CUST-IP-VLAN 100 HOST: 20.20.20.20 CUST-IP-VLAN 200 GW: 20.20.20.1 SP-IP-VLAN 20 HOST: 20.20.20.20 CUST-IP-VLAN 200 HOST: 30.30.30.30 CUST-IP-VLAN 300 GW: 30.30.30.1 SP-IP-VLAN 30 GW: 10.10.10.1 SP-IP-VLAN 10

In Figure 44 on page 131, Customer IP-VLANs 200 and 300 map to SP-IP-VLAN 20 on port 1/1 and port 1/2 respectively.
320747-A
Configuration considerations and limitations 131 Figure 44 ESU Ring8668 ESM
HOST: 10.10.10.10 CUST-IP-VLAN 100
ESU D
Primary
HOST: 20.20.20.20 CUST-IP-VLAN 200
Secondary
ESU D
ESU Ring - 8668 ESM
Transparent domain ID (TDI)

Transparent domains are the same as a broadcast domain (or VLAN) within a customer network. TDIs are also the same as VPNs for TLS services. These domains provide customer separation within a common SP network. This section includes the following topics: Rules for TDIs, next TDI mux mode on page 133
Rules for TDIs

All TDIs must reside in a mapped NNI VLAN. Only port-based VLANs are supported as mapped NNI VLANs for TDIs. When a TDI is created, it is added to mapped NNI VLAN 1 by default. VLANs assigned as mapped NNIs cannot be IP enabled.
All endpoints defined against a single TDI must be of the same connection type (for example, if an any-to-any connection type is defined first, all additional endpoints must be any-to-any). Note: Both point-to-point and point-to-multipoint are considered to be of the same connection type. TDIs with point-to-point connection type and spoke connection type ignore user-MAC entries for the TDI. Endpoints designated as point-to-point or spoke do not learn remote customer MAC addresses, all ingress traffic is forwarded only to the designated remote UNI for these endpoints. Note: Customer MAC address-related commands have no impact on endpoints configured as point-to-point or spoke connection types (refer to Legacy access port and services on page 147 for more details and exceptions).
320747-A
TDI mux mode

TDIs within the Metro Ethernet Passport 8600 Switch solution support two TDI mux-modes: one-to-one, and many-to-one (refer to TDIs on page 32 for detailed information about TDI mux-modes). These assignments are global to all endpoints assigned to the TDI within the Metro Ethernet Passport 8600 Switch. There are two types of TDIs that you can define: TDI one-to-one TDI many-to-one
Figure 45 shows the TDI types.

Figure 45 TDI types
VLAN10 VLAN20 UNI ID 0.127.1.5
VPN A
VLAN10 UNI ID 0.129.3.5 VLAN20 UNI ID 0.129.1.1 VLAN30 UNI ID 0.125.1.1
Point-to-point
Point-to-mulitpoint
VPN B
VLAN20 VLAN30 UNI ID 0.122.4.7
VPN C
Any-to-any UNI ID 0.123.5.1
VLAN30
TDI one-to-one
One-to-one TDIs support one q-tag classification per endpoint. If the UNIs defined for the endpoint are TLS-switched, each endpoint assigned to the TDI within the local chassis must have a unique q-tag. Figure 46 on page 134 shows the VLAN translation of the TLS-switched application.
For one-to-one TDIs, only one q-tag can be assigned to the endpoint. Packets egressing a one-to-one switched endpoint are remapped using the q-tag assigned to the endpoint. If a q-tag for an endpoint is 4096, the customer VLAN tag is popped and sent out untagged.
UNI Tls - Switched UNI Tls -Transparent
Figure 46 VLAN translation of the TLS-switched application
SP Network
Data V 10 Ethernet
Data V 10 TDI 200 Ethernet
Data V 20 Ethernet
TDI 200
Metro Ethernet Passport 8600 Switch Customer premise equipment (CPE)
QTAG Remapped
TDI many-to-one
Many-to-one is a special case where more than one q-tag can be associated with the same endpoint assigned to the many-to-one TDI. For many-to-one TDIs, you can assign multiple q-tags to endpoints. Remapping is not allowed. Q-tag 4096 is not supported with many-to-one endpoints. Note: The customer q-tag must match one of the endpoint q-tags or the packet is dropped. This rule applies to both ingress and egress paths.
320747-A
Endpoints
This section describes configuration rules that apply to endpoints. The following topics are included: BPDU forwarding feature, next Endpoints default COS profile on page 136 Q-tag 4096 - default VLAN for TLS-switched UNI on page 136 Hub and spoke on page 137 Local switching endpoints on page 137 Destination MAC table size on page 138
BPDU forwarding feature

Endpoints can be configured to: forward predefined system BPDUs normally; drop certain BPDUs; or expedite forwarding of certain BPDUs. The following BPDU addresses are filtered (per the endpoint BPDU forwarding setting): CISCO BPDU: 01-00-0c-cc-cc-cd STP/RSTP/MSTP: BPDUs: 01-80-c2-00-00-00 All bridges: 01-80-c2-00-00-10
The following BPDU forwarding settings apply to all packets with destination MAC addresses, as noted in the above list: Normal - BPDU packets are forwarded normally. Drop - all matching destination BPDU packets are dropped. Expedite forwarding - this option raises the QoS level for the above listed BPDUs to the highest level defined for the endpoints QoS default-profile setting.
The following rules apply to BPDUs: For spanning tree groups, only STG 1 is supported in accordance with IEEE 802.1s untagged packets. Transparent UNIs forward all BPDUs over the same TDI that is assigned to an endpoint.
For TLS-switched UNIs BPDUs are only forwarded if q-tag 4096 is assigned to the endpoint. Nortel recommends that a separate TDI be assigned for q-tag 4096 to handle untagged BPDUs on separate paths. Tagged BPDUs that ingress a UNI are only forwarded if the BPDU q-tag matches an end-point with the same q-tag assignment.
Specific BPDUs are tagged and given highest priority mapping only when you enable expedite forwarding. For QoS remapping, the highest SP QoS remapping defined in the default profile is used. For example, if the highest SP assignment on any one of the default profile position is 5, then 5 is used.
Endpoints default COS profile

The default COS profile is named DEFAULT_PROFILE and is assigned to each endpoint that you create. Unless you change this default profile, or you create a different COS profile and assign the profile before you enable the new endpoint, the following default QoS values apply: All QoS default UNIT values are set to 64K. All QoS levels are set to 15 (sets policed rate to 960K). CIR level is set to 0 by default for all upper level COS values. All upper level COS values are allowed to burst up to the maximum PIR value for the COS profile.
For more information on overall operation and capabilities, refer to Metro Ethernet Passport 8600 Switch QoS on page 153.
Q-tag 4096 - default VLAN for TLS-switched UNI

You can assign q-tag 4096 to a one-to-one endpoint to classify untagged packets that ingress a TLS-switched UNI port. On egress, when you configure an endpoint as one-to-one and you the assign the endpoint q-tag as 4096, if the customer packet includes a q-tag, the tag is popped before the packet egresses the port.
320747-A
If you do not configure the TDI as one-to-one, and the customer record includes a q-tag, the packet is dropped. Q-tag 4096 classification of SVID is not supported for endpoints defined as QinQ.
Hub and spoke

The following list describes important considerations and limitations rules for hub-and-spoke configurations: The hub is the central point of connectivity to all spokes. Only one hub can exist in a properly defined hub-and-spoke network. Spokes only receive packets from hubs. Packets received from other spokes are dropped. Spokes require a specific remote UNI ID to be assigned before the endpoint can be enabled (the remote UNI ID must be that of the hub). Multiple spoke endpoints are allowed on a single hub TDI endpoint (unlike point-to-point). If a spoke is configured to dynamically learn the hubs remote UNI ID, the spoke learns the hubs MAC address, stops learning, and does not age the learned hubs MAC address. However, the hub always operates similar to an any-to-any connection type and ages out the learned customer MAC address for each spoke. There can only be one hub in a TDI domain. If a network environment has more than one hub, the spoke could become disjointed. A spoke does not verify remote UNI IDs on egress.
Local switching endpoints

Local switching is defined as any traffic that is switched between two intra endpoints, on the same local Metro Ethernet Passport 8600 Switch. Local switching is only supported between two physical ports on the same chassis. Local switching is supported in the following configurations: Between two ESM local ports Between two Metro ESM ports on the same ring or between rings
Between TLS-switched endpoints assigned to the same ESM local port
Local switching is not supported in configuring switching between QinQ endpoints assigned to the same ESM local port.
Destination MAC table size

Each UNI endpoint maintains an independent MAC table, and the maximum table size is directly proportional to the number of UNI endpoints that are associated with a Metro ESM 8668 port. Each Metro ESM 8668 port supports a total of 97 000 unique-destination MAC entries. If the endpoints within the same TDI are associated with different Metro ESM 8668 ports, the MAC tables are managed separately, and each UNI endpoint separately learns about the destination UNI. For example, if UNI 1 on Metro ESM 8668 port 1 sends a multicast OEL2 packet to destination X, when destination X responds with a unicast packet, only the UNIs on Metro ESM 8668 port 1 learns about destination X on port 1. If UNI 2, in the same TDI on Metro ESM 8668 port 2 sends a packet to destination X, the packet from UNI 2 is multicast towards destination X, not unicast. All UNI endpoints allow the MAC table size to float between 0 and up to 100 000 entries. Each UNI endpoint can also manage a high watermark for the UNI. When an endpoint is assigned a specific table size and a high watermark percentage value, if the endpoint exceeds the watermark size and the total number of MAC entries exceeds a predetermined percentage of the table size defined, an SNMP trap is sent to the NMS fault applications. The trap states the total number of learned MAC entries has exceeded the high watermark. By default, the watermark is set to 0%, thus disabling the trap message. If a high watermark is configured for the endpoint, and the MAC table is full for the specified endpoint, all MAC learning is disabled until enough MAC entries age out to drop the count below the high watermark. When MAC learning is disabled, all learning is disabled for the assigned endpoint. MAC address changes
320747-A
for remote UNIs; new destination MAC addresses and unknown destination MAC addresses are ignored while learning is disabled. Customer data packets received by an endpoint with a full MAC table drop the packet on receipt until MAC learning is restored. Note: When MAC learning is disabled, MAC aging continues. It is possible that some known MAC destinations ages before MAC learning is restored. This results in the loss of customer data traffic until the MAC table size falls below the defined watermark. When multiple endpoints are associated with an Metro ESM 8668 port, the sum of the total MAC table size for each assigned UNI endpoint cannot exceed 97 000 entries. If all endpoints have been assigned specific table sizes and the sum equals 97 000 entries, all new endpoints that are assigned to the Metro ESM 8668 port use the default MAC table entry of 0, which allows the table size to float between 0 and 97 000 entries.
NNI ports
The network-to-network interface (NNI) ports are used to forward into and transport customer separate traffic over a common SP network. The NNI port must be set to perform tagging (enabled). The VLAN assigned to B-router port or MLT group of NNI ports is also the management NNI VLAN ID. VLANs with an IP address cannot be assigned to TDIs as a mapped NNI Any VLAN assigned to a TDI as mapped NNI cannot participate within other generic bridged services within the chassis.
Mapped NNI VLANs are used to interconnect OEL2 packets between remote endpoints. These are Layer 2 only VLANs and, as such, NNI VLANs do not participate within any routing protocols within the SP network or customer network.
Static destination UNIs and endpoints

This section describes configuration rules that apply to static destination UNIs and endpoints. This section includes the following topics: Predefining static UNIs, next Any-to-any static destination tables on page 141 UNI-MAC on page 141 Destination-UNI on page 142 User-MAC on page 143 Static destination UNI and ring access ports on page 144
Predefining static UNIs

The Metro Ethernet Passport 8600 software allows SPs to predefine destination UNIs, static entries for UNI MAC addresses, and to assign specific customer MAC entries to specific UNIs. There are two types of static UNIs: Any-to-any (including hubs) Point-to-point (including spokes)
In a dynamic learning environment, packets enter with customer destination MAC addresses. The software searches the customer-learned MAC address table for the destination MAC address and, if it exists, the software uses the destination UNI ID that is assigned to the customer-learned destination MAC address. With the UNI ID available, the switch searches the UNI-MAC table to find the unicast MAC address of the remote destination UNI ID and, if found, the switch places the UNI IDs unicast MAC address into the destination MAC header of the OEL2 packet that egresses the NNI port.
320747-A
Any-to-any static destination tables

For any-to-any static destination UNI entries, three tables are used to associate a remote endpoints destination UNI: UNI-MAC table This table is a static MAC address for destination UNIs. This table holds all destination UNI MAC addresses. Static UNI-MACs are only associated with static destination UNI entries. It does not override the customer MAC learning database unless a USER-MAC entry is made for the specific TDI. Destination UNI table This table is a static destination UNI table for the TDI. All customer packets ingressing a TDI with destination UNIs assigned are restricted to this set of destination UNIs. No dynamic learning of destination UNIs is allowed for the TDI once destination UNIs are defined. User-MAC UNI table This table is a static customer MAC table where explicit customer destination MAC addresses are assigned to a specific UNI ID (static destination UNI ID). When a static customer destination MAC address is assigned, the destination address does not age, and does not dynamically update in the event the remote destination hosts moves between UNI IDs.
UNI-MAC
The UNI-MAC address defines the explicit MAC address for the SP far-end UNI ID where the customer packet terminates (the customer destination UNI). UNI-MAC entries reside in a UNI-MAC table for all learned or statically defined UNI ID addresses. UNI-MAC is global to the chassis and not to the TDI or endpoint. When you define a MAC address for the UNI MAC, use the Metro ESM 8668 port where the UNI is attached.
A static UNI-MAC only defines the OEL2 destination MAC address for a statically defined destination UNI. There is no correlation between dynamic learned customer destination MAC and UNI-MAC at the global level. If a UNI-MAC entry has not been assigned to the destination UNI ID table for a TDI or if a UNI MAC entry has not been used for a USER-MAC table entry, the static destination UNI-MAC is ignored for both ingress and egress traffic and customer destination MAC learning functions normally for the endpoint. Static destination UNI and static USER MAC entries are not allowed to be assigned to TDI unless there is an associated UNI-MAC entry with a unicast MAC address defined for the destination UNI ID.
Destination-UNI
Destination UNIs are defined for each TDI. All endpoints that are assigned to the TDI use the destination UNIs just as if the UNIs had been learned for all endpoints assigned to the TDI. You cannot add a destination UNI ID to a TDI until there is a corresponding UNI-MAC entry for the static destination UNI ID. When you add a static defined destination UNI ID, OEL2 packets cannot multicast out the NNI port. However, the Layer 2 bridge's within the mapped NNI VLAN domain broadcasts unknown destination unicast MAC addresses. This is according to standard Layer 2 rules. The destination UNIs for a given TDI override all learned UNIs for that TDI. If customer MAC-learning has dynamically learned a destination UNI, and if a destination UNI ID is added to the TDI that is other than the learned UNI ID, the learned UNI ID is ignored on the next packet transfer. All packets use the statically defined destination UNI after an entry is complete. In cases where more than one destination UNI is defined for the endpoint and the customer MAC address has an unknown destination UNI ID (in the customer destination MAC table), the VPN replicates the customer packet n* (n=number of destination UNIs assigned to TDI) and sends each packet out with the destination UNI static unicast MAC address.
320747-A
For example, if there are four static destination UNIs, four unicast packets are created using the static destination UNIs defined for the TDI. Each packet is sent out with its static unicast MAC address (from the UNI-MAC table). Caution: Too many destination UNIs can create a large broadcast flow if the OEL2 destination is unknown to the various bridged nodes within the mapped NNI network. Also, throughput performance can degrade if the customer destination is unknown because each replicated OEL2 packet consumes switch fabric bandwidth and NNI bandwidth.
User-MAC
You must assign the user-MAC address on a per TDI basis, within the same chassis. The user-MAC address is used to statically define a destination UNI ID to a customer destination MAC address. You cannot add a user-MAC destination UNI ID binding to a TDI until there is a corresponding UNI-MAC entry for the static destination UNI ID. User-MAC addresses consume considerable MAC table space. Every entry counts towards the total allowed MAC entries in the Metro ESM 8668 port MAC table for all endpoints within the TDI. If the total number of user-MAC entries exceeds the MAC table size for a given UNI, all static MAC entries are entered, but the endpoint disallows the learning of new MAC entries and MAC changes (including UNI ID changes). When you add a static defined USER MAC and destination UNI ID, OEL2 packets never multicast out the NNI port. However, the Layer 2 bridge's within the mapped NNI VLAN domain broadcasts unknown destination unicast MAC addresses. This is according standard Layer 2 rule. User-MAC entries override any dynamically-learned customer destination User-MAC addresses. The user-MAC addresses are locally significant to the TDI, but do not affect other non-static destination MAC address that ingress the TDI. For all non-static destination MAC addresses, normal dynamic learning applies for the customer MAC entry.
Static destination UNI and ring access ports

This section describes what happens if the ESU-ring fails and the remote endpoints are configured with static destination UNIs. The ESU-ring is designed as a bi-directional transport. For example, packets originating on the ring enter the Metro Ethernet Passport 8600 Switch through the Secondary port. Packets destined to UNIs on the ring enter the ring through the Primary port. The MAC address of the Primary port is used for the static destination UNIs. A ring failure is considered to be either a single mid-span cut, or a single Metro Ethernet Passport 8600 Switch access port failure (multiple cuts can result in unpredictable results). If a ring failure occurs mid-span, static VPNs and VPNs with remote UNIs continue to be sent to the physical Primary ring port. The Metro ESM 8668 module properly forwards the packet, depending on which side of the break the MOD-ID is destined for. If the MOD-ID is on the side of the break that is not reachable by the Primary port, the Metro ESM 8668 module forwards the customer packet back to the switch fabric, and out to the Secondary port. If the ring failure is on the Primary ring port, the intended Primary port MAC address is reassigned to the designated Secondary port. The legacy forwarding tables view both the original Primary MAC address and Secondary MAC address as being assigned to the same port (the ring Secondary port). When the Primary port recovers (link up), the legacy port redefines the forwarding entry back to the original port designated as the Primary ring port.
Point-to-point UNIs
This section describes configuration rules that apply to point-to-point UNIs. The following topics are included: Configuring a remote UNI ID, next Remote MAC address rules on page 145 Defining a remote MAC address for a remote UNI on page 146
320747-A
Configuring a remote UNI ID

You must define a remote UNI ID to a point-to-point endpoint before you enable the endpoint. To change the remote UNI ID, you must disable the endpoint first. To remove the remote UNI ID, you must delete the endpoint first. Note: These same rules apply to spoke connection types.
Point-to-point and spoke connection types do not learn customer MAC entries. All circuits are locked to the remote UNI ID that is defined when you create the endpoint. MAC aging, table size, and watermarks for the endpoint do not apply for point-to-point and spoke connection types. When you assign a remote UNI ID, the remote UNI MAC address provision is optional. If no address is defined, the OEL2 packet broadcasts using a multicast Layer 2 record, but the destination UNI field within the OEL2 record is the same as the defined remote UNI ID. Although the packet is broadcast throughout the network, the packet is only forwarded out to the ports that match the destination UNI in the OEL2 header. When the endpoint with the defined remote UNI responds, the local endpoint statically learns the remote UNI MAC address and uses the MAC address as the unicast destination MAC address for all packets forwarded to the defined remote UNI. After the MAC address is learned, all learning is disabled and the MAC address for the remote UNI does not age. If you assign a UNI MAC address when you enter the UNI ID, all OEL2 packets are forwarded as unicast packets to this static UNI ID MAC address. With the UNI ID MAC address inserted, UNI MAC learning is disabled.
Remote MAC address rules

To change a static remote UNI MAC address, you must first disable the endpoint before you can change the remote UNI MAC address. If the remote UNI MAC address changes:
If no static remote MAC address is configured, you must first disable, and then enable the endpoint. The previously learned remote UNI MAC address is then flushed. All packets for the point-to-point circuit are multicast until the remote responds, allowing the local endpoint to learn remote UNI MAC address.
If the point-to-point connection type includes a static remote UNI MAC, you must disable the endpoint first, before you can change the remote UNI MAC address. To reconfigure a new remote UNI ID and a new MAC address, you must first delete the endpoint, and then create a new endpoint.
Defining a remote MAC address for a remote UNI

The statically defined remote UNI MAC address depends on where you want the packet to exit. Use any of the following port types to identify the proper MAC address for the remote UNI:
For:
remote UNI on the Metro ESU in ring configuration, use the MAC address of the Primary ring port. Remote UNI on Metro ESU standalone port, use the MAC address of the Metro ESU port defined as standalone. Remote UNI on ESM local port, use the MAC address of the Metro ESU module port defined as the local access port. Remote UNI on generic TLS access port, use the MAC address of the assigned server port module on the Metro ESU.
320747-A
Legacy access port and services

This section describes configuration rules that apply to legacy access ports and services. The following topics are included: ESM server port (new port-type), next Legacy access port setup and rules on page 148 Legacy access ports and spanning tree on page 149 MAC aging for legacy access ports on page 150
ESM server port (new port-type)

The Metro ESM 8668 module can directly extend the capabilities of a physical Passport 8600 legacy line-card access port to the NNI trunk port(s). With the Metro Ethernet Passport 8600 Release 3.5, the Metro ESM 8668 module supports a port-type known as the server port (hereinafter referred to as the ESM server port). The ESM server port has no physical connectivity outside of the chassis, thus rendering it portless. The ESM server port receives all of its data traffic over the backplane from the switch fabric. This method of receiving the data traffic introduces two new traffic stream concepts to the ESM server port: Server-port access traffic streams. Server port access traffic stream (SPATS) is a stream of packetized data traffic that is received from the customer network through a legacy access port, and is then directed to the NNI trunk ports as OEL2 packets by the ESM server port. ESM server port trunk traffic streams. The server port trunk traffic streams (SPTTS) are OEL2 packets that are received from the NNI trunk ports, which reside on another set of legacy ports, and are directed towards the associated legacy access port as un-encapsulated customer traffic by the ESM server port.
The Metro ESM 8668 module allows multiple legacy access ports to be associated with the ESM server port. This significantly increases the overall scalability of the Metro ESM 8668 module access ports when using 10/100 Ethernet ports. When a Metro ESM 8668 port is defined as a ESM server port, direct connections to the local Gigabit Ethernet ESM server port are not allowed. In this mode, an SFP GBIC is not required for ESM server ports. You can assign one or more legacy ports to the ESM server port using Server Access VLANs (refer to Mapped NNI VLANs on page 118 for more information). This allows more physical access ports to be fanned out or concentrated across a single service module port, allowing for higher port density, such as the use of multiple 10/100 ports. There are no restrictions on the number of legacy access ports that can be associated with an ESM server port. However, when a Metro ESM 8668 port is defined as an ESM server port, direct connections to the local Gigabit Ethernet ESM server port are not allowed.
Legacy access port setup and rules

When you create a legacy access port, several rules apply: Each legacy access port must reside in a unique default VLAN, known as a server-access VLAN. All legacy access ports must be configured to support tagging, even if the port participates as a transparent port with untagged packets. A server access VLAN supports one legacy port and one ESM server port. You must configure the ESM server port as a server-enabled port before you create UNIs with legacy access ports. Use the following steps to create a legacy access port: 1 2 3
320747-A
Identify the legacy port and the Metro ESM 8668 port that used as the ESM server port. Enable tagging on the legacy port. Set server-enable to true on the Metro ESM 8668 port.
Create the server-access VLAN. The server-access VLAN must be port-based and the VLAN-ID must be greater than 1.
5 6 7 8 9
Assign the legacy port to the server-access VLAN. Create the UNI. Assign the legacy port to the UNI first. Assign the ESM server port to the UNI. Set the UNI service type, and then enable the UNI. Note: Nortel recommends that after you assign the legacy port to the server access VLAN, remove the legacy port from VLAN 1 to avoid confusion in the configuration files and to reduce undesired traffic from bypassing the VPN.
Legacy access ports and spanning tree

When a legacy access port is assigned to a UNI with a server port, the spanning tree operations for this port changes. All spanning tree 1 BPDUs are forwarded to the ESM 8668 server port, even if spanning tree is enabled on the Metro Ethernet Passport 8600 Switch. Legacy ports use a distributed MAC table database. If any legacy access port reaches the maximum for hardware forwarding entries within the chassis, all legacy access ports discontinue to learn new MAC addresses. Note: This limitation does not affect Metro ESM 8668 ports that are designated as local TLS or ports that are assigned to an ESU-ring and standalone services. By default, legacy access ports are configured to reserve space for only 2000 MAC entries. Use record-reservations to change the desired minimum requirement if the UNI endpoint assigned to the legacy access port has more than 2000 MAC addresses.
When a legacy access port exceeds the hardware forwarding limit, all unlearned customer destination packets continue to be directed to the ESM server port, but the packets take a broadcast path within the switch fabric.
MAC aging for legacy access ports

The Metro ESM 8668 and Passport 8600 series legacy modules learn, and age forwarding records differently. Legacy modules use a distributed database with aging assigned per VLAN, whereas the Metro ESM 8668 ports learn independently and age MAC addresses per endpoint assignment. When multiple endpoints are assigned to a single legacy access port, the endpoint with the highest remote MAC aging timer is used to age all destination MAC entries learned. For access ports, the local MAC aging timer is not supported because legacy ports do not differentiate between locally learned MAC addresses and remote MAC addresses.
Managing the Metro Ethernet switch

Access to Metro Ethernet Passport 8600 NMS Services is available through NNI ports. All IP management traffic that egresses the NNI port are tagged using the VLAN ID that is assigned to the b-router port or to the multilink trunk (MLT) group. Nortel recommends that you use the new IP VLAN Management Support when managing edge devices. Only out-of-band is supported for Dual Home Rings. Out of Band L2 VPN is supported to maintain backward compatibility.
320747-A
Edge-device management
For this release, management of attached carrier located equipment (CLE) devices can be in-band or out-of-band.
Out-of-band L2 VPN management

To manage the Metro Ethernet Services Unit (ESU), assign port 28 for the ESU ring and ESU standalone port types, and then assign the ports to the TDI as follows: Terminate the management TDI in a central office where connectivity to the networks operations center exist: For example, use a Metro Ethernet Passport 8600 Switch to terminate the management TDI. Set the device to terminate at the NOC Center network for management devices. For legacy access ports with TLS-switched UNI service type, the attached device must support tagged IP packets to- and from- the CLE device CPU. Device management of CLE devices that are attached to the transparent TLS access-ports is not supported.
Metro ESU port rules

This section describes port configuration rules for the Metro Ethernet Service Unit. This section includes the following topics: Valid UNI port numbers, next Ring port connections on page 152 IP management on page 152 Standalone configuration on page 152
Valid UNI port numbers

Valid UNI port numbers for the ESU 1800 are ports 1 through 24 for Fast Ethernet ports, and ports 25 and 26 for the Gigabit ports. Valid UNI ports for the 1850 are ports 3-12 with the optional MDAs installed for ring and stand alone.
Ring port connections

There is no hierarchy for ring port connections. The Primary ESM port for the ESU 1800 can connect to either gigabit port 25 or port 26. The primary ESU port for the ESU can connect to either gigabit port 1 or 2. Note: Nortel recommends using a common and consistent scheme, where the Primary port is always connected to the same Metro ESU port. This applies to all Metro ESU access rings (for example, Primary always connects to Metro ESU 1800 port 25, and the Secondary always connects to Metro ESU 1800 port 26). This practice simplifies troubleshooting and is good network design practice.
IP management
Port 28 is reserved for Metro Ethernet Service Unit IP management (used for in-band IP VLAN or out-of-band TDI management).
Standalone configuration
ESU 1800 supports Ports 1 to 24 FE 10/100, and one gigabit port as Access Port in standalone mode. ESU 1850 supports ten gigabit ports 3-12 in standalone mode and these can be any combination of fiber and copper.
320747-A
Metro Ethernet Passport 8600 Switch QoS

This section describes QoS queue configuration rules that apply to the Metro Ethernet Passport 8600 Switch. This section includes the following topics: Metro Ethernet services configuration, next 802.1q p-bit override option on page 155 TLS-priority override attribute on page 156 Metro 8600 QoS mapping on page 157 Metro ESU QoS on page 161 Metro ESU egress queueing for untagged packets on page 162
Metro Ethernet services configuration

The Metro Ethernet Passport 8600 Switch performs QoS services differently from the standard Passport 8600 Release 3.5 mode of operation, with the exception of packets that ingress the legacy NNI ports. In this case, packet classification, filtering and remarking are the same as in the Passport 8600 Release 3.5 operation. For packets entering the UNI side of the Metro Ethernet Passport 8600 Switch, through the Metro ESM 8668 ports or the legacy ports, the mode of operation is similar to the Optical Metro 1000 QoS methodology. This section includes the following topics: General QoS rules, next Metro Ethernet services DiffService on page 154
General QoS rules

QoS is always enabled on the UNI ports, and cannot be disabled. There are only four strict priority queues within the switch fabric per customer endpoint.
All ingress UNI ports trust the customer QoS markings (software does not modify customer QoS markings). The QoS markings remap the OEL2 SP p-bits and TOS bits per default-profile map for the endpoint the packet enters. DSCP interpretation and classification is based on the class selector code points (CS) standard. Only the three most significant bits of the TOS header are used to define the QoS level when DSCP/TOS is used to map per-hop behavior (PHB).
Metro Ethernet services DiffService

The Metro ESM 8668 ports on the Metro Ethernet Passport 8600 Switch are used to encapsulate customer traffic for VPN based services. Encapsulated traffic and IP routed traffic are handled differently for QoS. When traffic enters an Metro ESM 8668 port, all customer traffic is considered marked by a trusted source. In this mode, the DiffServices operates in a core mode (TOS/p-bits); for example, the received TOS/p-bits are trusted. QoS classification on ingress of a local TLS access and an ESM server port is enabled at all times (it cannot be disabled).
NNI bridged packets (ingress to NNI):

All NNI ports must be configured according to QoS configuration rules. For more information, see Configuring QoS and IP Filtering, Passport 8000 Series Software. By default, Diffservices is disabled on legacy ports and ingress NNI traffic is not classified for QoS. Both core and access DiffServ modes act differently at the NNI port: DiffServ core port: OEL2 Packet Internal QoS is classified by TOS bit settings only. P-bits are ignored. DiffServ access port: OEL2 Packet Internal QoS is classified by p-bit settings only. TOS bits are ignored
320747-A
802.1q p-bit override option

The p-bit override function defines when p-bits or IP TOS (DSCP) bits should be used. This is a QoS classification rule only, not a remarking tool. The p-bit override function is disabled, by default. Note: If the UNI port type on the Metro Ethernet Passport 8600 switch is ESU ring or ESU standalone, and the Metro ESU ports are remarking customer QoS traffic (because the port is considered untrusted), Nortel recommends that you leave the 802.1q override option disabled. This section includes the following topics: Override disabled, next Override enabled on page 155 Override option for QinQ ports on page 156
Override disabled
On ingress, the tag header (802.1q) p-bits from each received packet is used for QoS classification. For mapped endpoints, if a packet is untagged and TDI maps to 4096, the p-bits are assumed to be the same as TOS IP precedence bits; but if the packet-type is not IP, the TOS is zero. The p-bits are then used to define the per-hop behavior by associating the p-bit value with the COS profile mappings for the endpoint. For local TLS-transparent endpoints, the p-bit rules are the same as noted above; but if packet enters the transparent endpoint untagged, and if the packet-type is IP, the customer TOS IP precedence bits are used for classification; if the packet-type is not IP, the p-bits are assumed to be zero.
Override enabled
If p-bit override is enabled, only the TOS/DSCP bits are used from the customer packet, regardless of whether it is tagged or untagged. If the packet-type is not IP, the TOS/DSCP bits are assumed to be zero.
Override option for QinQ ports

QinQ(1): The p-bit override option is not supported on ports configured for QinQ(1). QinQ(2): When the p-bit override is disabled, the p-bit classification is based on the SP tag (the outer tag) only. If p-bit override is enabled, the TOS/DSCP bits are used from the customer packet. If the packet is not IP, the TOS/DSCP bits are assumed to be zero. Note: The inner q-tag for a QinQ(2) UNI must have the Ethertype ID provisioned on the first inner tag as 0x8100. The outer q-tag Ethertype value must match the Ethertype ID assigned to the UNI ID. Any exceptions are dropped. The UNI endpoint only accepts packets on QinQ(2) UNI ports that have the Ethertype provisioned on the first inner tag as 0x8100 and on the outer tag add a value matching the Ethertype assigned to the UNI_ID. Any exceptions are dropped.
TLS-priority override attribute

This feature allows SPs to override customer priority marking when queuing packets from legacy port to ESM port, even though DiffServ access is enabled. A new attribute known as TLS-Priority-Override has been added. This attribute applies to all packets arriving at the port. When TLS-Priority Override is enabled, the legacy port is not available for tagged based bridging. The following rules apply: Legacy access port must be DiffServ access or DiffServ disabled Attribute is enabled on a per-RaptARU basis Ethertype header for q-tag is changed to 9100. Therefore, this affects eight ports at a time if 8648TX card is used Ports can still be directed to different server ports, and can still have a different override priority for each port
320747-A
It is not recommend that any of the ports be in that group of eight for normal bridging.
Metro 8600 QoS mapping

QoS priority mapping on ingress of UNI endpoint and OEL2 QoS remarking is per ingress endpoint. When an endpoint is created, a default priority mapping is created for the endpoint. The default mapping follows the (Nortel) Metro Ethernet Solutions QoS mapping (as described in Metro 8600 QoS mapping on page 157). This section includes the following topics: Endpoint priority mapping, next QoS remapping on egress on page 160 ESU default mapping on page 161
The Metro Ethernet Services Unit supports IEEE 802.1p priority queuing. Filters can be used to remap the QOS levels based on various matching criteria, which include VLAN, TOS bits, and customer tagged p-bits. The ESU 1800 switch has four hardware-based priority queues for each port. These priority queues are numbered from zero, the lowest priority queue, to three, which is the highest priority queue. The eight priority queues specified in IEEE 802.1p (queues 0 to 7) are mapped to the switch's four priority queues. The ESU 1850 switch has eight hardware-based priority queues for each port. These priority queues are numbered from zero, the lowest priority queue, to seven, which is the highest priority queue. To maintain backwards compatibility, the ESU 1850 is configured by default to only use the first four priority queues from zero to three, but the user can configure the higher queue levels as needed. The factory default for the ESU 1850 assigns the eight priority queues specified in IEEE 802.1p (queues 0 to 7) to the lower four priority queues. Packets entering a Metro Ethernet Services Unit are queued at the ingress port based on the priority of the packet as indicated in the customers pbit. When the customers packet is untagged, queuing is based on the default port QOS value. When packets enter an ESU ring, the queue assigned is based on the tagged value
that was originally assigned in the customer packet when it entered the service provider network. If the customer pack was untagged, before the packet will egress into the ring, the Metro Passport 8600 will mark the packet with the same QOS level assigned by the service provider packet.
Endpoint priority mapping

Each endpoint has a configurable SP priority mapping field. When you create an endpoint, the priority-mapping field is used to designate the QoS level for the packet as it egresses the mapped NNI port. The priority-mapping field is also used for marking the OEL2 packets on egress into the SPs NNI network. The priority-mapping field comprises 8 mapping levels. Each position, from left to right, is associated with an 802.1p numerical value (from 0 to 7) or TOS IP precedence value if the 802.1p override is enabled. Each numerical value represents the remapped p-bit and TOS value, which is assigned to the OEL2 packet. When the customer packet enters the Passport 8600 Switch, the customers QoS value is translated into this service priority QoS level. The default endpoint priority mapping appears as follows: Priority mapping 0:0:2:4:0:6:6:7 In the above mapping, if a customer packet enters with a QoS level of 3 (for example, p-bit 3 or TOS precedence 3), the priority mapping assigns the packet to QoS level 4 and marks the OEL2 packets p-bits and TOS bits with 4. Table 5 shows the default priority mappings and queue assignments:
Table 5 Default priority mapping and queue assignments
Customer Customer DSCP TOS1 802.1p level 000xxx 001xxx 010xxx 011xxx 100xxx 101xxx 0 1 2 3 4 5 BE AF1 AF2 AF3 AF4 EF OEL2 OEL2 SPVID TOS remarking remarking 000000 000000 010000 100000 000000 110000 000 000 010 100 000 110 OE QoS queue 0 0 2 4 0 6 OE queue priority Standard Standard Silver Gold Standard Premium
320747-A
Configuration considerations and limitations 159 Table 5 Default priority mapping and queue assignments (continued)
Customer Customer DSCP TOS1 802.1p level 110xxx 111xxx
1
OEL2 OEL2 SPVID TOS remarking remarking 110000 111000 110 111
OE QoS queue 6 7
OE queue priority Premium Premium
6 7
NC2 NC1
x = any bit from 0 to 1.
The OE-QoS queue field represents the endpoints priority-mapping field. The QoS levels (0-7) represent the desired QoS level on egress and the OEL2 packet re-markings. For example: If the 802.1p override is enabled, and the TOS bits are 101(5), the SP QoS mapping translates to 6 (per the above default mapping). If the 802.1p override is disabled, and a customer packet enters the Passport 8600 Switch with p-bits set to 011(3), the service priority mapping translates to 4. The mapping marks both the OEL2 header SPVID p-bits and the OEL2 TOS field with the same mapping. Table 6 shows the default ESM internal QoS to SP priority markings. This feature maps internal QoS to SP (MiM) priority marking at the NNI. The single profile for the whole chassis is configurable. Note that queuing at the NNI port is still based on internal QoS value.
Table 6 Default ESM internal QoS to SP priority markings
Internal QoS Value SP (MiM) p-bit 0 1 2 3 4 5 6 7 1 0 2 3 4 5 6 7 SP (MiM) DSCP 0 0 10 18 26 34 46 46

NOTE: P-Bits and QOS values 0 & 1 inverted to IEEE standards. Per standards, 0 is best effort, 1 is standard (weighted). Default PP8600 QOS port settings were defined as 1 prior to IEEE standards.
Table 7 shows the Passport 8600 default DSCP internal QoS to SP priority markings. DSCP internal QOS values DO NOT correspond to the same internal QOS values assigned to P-Bits. DSCP equivalent QOS values are one level higher than P-bits. For example, a TOS setting of 001000 (best effort for P-bits) maps to Silver when it ingresses an NNI port with DiffServ enabled.
Table 7 Passport 8600 default DSCP internal QoS to SP priority markings
Internal QoS value 1 2 3 4 5 6 7 7 SP-TOS and ingress map 000000 001000 010000 011000 100000 101000 110000 111000 Corresponding SP P-bit 0 1 2 3 4 5 6 7
QoS remapping on egress

Although there is no egress map to remark customer packets that exit the VPN, the customer QoS settings are preserved end-to-end. There are two exceptions to this rule: Untagged customer packets that egress a TLS-Switched UNI with remapping enabled: When a new VLAN shim is added to support remapping of an untagged packet to a tagged network, the VLAN p-bits are set to 0. Customer TOS bits remain unchanged end-to-end. QinQ services. For packets that egress QinQ(1) and QinQ(2) ports, an S-tag is added to the packet (known as the outer tag) when the packet egresses the Metro Ethernet Passport 8600 Switch ports.
320747-A
When the new QinQ SP tag (outer tag) is added, the OEL2 SPVID p-bits are transferred to the QinQ S-tag p-bits.
ESU default mapping

Table 8 shows the mapping of VLAN 802.1p bits that is performed for directing classified traffic to the appropriate output queue.
Table 8 VLAN 802.1p bit mapping
DSCP NC1 NC2 EF AF3 AF2 AF4 AF1 BE 802.1p 111 110 101 011 010 100 001 000 Queue number 3 3 3 2 1 0 0 0 Queue priority High High High Video Medium Low Low Low NNSC Premium Premium Premium Gold Silver Standard Standard Standard
Note: When an edge device (the Metro ESU) is used to only remark customer p-bits before forwarding, the aggregation device (the Metro Ethernet Passport 8600 Switch) must be configured with 802.lq override disabled. When the 802.1p-bits are remarked, but the TOS bits remain unchanged, the VPN QoS classification can be invalid if "802.1q override" is enabled.
Metro ESU QoS

The Metro ESU 1800 switch supports four output queues per port and the Metro ESU 1850 switch supports eight queues per port. Each queue is mapped to one of eight QoS levels, and are serviced using guaranteed Weighted Round Robin (WRR). This mechanism ensures strict priority for the queues that are assigned the highest priority, proceeding to the lowest priority queue before returning to the highest priority queue.
The Metro ESU supports one strict-priority queue and three queues for WRR. When the packet transmit opportunity that is allocated to a particular time-slot arrives and the queue contains data, it is serviced. If two queues contain data, and their time-slots arrive simultaneously, the queue with the highest priority is serviced first. The WRR-based scheduling alleviates the main disadvantage of strict priority-based scheduling by allowing lower priority queues to minimize bandwidth usage by providing a minimum bandwidth to all queues for transmission. This is accomplished by configuring the maximum number of packets allowed to be transmitted from a given priority queue, and the maximum amount of time a given priority queue has to wait before being allowed to transmit its accumulated packets. This establishes a class of service (CoS) for each of the switch's four hardware priority queues. The Metro ESU queue classification is by p-bits only. When an untagged packet ingresses the Metro ESU, a new VLAN shim and a mux tag is added to the customer packet, with the new VLAN tag p-bits set to zero. However, the Metro ESU filter classification allows the SP to remark the p-bits during policing to any desired p-bit level between 0 and 7. If the access point is considered not trustworthy, the same filter support can be used to remark customer p-bits (for tagged packets) based on various filter classifications. When the customer p-bits are remarked, the remarking is permanent and the customer packets egress the network with the new markings. Note: Remarking of p-bits during policing occurs before queue assignment. After remarking, the packet is placed in the appropriate queue.
Metro ESU egress queueing for untagged packets

When an untagged customer packet enters a Metro ESU port, a default customer tag is added to the packet, with the p-bit setting based on the Metro ESU default port COS value or the filter, policer, or classifier action (depending on how the port is configured). This p-bit is used to indicate packet priority on the ESU ring only. When the data packet enters the Metro Ethernet Passport switch's Metro ESM 8668 port, the service priority COS value is reclassified by the endpoint priority map, using the p-bits in the default customer tag.
320747-A
The default customer tag, which is assigned by the Metro ESU, is removed before the packet is forwarded out the NNI link(s) to the destination, and the original customer data packet is left untagged. The SP OEL2 header is remarked per the endpoint priority map. When data packets are processed for egress into an ESU-ring, all data packets must include a mux tag. After the packet arrives at the egress endpoint, the customer packet is inspected prior to removing the OEL2 header. The original customer tag is transferred to the ESU stack tag, including the original customer p-bits, or the remarked p-bits (customer p-bits can be remarked by filters at ingress ESU). If the customer packet is untagged, a default customer tag is added and the SP p-bits that accompanied the packet is remarked into the default customer tag. The p-bits assigned to the default customer tag are used in the ring for COS priority during congestion. If the original customer packet was untagged, when it egresses the Metro ESU port, it remains untagged.
Metro Ethernet Switch policing

In this release, endpoints support both ingress rate policing and egress rate policing. Both ingress rate policing and egress rate policing use a synchronized collection of a two-rate and three color marker token bucket model. All traffic classes except for best effort (BE) get a guaranteed data rate represented by the committed information rate (CIR) rate. Peak information rate (PIR) represents the total bandwidth allocation for the endpoint and also represents the peak data rate for all service classes. When configuring the COS-profiles, the sum of all CIR must not exceed the PIR. In addition, PIR must not exceed the provisioned service rate. This section includes the following topics: Summary of policing enhancements, next Metro Ethernet Switch policier functionality on page 165 Configurable token buckets on page 166 Policing rules on page 168
Summary of policing enhancements

For SPs to deploy VPN-based services, there is sometimes a need for limiting the amount of BW egressing an endpoint. The ingress policer acts on data traffic entering a specific endpoint at the UNI to NNI direction. The new egress policer essentially replicates that functionality for traffic in the NNI to UNI direction on a per endpoint basis. Both ingress and egress policing can be enabled or disabled independently. For example, if only egress policing is desired on an endpoint, ingress policing can be disabled while egress policing is enabled. By default, egress policing is disabled, whereas ingress policing is enabled. When using policing, a cos-profile must be created and assigned to the desired rate policier. Both ingress and egress policing can be configured with independent cos-profiles, or the same cos-profile can be used for both rates if desired. In addition to defining CIR and PIR levels for the cos-profile, the profile also allows for configuring the token bucket depth for each SLA defined. This is discussed in brief in Configurable token buckets on page 166. Release 3.6 also allows the end-user to dynamically change the cos-profile for an endpoint without having to first disable the endpoint. The end-user must first change the desired cos-profile, or create a new cos-profile, and than assign the cos-profile to the endpoints ingress and/or egress cos profile field. Classifiers, policers, and filters are applied to ports on the ESU and multiple instances of each can be applied to any given port. A packet arriving at a port is processed by all policies applied to that port at the same time. If the packet matches more than one policy, the following rules apply: All non-conflicting actions is applied (for example, a classifier remarks and policer meters) If there are conflicting actions (for example, two matching classifiers want to remark to different values, or a classifier and policer both want to remark): Classifier remark takes precedence over policer remark Classifier with lower ID takes precedence over classifier with higher ID
320747-A
Policer with lower ID takes precedence over policer with higher ID for both remarking and metering Filters are applied implicitly during the initial classification. In the event the filter action is drop, all actions by policier and classifier stop, and the packet is dropped
Metro Ethernet Switch policier functionality

Policing on the ESM 8668 is based on a two-rate, three-color-marker model. This model employs two token buckets, referred to as CIR and PIR, for each endpoint. When configuring an endpoint for policing, a COS profile must be configured and associated with each TDI endpoint, one to control ingress policing and one to control egress policing. The profiles can be the same or different depending on desired service level. Initially, both ingress and egress profiles are assigned default values (DEFAULT_PROFILE). The SP has the option of overriding the default profile settings. The COS profile is an aggregation of policing attributes defining four classes of service. A distinct CIR is configured for the top three classes (Premium, Gold, and Silver) and a PIR is configured for the lowest class (BE). The PIR is shared by all four classes, and must be greater than or equal to the sum of the CIRs. For the top three classes, a packet that conforms to CIR is marked as green and immediately accepted and forwarded to it intended destination endpoint. Note: When configuring multiple endpoints that egress the same NNI interface, traffic engineering concepts must be adhere to. If the NNI port is congested and the endpoint receives a packet that conforms to CIR, it is forwarded into the congested network and can be lost. The policing and QoS action taken when CIR is exceeded depends on the PIR usage attribute associated with that class. If PIR usage is disabled, the packet is marked as red and dropped. If enabled, the packet is marked as yellow and sent to the PIR meter. If PIR is exceeded as well, the packet is marked red (dropped). If a packet conforms to PIR, the action taken is then determined by the congestion status of the egress port as reported by the switch fabric. If the egress port is temporarily congested (for that service class), the packet is dropped. Otherwise the packet is accepted and marked as yellow and forwarded towards the egress NNI interface. If the egress NNI interface is congested, yellow packets are dropped first.
Configurable token buckets

Policing for the Metro Ethernet Passport 8600 Switch is based on a token bucket concept, where a virtual bucket slowly fills up with tokens, which arrive at some constant rate and are used to measure and rate limit traffic flows. Every packet must obtain a token before it can be transmitted (if there are no available tokens, the packet cannot be transmitted). Thus, the rate at which tokens arrive dictates the average rate of traffic flow. The depth of a token bucket dictates how bursty the traffic is allowed to be. The depth of a token bucket also has various effects on the type of traffic flows that enter the policed endpoint. The optimal token bucket size is more of a compromise than an exact science. It is a function of the interface speed, its configured CIR rate, and the desired burst size (in milliseconds) for the application in use: Shallow token bucket depth A shallow token bucket depth forces the policer to be overly strict at enforcing rate compliance, and this can have a particularly adverse affect on TCP/IP sessions. Because data packets for a given flow are not typically transmitted at perfectly uniform intervals (for example, not evenly distributed over a one-second period), the maximum token bucket depth should be high enough to accommodate the somewhat bursty nature of traffic on a live network. Deep token bucket depth However, a deep bucket can allow traffic flows to burst up to the maximum media speed for extended periods of time. This can make service level agreements difficult to manage. Warning: Oversubscribed premium and critical network marked packets overloads the CPU switch fabric and can result in all traffic flows, including un-related traffic flows, to stop forwarding. DO NOT oversubscribe premium flows by more than 120% to any egress port. Do NOT oversubscribe bi-directional legacy access ports by more than 50%. You can use the following formula to arrive at a token bucket (TB) max value in kilobits:
320747-A
T = B(S - R) / (1024 x 8) where: T uses a multiple of 1024 to achieve a particular burst duration (B) in milliseconds, with an interface speed (S) and a given configured rate (R).
For example, to achieve a 5 ms burst rate for a CIR rate of 100 Mb/s, with an interface speed of 1 Gb/s, the TB Max value would be: B = 5 ms, S = 1 Gb/s, R = 100 Mb/s, T = .005(900 000 000) / 8 192 = 549 By default, the TB max value attribute is controlled internally by software (automatic mode), but can be configured by the administrator (manual mode). Table 9 lists the default TB max values assigned by the system when using automatic mode to define the default TB max values for a configured rate:
Table 9 Default TB maximum values in kilobytes
Configured Rate 1 x 64 Kb/s 2 x 64 Kb/s 3 x 64 Kb/s 4 x 64 Kb/s 5 x 64 Kb/s 6 x 64 Kb/s 7 x 64 Kb/s 8 x 64 Kb/s 9 x 64 Kb/s 10 x 64 Kb/s 11 x 64 Kb/s 12 x 64 Kb/s 13 x 64 Kb/s 14 x 64 Kb/s 15 x 64 Kb/s TB Max value (x 1024) 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 Configured Rate 40 Mb/s 50 Mb/s 60 Mb/s 70 Mb/s 80 Mb/s 90 Mb/s 100 Mb/s 150 Mb/s 200 Mb/s 250 Mb/s 300 Mb/s 350 Mb/s 400 Mb/s 450 Mb/s 500 Mb/s TB Max value (x 1024) 15 15 15 30 30 30 100 125 150 175 200 225 250 275 300 Configured Rate 750 Mb/s 800 Mb/s 850 Mb/s 900 Mb/s 950 Mb/s 1000 Mb/s TB Max value (x 1024) 150 100 75 50 50 50
168 Configuration considerations and limitations Table 9 Default TB maximum values in kilobytes (continued)
Configured Rate 1 Mb/s 10 Mb/s 20 Mb/s 30 Mb/s TB Max value (x 1024) 10 10 10 10 Configured Rate 550 Mb/s 600 Mb/s 650 Mb/s 700 Mb/s TB Max value (x 1024) 300 300 275 250 Configured Rate TB Max value (x 1024)
To calculate burst values for the parameters displayed in Table 9 on page 167, use the following formula: (T x 1024 x 8) / (S - R) = B
Policing rules
This section describes the configuration rules to follow when you create and assign a COS profile to your endpoint configuration. This section includes the following topics: Classification rules for policing, next Default policing values on page 171 Changing profile settings on page 171 Rate setting rules on page 172 COS level burst rules on page 172
Classification rules for policing

There are four policing COS levels per profile; standard, silver, gold and premium. The QoS level assigned by the endpoint's priority profile determines the policing level that is used. For example, if the service priority QoS level is set to 3 (silver queue), the assigned COS-profile's silver CIR/PIR setting is used to police the packets.
320747-A
Table 10 shows the endpoint priority mappings that relate to the following policed meters.
Table 10 Endpoint priority mappings
Priority map COS-profile meter Meter value 0 1 2 3 4 5 6 7 Standard Standard Silver Silver Gold Gold Premium Premium PIR PIR CIR/PIR CIR/PIR CIR/PIR CIR/PIR CIR CIR Traffic burstable to: PIR PIR PIR PIR PIR PIR CIR only CIR only Diff server class BE BE AF2 AF2 AF3 AF3 EF NC/EF
For data traffic that enters the endpoint, after the data packet is classified and remarked based on the endpoint priority mapping, the packet is policed per the Ingress-COS-profile, which was assigned to the endpoint. For data traffic arriving at the egress endpoint, the packet is classified on the original customer p-bits (or TOS bits if p-bit priority override is enabled for the endpoint) and policed per the egress-COS profile, and only if egress policing is enabled for the endpoint. Note: If a packet enters the egress UNI port marked "yellow" from a previous traffic profile remarking (i.e. local switched traffic marked by ingress policier or marked at NNI using IP traffic profile filters), the packet remains yellow even if it is within the CIR rate limit on the egress rate policier. This means pre-marked "yellow" traffic that is forwarded classified and forwarded by an ESM server port, remains out of profile as it is forwarded to legacy access ports.
See Table 11 for egress statistics.

Table 11 Egress statistics
Statistic All frames TX TX-DR TX-CIR-DR TX-PIR-DR TX-CDR Multicast frames TX-SP Multicast 2 3 4 16 Premium 1 (2,3,4) Gold 5 (6,7,8) 6 7 8 Silver 9 Standard 13
(10,11,12) (14,15) 10 11 12 14 15
RX = packets received (unicast and multicast) at this endpoint (for example, from the UNI) DR = packets dropped due to policer action or switch congestion CIR-OOP = packets dropped because they exceeded the CIR setting for this CoS PIR-OOP = packets dropped because they exceeded the PIR setting CDR = packets dropped due to congestion to the switch fabric
RX-SP MCast
RX-SP MCast counts all packets that had a multicast Dest UNI in the TLS header (that is, after encapsulation) including: end-user packets with multicast/broadcast MAC DAs, end-user packets with unicast MAC DAs that have not been learned yet
TX-SP MCast
TX-SP-MCast counts all packets that had a multicast Dest UNI in the TLS Header (i.e., before decapsulation). The end-user packet can be unicast or multicast. The following customer frames are examples: customer MAC DA is broadcast, customer MAC DA is multicast, customer MAC DA is unicast with negative hit on the forwarding table. The following ingress statistics increment:
320747-A
RX is incremented in all cases.
RX-SP MCast is incremented when Dest UNI in OEL2 Hdr is a multicast address. This is the case for the above customer packets unless: endpoint connection attribute is point-to-point or spoke endpoint connection attribute is any-to-any and dest-uni(s) are configured for the TDI Thus, these packets are counted under the unicast statistics.
In addition, the RX drop stats could be incremented if the packet ends up being dropped by ingress policing.
The following egress statistics increment: TX increments for all these packets UNLESS the packet is dropped by egress policing. TX-SP-MCast increments if the Dest UNI in the OEL2 Hdr is a multicast address UNLESS the packet is dropped by egress policing.
Default policing values

By default, ingress policing is enabled and egress policing is disabled. Either of the two rate limiters can be explicitly disabled or enabled as needed by the endpoints SLA requirements. For newly created COS profiles, the default CIR level for all three upper traffic classes is set to 0 and the PIR level is set to 960K for all four levels (including best effort or standard). To avoid restricting an endpoint to the default value, create a COS profile with your desired rate, and assign the COS profile to the new endpoint prior to enabling the endpoint.
Changing profile settings

The COS profile settings for an endpoint can now be dynamically updated when the profile is changed, or when a new profile is created to change the policing characteristics of an endpoint.
When updating an ingress or egress cos profile, the user only has to re-add the existing profile name or add the new profile name if newly created. Note: When changing or adding a new COS profile to an active endpoint, internally the image is disabled and re-enables the endpoint to apply the change. Traffic flows are impacted for up to 2000 milliseconds or less.
Rate setting rules

There is a single PIR setting for each COS profile. When you configure a CIR rate, the default unit value is 64K. This allows for a CIR entry range of 1 to 15 (or 64K to 960K). The CIR entry range is a unit multiplier value, not a rate value. For example, a CIR value of 2 and a UNIT value of 64K equals 128K CIR rate for the COS value assigned. When the UNIT is set to 1M, the CIR value range allowed is 1 to 1000 (or 1M to 1000M). When setting the CIR rates for the three upper COS values (silver, gold and premium), the summation of all CIR rates defined for the COS-Profile cannot exceed the PIR rate defined for the cos profile. For example, if the CIR rate for Premium, Gold and Silver are set to 100M each, the standard PIR setting must be 300M or greater. If the Standard PIR is less than 300M, an error is displayed once the sum of all CIRs exceeds the PIR limit.
COS level burst rules

You can configure each of the upper QOS levels to allow or disallow the SLA level to burst above CIR settings. When the pir-usage flag for any or all of the SLA levels is set to enable, the traffic flows are allowed to sustain a burst level above the configured CIR level and up to the defined Peak Information Rate (PIR) level for the cos profile. When traffic is marked yellow or PIR, the priority level is ignored. All packets that are marked yellow are treated equally.
320747-A
IP address spoofing
The IP spoofing feature detects the duplicate IP Address, (which ARP does) but blocks duplicate packets to/from by discarding (overwriting) MAC record, and sends the correct MAC address. By sending a gratuitous ARP (correct MAC address) to other devices in the vlan, this feature restricts the device from communication w/ other devices in the VLAN. IP Spoofing is supported on E-Series and M-Series Legacy NNI ports, in addition to ESM 8668 ports. Note: This feature requires the switch to be rebooted. Nortel recommends that you enable this feature during the upgrade to OE 4.0.0.0 in order to minimize the impact for the network traffic. This feature detects duplicate IP address based on ARP packets received. It is only during this detection phase that the security feature will restrict and drop offending data traffic. If a an attached host has already spoofed the network and remote devices have learned the MAC address, this feature does not protect the network from an existing IP Spoof incident nor will it restrict the traffic flows in progress. You can configure an ESM port for prevention of IP spoofing on a per ESM port basis. All UNIs assigned to the ESM port for Local TLS, and all UNIs assigned to an ESM ring port participate when IP Spoofing is enabled. It cannot be disabled per ESU or per ESU port. When enabling IP Spoofing on ESM ports, the service must be enabled on either the primary and secondary ring port, If you do not enable the service, connectivity issues can occur. If you are operating IP Spoofing in a core network with SMLT, configure this option on both SMLT aggregation switches to avoid connectivity issues. The Auto-Recovery-Delay timer is a global parameter. Separate timers for each port, TDI or Ring are not supported in this release. The default value for the auto-recovery-delay timer is 30 seconds.
Troubleshooting with TD continuity

The TD continuity feature provides a powerful set of tools that are useful for troubleshooting your Internet working traffic for TLS services. For example, when you use TD continuity testing to simulate a customers data path traffic, the test sends and receives test packets, and then reports the test results. You can also use TD continuity testing to check local and remote ports for improper configurations that could cause network problems. TD continuity and TD-connectivity both refer to one suite of tests that are used to test end-to-end pathways for OEL2/TLS packets. The Metro Ethernet Passport 8600 Switch TD continuity testing interoperates with the Optical Metro 1000 ESM module Release 1.2 or above. Note: TD-continuity tests require connectivity to a Metro Ethernet Passport 8600 UNI or an Optical Metro 1000 ESM module UNI with release 1.2 or above. Transparent ports use only untagged TDC test frames. For switched ports, you can send either tagged or untagged frames for testing, depending on the endpoint q-tag provisioning. The Metro Ethernet Passport 8600 Switch supports the following tests and features: Basic TD continuity test operation (multicast and unicast test sequence) Point-to-point Point-to-multipoint Transparent and mapped mode port testing. Testing both untagged test packets and tagged test packets. CLI interface for initiating a client end TD-continuity test. Round trip time option. This option allows you to display the time required for the round trip for each packet exchange between the source and destination ports.
320747-A
Round trip time threshold, user-provisionable Endpoint customer priority change option.
This option allows you to set a custom priority for TD continuity test packets. Note: You can only use the priority option for tagged frames on a TLS-Switched ports. Flooding (multicast) or unicast only option. You can send either only multicast packets or only unicast packets with TD-continuity test packets. Without using this option, both multicast and unicast test packets are sent. Automated periodic TDC tests with user-provisionable interval The periodic rate at which a test can be executed is in one minute granularity. The time period ranges from once-a-minute (1) to once-a-day (1440). The number of time periods a test can execute is indefinitely (value of 0) or 1 to 1440 times. TDC test history capable of holding at least 30 test results per test User-configurable multicast packet count for a TDC test; overrides default q-tag This option enables you to define the q-tag to use for endpoints assigned to many-to-one TDIs. This section includes the following topics: Diagnosing problems using TDC on page 175. Testing options on page 176. Round-trip time option on page 177. Priority option on page 177. Flooding (multicast)/unicast option on page 177. Limits and rules on page 178
Diagnosing problems using TDC

You can use TDC to diagnose a number of problems. This set of tools sends special packets through the SPs network for the specified customer TD during live traffic processing to identify specific problems. The main goal of TDC testing is to simulate the data packet traffic.
The Metro Passport 8600 can be either a requestor (client) or a responder (server) in test exchanges. To simulate the data path, the TDC test can perform two types of packet exchanges: multicast and unicast. Multicast packets test the data path setup, and unicast packets test the data path use. TDC tests are configured to send one or more multicast and/or unicast packets. Tests do not run concurrently on the Metro Passport 8600. Each test is executed in the order it is requested. The default time-out value for waiting for a server response is 10 seconds. In a normal test with two packet exchanges, the test should finish within 10 seconds. The minimum information needed to perform a TDC is as follows: TDI to test Source port UNI ID Destination port UNI ID
Testing options
The TDC feature includes the following optional capabilities and enhancements: Support for Preside Service Provisioning JDM support for TDC Support for round-trip delay statistics Round-trip time threshold, with optional notification using SNMP trap if time is exceeded User configurable priority levels for TDC test cases Support for periodic tests at user-specified intervals Historical test results with user-configurable history length Ability to assign a name to each TDC test Ability to define a destination NNI port (for OM3500 destination NNI ports only) Non-volatile storage of test configurations Custom test configurations, with user-configurable multicast and unicast packet counts Ability to modify test parameters (instead of completely reconfiguring a test)
320747-A
Round-trip time option

The round trip time option allows you to display the time required for the round trip for each packet exchange between the source and destination ports. An optional round trip threshold parameter can be set, in milliseconds, to confirm the overall round trip time is equal to or less than the specified threshold. If the round trip time threshold is exceeded, an SNMP error trap is sent to indicate the TDC test failed for the specified threshold.
Priority option
The priority option allows you to set a custom priority level for TDC test packets. This parameter sets the initial q-tag for the TDC packet as it enters the UNI interface. Note: The endpoint custom QoS parameters and egress QoS map define the internal QoS and remapping of the OEL2 packet as the packet exits the NNI port.
Flooding (multicast)/unicast option

You can send three types of TDC test packets: Both multicast and unicast test packets Only multicast test packets Only unicast test packets
The default options for this test sends one multicast and one unicast packet. When you configure the TDC test to send both multicast packets and unicast packets, only the first part of the TDC test executes: the TDC test sends one multicast packet and wait for the response before continuing with the normal Secondary
unicast exchange. If there is no response to the multicast packets, the unicast portion of the test does not execute. When you send only TDC unicast packets, if the MAC destination address (DA) is unknown, the packet forwards out of the SP NNI port as a multicast packet. Note: If you define a destination port for UNI-to-NNI port verification, only multicast test packets are supported. The Unicast test packet count is set to zero if this field is set.
Limits and rules

The TDC test provides the functionality to support TDC tests for Metro Ethernet Passport 8600 and ESU UNI to OPE NNI ports. A new TDC test attribute, dest-port now exists to provide the destination NNI port information needed to complete this test. Note: Nortel only supports NNI TDC test from the Metro Ethernet Passport 8600 and ESU source UNI to OPE destination NNI ports. The Metro Ethernet Passport 8600 has no UNI ID concepts for NNI ports on the Metro Ethernet Passport 8600. There are four NNI TDC scenarios supported: Metro Ethernet Passport 8600 UNI to OPE NNI ports ESU UNI to OPE NNI ports Metro Ethernet Passport 8600 UNI to OPE UNI ESU UNI to OPE UNI
OPE NNI ports do not support unicast TDC packets on the NNI ports. On OPE, NNI does not perform MAC learning on the customer TD. So a unicast packet on a particular TDI to NNI does not work. If the dest-port field is configured, the unicast value for the test is set to 0, even if it was pre-configured. User-configurable unicast packet count for a TDC test; overrides default.
320747-A
Enhanced RRP considerations

When configuring ESU Rings, the RRP Hello interval should be less than the discover interval to allow the RRP Hello mechanism to detect a ring problem before bringing the ring down. Also, ensure that the hello interval on the Metro Ethernet Passport 8600 matches what is configured for each ESU in the ring. If the timers do not match on all devices in the ring, the ring may transition into a cut state unnecessarily. Enabling RRP Hello in the ring and changing the RRP Hello interval is a dynamic configuration change. The RRP Link Down messages use the stack module ID of 28 (to forward and copy to the Local CPU).
VLACP considerations
You configure VLACP on a per port basis at the Ethernet port level. The port can be an individual port or an MLT member. VLACP goes through Periodic, Transmission and Receive State Machines of LACP, but does not use Selection and Mux State Machines as defined in the 803.2ad standards. Periodically, VLACP DUs (i.e., BPDUs) are sent on each port where VLACP is enabled. You can configure the destination MAC address used in VLACP DUs. The MAC address needs to be a multicast MAC address, so it will always flood. This allows the exchange of VLACP DUs from an end-to-end perspective. Failover time is determined by the periodic VLACP DU exchange you configure using the fast-periodic-time and timeout-scale values. The timeout-scale value is a multiplier for fast-periodic time used to determine how long to wait before considering time to failover. The fast-periodic-time and timeout-scale values are hard-coded and not user-definable. The fast-periodic-time value is set at 10 milliseconds, while the timeout-scale value is set to 2. This means that the switch waits until three times the fast-periodic-time value (30 milliseconds) before considering the remote MLT port non-operational.
320747-A
181
Chapter 4 Configuring the Metro Ethernet Passport 8600 Switch using Device Manager
This chapter describes how to configure the Metro Ethernet Passport 8600 Switch using Device Manager. For information about configuring the Metro Ethernet Passport 8600 Switch using the CLI, see Configuring the Metro Ethernet Passport 8600 Switch using CLI. Note: Before configuring Metro Ethernet Services on the Metro Ethernet Passport 8600 Switch, review the configuration considerations described in Chapter 3. See Configuring the Metro Ethernet Passport 8600 Switch using CLI for the CLI commands to configure RSTP and MSTP. This chapter includes the following topics:
Topic Configuring TD continuity testing Configuring an ESU Ring Displaying ESU ring RRP statistics Displaying ESU ring RDP statistics Configuring a Dual Home ring Displaying ESU ring records Displaying ESU ring port states Configuring ESU standalone Configuring a class of service profile Configuring a user-to-network interface Page 183 194 198 200 202 207 208 209 212 212
182 Configuring the Metro Ethernet Passport 8600 Switch using Device Manager
Topic Configuring a UNI MAC address Configuring transparent domain identifiers Displaying Metro ESM 8668 server-port statistics Configuring the Metro Ethernet Passport 8600 repeater feature Configuring a UNI Customer IP VLAN Configuring a VLACP Page 222 224 243 252 255 268
320747-A
Configuring the Metro Ethernet Passport 8600 Switch using Device Manager 183
Configuring TD continuity testing

This section describes how to test Transparent LAN Services (TLS) with the Transparent Domain (TD) continuity commands, including multicast and unicast packets and round trip time. You can run the tests using any port that is configured for Optical Ethernet Layer 2. This section includes the following topics: Running a currently configured TDC test Displaying test history on page 185 Configuring a new TDC test on page 191
Running a currently configured TDC test

When you select and run an existing (previously configured) test, only the current displayed configuration is overwritten; all other existing configurations remain unchanged. In addition, all existing result history for the specified test is cleared when an existing test configuration is overwritten (to display test history for specified tests, refer to Displaying test history on page 185). To run a currently configured TDC test, using Device Manager: 1 From the Device Manager menu bar, choose VPN > TD Continuity. The TDC dialog box opens with the TD Continuity tab displayed (see Figure 47).
Figure 47 TDC dialog boxTD Continuity tab
Double-click in the Action field to open the pull-down menu.
Select the currently configured test you want to run and then click start in the Action field (see Figure 47). Use the pull-down menu to choose other menu options. Refer to Table 14 on page 192 for the TDC, Insert TD Continuity dialog box field descriptions.
Click Apply to change the configuration.
320747-A
Displaying test history

You can use Device Manager to display test history for specific tests. To display test history for specified TDC tests, using Device Manager: 1 Choose VPN > TD Continuity from the Device Manager menu bar. The TDC dialog box opens with the TD continuity tab displayed (see Figure 47 on page 184). 2 3 In the TDC dialogTD continuity tab, select the test id for which you want to display test history. Click History. The TD Continuity History dialog box opens with the History tab displayed (see Figure 48 on page 186).
186 Configuring the Metro Ethernet Passport 8600 Switch using Device Manager Figure 48 TD Continuity History dialog boxHistory tab
Click the Error Codes button to display bitmask code descriptions.
Use the scroll bar to display all columns.
See Table 12 for a description of TD Continuity History field descriptions.
Table 12 TD Continuity History field descriptions

Field TestHId Id Description Indicates the unique test id for this entry. Indicates the unique number that identifies a specific customer TD, on which this test is executed.
320747-A
Configuring the Metro Ethernet Passport 8600 Switch using Device Manager 187 Table 12 TD Continuity History field descriptions
Field PktsSent PktsReceived RttBroadcastMin RttBroadcastMax RttBroadcastAvg RttUnicastMin RttUnicastMax RttUnicastAvg RttAvg HopCountMin HopCountMax HopCountAvg TestDateandTime TimeStamp Result ErrorMask Description Indicates the number of test packets transmitted. Indicates the number of test packets received. Indicates minimum round-trip-time (RTT), in microseconds, required by a broadcast test packet for all executions of this test. Indicates maximum round-trip-time (RTT), in microseconds, required by a broadcast test packet for all executions of this test. Indicates average round-trip-time (RTT), in microseconds, required by a broadcast test packet for all executions of this test. Indicates minimum round-trip-time (RTT), in microseconds, required by a unicast test packet for all executions of this test. Indicates maximum round-trip-time (RTT), in microseconds, required by a unicast test packet for all executions of this test. Indicates average round-trip-time (RTT), in microseconds, required by a unicast test packet for all executions of this test. Indicates average round-trip-time (RTT), in microseconds, required by a unicast and broadcast test packet for all executions of this test. Indicates the minimum number of hops a test packet took. Indicates the maximum number of hops a test packet took. Indicates the average number of hops a test packet took. Indicates the date and time of the test. Indicates the timestamp. Indicates the number of results saved for a given TDC test. Indicates the error mask associated with the TDC test. Each bit in the mask represents a specific error. The errors from the least significant bit to the highest significant bit are summarized and represented in this mask. See Table 13 on page 188 for the descriptions.
Click Refresh to update the display data. Note: The fields in this screen display register bitmap codes that indicate test history results.
Click Error Codes to view the bitmask code description online (or refer to Table 13).
Table 13 Error bitmask code descriptions

Error code number 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 to 32 Not used 33 34
Description TD nonexistent on destination port TD disabled on destination port TD not assigned to destination port TD filtered on destination NNI port Destination port is NNI Destination port is craft Destination FDB test failed Destination administrative state down Destination operational state down Destination port connectivity mismatch error Destination port type mismatch Destination port mode mismatch error Destination MIB query failed Destination system error Invalid destination port Destination port is CPU Destination port mode mismatch warning Destination port connectivity mismatch warning Default priority used on destination IP not assigned on destination oel2 port Static entry exists on destination port Destination FDB table full warning Not Applicable TD nonexistent on source port TD not assigned to source port
320747-A
Configuring the Metro Ethernet Passport 8600 Switch using Device Manager 189 Table 13 Error bitmask code descriptions (continued)
Error code number 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62
Description Source FDB test failed Source administrative state down Source operational state down Source system error No response (timeout) Could not get trace information Could not get time information Source MIB query failed TD disabled on source port Invalid source port All ports down on the source node Unknown error Source FDB test failed Static entry exists on source port No FDB entry for destination MAC, unicast aborted RTT threshold exceeded Test FAIL due to bad packet TD CONT version Test FAIL due to bad packet TDI Test FAIL due to bad packet Dest MAC (match) Test FAIL due to bad packet Dest IP (match) Test FAIL due to bad packet Src MAC (must be unicast) Test FAIL due to bad packet Src IP (match) Test FAIL due to tagged/untagged mismatch Test FAIL due to bad packet VID (match) Test FAIL due to T/M Bit Mismatch Test FAIL due to APPL TYPE mismatch in packet Test FAIL due to DST PORT mismatch in packet Test FAIL due to other field mismatch in packet
190 Configuring the Metro Ethernet Passport 8600 Switch using Device Manager Table 13 Error bitmask code descriptions (continued)
Error code number 63 64
Description Test was aborted by user Warning, dst TDI manytoone case, qtag mismatch
320747-A
Configuring a new TDC test

You can use Device Manager to configure a new TDC test. To configure a new TDC test: 1 Choose VPN > TD Continuity from the Device Manager menu bar. The TDC dialog box opens with the TD continuity tab displayed (see Figure 47 on page 184). 2 Click insert in the TDC dialog box TD continuity tab. The TDC, Insert TD Continuity dialog box opens (see Figure 49). 3 Click in any field to edit the data and then click Insert.
Figure 49 TDC, Insert TD Continuity dialog box
Refer to Table 14 for the TDC, Insert TD Continuity dialog box field descriptions.
Table 14 TDC, Insert TD Continuity dialog box fields

Field TestId Description Sets the number or name of the TD you want to create for continuity testing. Enter an integer value in the range 1 and 9999. Sets a unique name for the TD. Enter an alphanumeric string (in the range 1 and 63 alphanumeric characters) that uniquely identifies the TD. Specifies the unique number that identifies a specific TD. Enter an integer value in the range 1 and 16 777 214. Sets the source UNI ID (IP address) for the TDC test. Sets the destination UNI ID for the TDC test. Sets the destination port for the TC continuity test. Enter an integer value in the form of slot/port. Specifies the number of multicast packets to send for this test. Enter an integer value in the range 0 and 100 packets. Specifies the number of unicast packets to send for this test. Enter an integer value in the range 0 and 100 packets. Sets the number of history entries you want to allocate for this test. Enter an integer value in the range 1 and 9 999 entries. Note: The total number of all history entries across all tests on a single switch is 900. Specifies the time-interval, in minutes, when you want the periodic TDC test to run. Enter an integer value in the range 0 and 1 440 minutes. Note: 1 440 minutes equals 24 hours (one day).
Name
TDI
SrcUni DstUni DstPortNum MulticastCnt
UnicastCnt
HistoryCnt
PeriodicRate
320747-A
Configuring the Metro Ethernet Passport 8600 Switch using Device Manager 193 Table 14 TDC, Insert TD Continuity dialog box fields (continued)
Field PeriodicCount Description Specifies the number of times you want the periodic TDC test to run. Note: If you enter 0, the periodic TDC test runs constantly. Specifies a priority value to use, instead of the priority of the source port. Enter an integer value in the range 0 and 7. The default value is the priority of the source port. Sets the timeout period (in seconds) for the TDC test. The default value is 10 seconds. Enter an integer value in the range 1and 120 seconds. Note: You must specify an integer value; otherwise the default value (10 seconds) is used. Sets the round trip time option. none time Specifies the round trip time threshold parameter. Enter an integer value in the range 0 and 10 000 ms. Note: setting this value to 0 (zero) disables the rtt threshold parameter. Assigns the q-tag to endpoints defined as many-to-one. Allows you to specify the TDC test action: none: disables the specified TestID from running. start: runs the specified TestID. startPeriodic: allows you to run the specified TestID in periodic mode. abort: stops the TDC test you are currently running. abortPeriodic: stops the TDC test you are periodically running.
PktPriority
PktTimeout
TimeTrace
RttThreshold
Qtag Action
Configuring an ESU Ring

This section describes how to configure an ESU ring, using Device Manager. To configure an ESU ring, using Device Manager: 1 Choose VPN > ESU > Ring from the Device Manager menu bar, The ESU_Ring dialog box opens with the ESU Ring dialog box displayed (see Figure 50).
Figure 50 ESU_Ring dialog boxESU Ring dialog box
Click Insert. The ESU_Ring, Insert ESU Ring dialog box opens (see Figure 51 on page 195).
320747-A
Configuring the Metro Ethernet Passport 8600 Switch using Device Manager 195 Figure 51 ESU_Ring, Insert ESU Ring dialog box
Click the appropriate ellipses button to open the Primary or Secondary port dialog box.
Click to select any port.
Use the scroll bar to display all ports (or resize the dialog box).
3 4
Enter a unique ring-name in the ESU_Ring, Insert ESU Ring dialog box, Name field. Click the ellipses button in the ESU_Ring, Insert ESU Ring dialog box, Primary Port field, to select a primary ring port (see Figure 51). The Primary Port dialog box opens. Click to select a port, then click Ok.
In the ESU_Ring, Insert ESU Ring dialog box, Secondary Port field, click the ellipses button to select a secondary ring port (see Figure 51 on page 195). The Secondary Port dialog box opens. Click to select a port, then click Ok.
In the ESU_Ring, Insert ESU Ring dialog box, set the interval timer value in the DiscoverInterval field. Enter an integer value in the range of 1 to 255 seconds.
7 8 9
In the ESU_Ring, Insert ESU Ring dialog box, set the AdminState field to enable (click the enable radio button). In the ESU_Ring, Insert ESU Ring dialog box, in the VlanIds field, enter the VLAN IDs that you want to be associated with this ring. In the ESU_Ring, Insert Ring dialog box, set the RRPHello field to enable (click the enable radio button).
10 In the ESU_Ring, Insert Ring dialog box, set the RRPHelloInterval timer value. Enter an integer value in the range of 1000 to 10000 milliseconds. 11 In the ESU_Ring, Insert ESU Ring dialog box, click Insert. The new configuration appears in the ESU_Ring dialog box (see Figure 50 on page 194). Refer to Table 15 for the ESU Ring tab and Insert, ESU Ring dialog box field descriptions.
Table 15 ESU Ring tab and Insert, ESU Ring dialog box field descriptions
Field Id Name Description Creates the Ring ID number. The value ranges from 1 to 254. Creates a unique name for the ESU ring with a string length in the range 0 to 32, which represents the unique ESU ring name. Specifies the Primary port of the Metro ESM 8668. This port connects to the Primary port of the first Metro ESU in the ring.
PrimaryPort
320747-A
Configuring the Metro Ethernet Passport 8600 Switch using Device Manager 197 Table 15 ESU Ring tab and Insert, ESU Ring dialog box field descriptions
Field SecondaryPort Description Specifies the Secondary port of the Metro ESM 8668. This port connects to the Secondary port of the last Metro ESU in the ring. Sets the discover-interval timer value in the range 1 to 255, which represents the discover interval-time, in seconds. The default value is 30 seconds. Allows you to administratively enable or disable the ESU ring. Specifies the OperState for Cust IP VLAN. Appears as one of the following states: up down If AdminStatusfor the Cust-IP-VLAN is down, then OperStatus should be down. If AdminStatus is changed to up, then OperStatus should change to "normal" if the assigned UNI is AdminState up and OperState up. If the OperState of the Cust-IP-VLAN is up, the IP Endpoint is available to transmit and receive network traffic. If the OperState is down and AdminState is up, it indicates either the UNI is AdminState down or OperState for the UNI is down. If the assigned port (UNI) for the IP Endpoint is connected and link appears to be up, but the OperStatus for the IP Endpoint still appears down, there is a fault condition for the IP Endpoint that prevents it from going to the up state. Allows you to enter the VLAN Id for the Metro ESU ring trunk. Allows you to set the RRP Hello for an ESU dual home ring. Enable activates RRP Hello and disable deactivates RRP Hello. The default value is disable. Allows you to set the RRP Timer Interval in milliseconds. The range is from 1000 to 10000 milliseconds, and the default value is 1000.
DiscoverInterval
AdminState OperState
VlanIds RRPHello
RRPHelloInterval
Displaying ESU ring RRP statistics

This section describes how to display ESU ring RRP statistics. To display ESU ring RRP statistics, using Device Manager: 1 From the Device Manager menu bar, Choose VPN > ESU > Ring. The ESU_Ring dialog box opens with the ESU Ring tab displayed (see Figure 50 on page 194). 2 3 Click on a ring. Click the RRP Statistics button. The RRP Statistics dialog box appears (see Figure 52).
Figure 52 Statistics, RRPRing ID dialog box
Refer to Table 16 for the RRP Statistics, Ring Id field descriptions.
Table 16 RRP StatisticsRing Id dialog box field descriptions

Field Absolute Value Cumulative Description The absolute value of the received/transmitted/dropped octets. The total number of received/transmitted/dropped octets.
320747-A
Configuring the Metro Ethernet Passport 8600 Switch using Device Manager 199 Table 16 RRP StatisticsRing Id dialog box field descriptions
Field Average/Sec Minimum/Sec Maximum/Sec LastVal/Sec PrimaryPortTxRrpHello PrimaryPortRxRrpHello PrimaryPortMissing RrpHello SecondaryPortTxRrpHello SecondaryPortRxRrpHello SecondaryPortMissing RrpHello Description The average number of received/transmitted/dropped octets per second. The minimum number of received/transmitted/dropped octets per second. The maximum number of received/transmitted/dropped octets per second. The last value a second received. The number of RRP Hellos sent from the Primary port. The number of RRP Hellos received at the Primary port. The number of missing Primary port RRP Hellos. The number of RRP Hellos sent from the Primary port. The number of RRP Hellos received at the Secondary port. The number of missing Secondary port RRP Hellos.
To reset the statistics counters, use the Clear Counter button. When you click this button, all Cumulative, Average, Minimum, Maximum, and LastVal columns are reset to zero and automatically begin to recalculate statistical data. Note: Device Managers Clear Counter function does not affect the switchs AbsoluteValue counter. The Clear Counter function clears all cached data in Device Manager (except AbsoluteValue). To reset AbsoluteValue(s), use the resetCounter function (Edit > Chassis > System).
Displaying ESU ring RDP statistics

This section describes how to display ESU ring RDP statistics. To display ESU ring RDP statistics, using Device Manager: 1 Using Device Manager, choose VPN > ESU > Ring from menu bar The ESU_Ring dialog box opens with the ESU Ring tab displayed (see Figure 50 on page 194). 2 3 Click on a ring. Click the RDP Statistics button. The RDP Statistics dialog box appears (see Figure 53).
Figure 53 Statistics, RDPRing ID dialog box
Refer to Table 17 for the RDP Statistics, Ring Id field descriptions.
Table 17 RDP StatisticsRing Id field descriptions

Field Absolute Value Cumulative Average/Sec Description The absolute value of the received/transmitted/dropped octets. The total number of received/transmitted/dropped octets. The average number of received/transmitted/dropped octets per second.
320747-A
Configuring the Metro Ethernet Passport 8600 Switch using Device Manager 201 Table 17 RDP StatisticsRing Id field descriptions (continued)
Field Minimum/Sec Maximum/Sec LastVal/Sec PrimaryPortTxRdp PrimaryPortRxRdp SecondaryPortTxRdp SecondaryPortRxRdp Description The minimum number of received/transmitted/dropped octets per second. The maximum number of received/transmitted/dropped octets per second. The last value a second received. The number of RDP octets sent from the Primary port. The number of RDP octets received at the Primary port. The number of RDP octets sent from the Secondary port. The number of RDP octets received at the Primary port.
Configuring a Dual Home ring

This section describes how to configure an ESU Dual Home ring using Device Manager. To configure an ESU ring using Device Manager: 1 From the Device Manager menu bar, choose VPN > ESU > Dual-homing. The ESU Dual Homing window opens with the ESU Dual Homing tab displayed (see Figure 54).
Figure 54 ESU_DualHoming
Click the Insert button. The ESU_Dual Homing, Insert dialog box appears (see Figure 55 on page 203).
320747-A
Configuring the Metro Ethernet Passport 8600 Switch using Device Manager 203 Figure 55 ESU_Dual Homing, Insert dialog box
Click the appropriate ellipses button to open the port dialog box.
Edit the values, as necessary, and click Insert to save your changes.
Refer to Table 18 for the ESU Dual Homing tab and the ESU_Dual Homing, Insert dialog box field descriptions.
Table 18 ESU Dual Homing tab and ESU_Dual Homing, Insert tab field descriptions
Field Id Name Description Creates the Ring ID number. The value ranges from 1 to 254. Creates a unique name for the ESU ring with a string length in the range 0 and 32, which represents the unique ESU ring name. Sets the discover-interval timer value in the range 1 and 255, which represents the discover interval-time, in seconds. The default value is 30 seconds. Allows you to administratively enable or disable the ESU dual home ring.
DiscoverInterval
AdminState
204 Configuring the Metro Ethernet Passport 8600 Switch using Device Manager Table 18 ESU Dual Homing tab and ESU_Dual Homing, Insert tab field descriptions (continued)
Field OperState Description The current operational state of the Metro ESU dual home ring. Appears as one of the following states: Normal Down Cut If AdminStatus for the ESU Dual Home-Ring is down on either the Primary or the Secondary Metro Passport 8600 Switch, then OperStatus should be down on both the Primary and Secondary Passport 8600 Switch. If AdminStatus is changed to up on both the Primary and Secondary Metro Passport 8600 Switches, then OperStatus should change to "normal" if the dual home ring is operational and intact. If the OperStatus is cut, it indicates a ring break has occurred either within the ring or along the ESU Ring Trunk (ERT) path. If the OperStatus of the ring is either normal or cut, the ring is available to transmit and receive network traffic. If the ring is intact and the OperStatus still appears down and AdminState is up, there is a fault within the dual home ring path that prevents it from going to the up state. Allows you to set the ESU Port type to Primary or Secondary. Allows you to enter the port number for the Ban (ESU) Port in the following format: slot/port. Configures the dual home ring port peers MAC address in the following format: {0x00:0x00:0x00:0x00:0x00:0x00}. Allows you to enter the port number for the single link ESU ring trunk in the following format: slot/port. Allows you to enter the MLT for the ESU ring trunk MLT with an integer value in the range 1 to 32, and is a unique id. Allows you to enter the VLAN Id for the ESU ring trunk with an integer value in the range 1 and 4 094. Allows you to enter the VLAN Id for the ESU ring trunk.
RingPortType Port PartnerPortMac ErtPort ErtMlt
ErtVid VlanIds
320747-A
Displaying ESU Dual Home ring RRP statistics

This feature is not supported in release 4.0.
Displaying ESU Dual Home ring RDP statistics

This feature is not supported in release 4.0.
320747-A
Displaying ESU ring records

This section describes how to display information about your ESU ring, using Device Manager. To display ESU ring records, using Device Manager: 1 From the Device Manager menu bar, choose VPN > ESU > Ring Record. The Ring Records tab opens and displays information about your ESU Rings (see Figure 56).
Figure 56 Ring Records tab
Table 19 describes the Ring Records tab fields.
Table 19 Ring Records tab fields

Field RingId MacAddress IpAddress RingBreakType Position Description Read-only fieldDisplays the unique ring Id number. Read-only fieldDisplays the MAC address assigned to this ring. Read-only fieldDisplays the IP address assigned to this ring. Read-only fieldDisplays the ring state: normal or cut. Read-only fieldDisplays the position of the ESU in the ring, starting from the primary port.
Displaying ESU ring port states

This section describes how to display information about your ESU ring port states, using Device Manager. To display ESU ring port state information, using Device Manager: 1 Choose VPN > ESU > Port State from the Device Manager menu bar. The Ring Port State tab opens and displays information about your ESU Rings (see Figure 57).
Figure 57 Ring Port State tab
Table 20 describes the Ring Port State tab fields.
Table 20 Ring Port State tab fields

Field RingId Id PortMask PortState Description Read-only fieldDisplays the unique ring Id number. Read-only fieldDisplays the ModId assigned to the ESU. Read-only fieldDisplays the ESU port state: 1 indicates Up, 0 indicates down. Read-only fieldDisplays the ESU port link state: 1 indicates Up, 0 indicates down.
320747-A
Configuring ESU standalone

This section describes how to configure ESU in a standalone configuration, using Device Manager. To configure ESU standalone, using Device Manager: 1 Choose VPN > ESU > Standalone from the Device Manager menu bar. The ESU_Standalone dialog box opens with the ESU Standalone tab displayed (see Figure 58).
Figure 58 ESU_Standalone dialog boxESU Standalone tab
Click Insert. The ESU_Standalone, Insert ESU Standalone dialog box opens (see Figure 59 on page 210).
210 Configuring the Metro Ethernet Passport 8600 Switch using Device Manager Figure 59 ESU_Standalone, Insert, ESU Standalone dialog box
Click the ellipses button to open the port dialog box.
In the ESU_Standalone, Insert ESU Standalone dialog box, EsmPort field, click the ellipses button to select a standalone ring port (refer to Figure 59). The BanRingSaRbsBanPort dialog box opens. Click to select a port; then click Ok.
In the ESU_Standalone, Insert ESU Standalone dialog box, set the interval timer value in the DiscoverInterval field: Enter an integer value in the range 1 and 255 seconds.
5 6
In the ESU_Standalone, Insert ESU Standalone dialog box, set the AdminState field to enable (click the enable radio button). Click Insert. The new configuration appears in the ESU_Standalone dialog box (refer to Figure 58 on page 209).
320747-A
Refer to Table 21 for the ESU Standalone tab and Insert, ESU Standalone dialog box field descriptions.
Table 21 ESU Standalone tab and Insert, ESU Standalone dialog box field descriptions
Field EsmPort DiscoverInterval Description Specifies the Metro ESM 8668 port that is connected to the Metro ESU. Sets the discover-interval timer value in the range 1 and 255, which represents the discover interval-time, in seconds. The default value is 30 seconds. Allows you to administratively enable or disable the ESU ring. OperState for the Standalone ESU and Metro ESU dual home ring. Appears as one of the following states: Normal down If AdminStatus is down, then OperStatus should be down. If AdminStatus is changed to up, then OperStatus should change to "normal" if the ESU Standalone switch is connected and operational. If the OperStatus of the Standalone ESU is up, the ESU is available to transmit and receive network traffic. If the OperStatus is down and AdminState is up, it indicates the ESU standalone port is disconnected or the link is down. If the Standalone ESU is connected and link appears to be up, but the OperStatus still appears down, there is a fault between the Standalone ESU and the ESM 8668 port that prevents it from going to the up state.
AdminState OperState
Configuring a class of service profile

This section describes how to configure a class of service profile (COS), using Device Manager. To configure a COS using Device Manager: 1 Choose VPN > COS from the Device Manager menu bar. The COS dialog box opens with the COS Profile tab displayed (see Figure 60).
Figure 60 COS dialog boxCOS Profile tab
Insert (opens the COS Profile dialog box).
Click Insert. The COS, Insert COS Profile dialog box opens (see Figure 61 on page 213).
3 4
Click in any field to edit the data. Click Insert to enter the new data. Refer to Table 22 on page 214 for the COS, Insert COS Profile dialog box field descriptions.
320747-A
Configuring the Metro Ethernet Passport 8600 Switch using Device Manager 213 Figure 61 COS, Insert COS Profile dialog box
Table 22 COS, Insert COS Profile dialog box field descriptions

Field TblIndex Name Description Allows you to select the COS profile to create or modify. Allows you to enter a unique name for the COS profile you are creating. Enter an alphanumeric string with a range of 1 and 20 characters. Sets the unit of measure for the Premium COS profile. 64Kbps sets 64 Kb/s service 1Mbps sets 1 Mb/s service Allows you to set a CIR rate for the Premium COS profile. rate is an integer value in the range 1 and 1 000. Enables or disables the Premium PIR service Specifies the size limit, in Kilobytes (KBs) for the associated token bucket. The default value is 50 KB. Enter a number in the range 1 and 8 000, representing a 1 024 byte multiple. Specifies whether the token bucket maximum size (PremiumTBMaxSize) attribute is controlled internally by the software (automatic mode), or by the system administrator (manual mode). The default value is automatic. automatic sets the token bucket max size to internal software control. manual allows you to manually set the token bucket max size. Note: When set to automatic, the related PremiumTBMaxSize attribute (see previous field) cannot be overridden. If set to manual, the related PremiumTBMaxSize attribute is initialized to a default value (50 KB), but can be overridden by the system administrator. Sets the unit of measure for the Gold COS profile. 64Kbps |1Mbps allows you to choose either 64K service or 1 Meg service for your COS profile. Allows you to set a CIR rate for the Gold COS profile. rate is an integer value in the range 1 and 1 000.
PremiumCirUnits
PremiumCir
PremiumPirUsage PremiumTBMaxSize
PremiumTBMaxCtl
GoldCirUnits
GoldCir
320747-A
Configuring the Metro Ethernet Passport 8600 Switch using Device Manager 215 Table 22 COS, Insert COS Profile dialog box field descriptions (continued)
Field GoldPirUsage GoldTBMaxSize Description Enables or disables the Gold PIR service Specifies the size limit, in Kilobytes (KBs) for the associated token bucket. The default value is 50 KB. Enter a number in the range of1 and 8 000, representing a 1 024 byte multiple. Specifies whether the token bucket maximum size (GoldTBMaxSize) attribute is controlled internally by the software (automatic mode), or by the system administrator (manual mode). The default value is automatic. automatic sets the token bucket max size to internal software control. manual allows you to manually set the token bucket max size. Note: When set to automatic, the related GoldTBMaxSize attribute (see previous field) cannot be overridden. If set to manual, the related GoldTBMaxSize attribute is initialized to a default value (50 KB), but can be overridden by the system administrator. Sets the unit of measure for the Silver COS profile. 64Kbps |1Mbps allows you to choose either 64K service or 1 Meg service for your COS profile. Allows you to set a CIR rate for the Silver COS profile. rate is an integer value in the range 1 and 1 000. Enables or disables the Silver PIR service Specifies the size limit, in Kilobytes (KBs) for the associated token bucket. The default value is 50 KB. Enter a umber in the range of 1 and 8 000, representing a 1 024 byte multiple.
GoldTBMaxCtl
SilverCirUnits
SilverCir
SilverPirUsage SilverTBMaxSize
216 Configuring the Metro Ethernet Passport 8600 Switch using Device Manager Table 22 COS, Insert COS Profile dialog box field descriptions (continued)
Field SilverTBMaxCtl Description Specifies whether the token bucket maximum size (SilverTBMaxSize) attribute is controlled internally by the software (automatic mode), or by the system administrator (manual mode). The default value is automatic. automatic sets the token bucket max size to internal software control. manual allows you to manually set the token bucket max size. Note: When set to automatic, the related SilverTBMaxSize attribute (see previous field) cannot be overridden. If set to manual, the related SilverTBMaxSize attribute is initialized to a default value (50 KB), but can be overridden by the system administrator. Sets the unit of measure for the Standard COS profile. 64Kbps |1Mbps allows you to choose either 64K service or 1 Meg service for your COS profile. Allows you to set a CIR rate for the Standard COS profile. rate is an integer value in the range 1 and 1 000. Specifies the size limit, in Kilobytes (KBs) for the associated token bucket. The default value is 50 KB. Enter a number in the range of 1 and 8 000, representing a 1 024 byte multiple. Specifies whether the token bucket maximum size (StandardTBMaxSize) attribute is controlled internally by the software (automatic mode), or by the system administrator (manual mode). The default value is automatic. automatic sets the token bucket max size to internal software control. manual allows you to manually set the token bucket max size. Note: When set to automatic, the related StandardTBMaxSize attribute (see previous field) cannot be overridden. If set to manual, the related StandardTBMaxSize attribute is initialized to a default value (50 KB), but can be overridden by the system administrator.
StandardPirUnits
StandardPir
StandardTBMaxSize
StandardTBMaxCtl
320747-A
Configuring the Metro Ethernet Passport 8600 Switch using Device Manager 217 Table 22 COS, Insert COS Profile dialog box field descriptions (continued)
Field McastLimitUnits Description Sets the multicast limit units. The default is 1 Mbps. unitsOf64kbps is a rate of 64 kbps unitsOf1Mbps is a rate of 1 Mbps Note: The aggregate traffic for the endpoint cannot exceed the standard-pir. Specifies the multiple for the McastRateUnits. If the McastRateUnits is set to 1MB and the McastLimitRate is set to 2 then the multicast data rate would be set to 2MB. The default is 1000. Allows you to enable or disable multicast rate usage. The default is disable. Specifies where the maximum token bucket size attribute is being used to control the multicast bucket or not. The default is automatic. automatic sets the token bucket max size to internal software control. manual allows you to manually set the token bucket max size. Specifies the maximum token bucket size limit for the multicast bucket, in kilobytes. The default value is 1. Enter a number in the range of 1 and 8000, representing a 1024 byte multiple.
McastLimitRate
McastLimitUsage McastLimitTBMaxCtl
McastLimitTBMaxSize
Configuring a user-to-network interface

This section describes how to configure or modify a user-to-network interface (UNI), using Device Manager. To configure a UNI, using Device Manager: 1 Choose VPN > UNI from the Device Manager menu bar. The UNI dialog box opens with the UNI tab displayed (see Figure 62).
Figure 62 UNI dialog box UNI tab
Click Insert. The UNI, Insert UNI dialog box opens (see Figure 63 on page 219).
320747-A
3 4
Click in any field to edit the data. Click Insert to enter the new data. Refer to Table 23 on page 220 for the UNI tab and UNI, Insert UNI dialog box field descriptions.
Figure 63 UNI, Insert UNI dialog box
Click the appropriate ellipses button to open the Port or Server port dialog box.
Table 23 UNI tab and UNI, Insert UNI dialog box field descriptions
Field Addr Description Allows you to enter the UNI ID (in IP notation). The UNI ID is restricted to a 32-bit IP address range, where the first octet (the most significant bits) is in the range 0 and 255. Sets a unique name for the UNI. Enter an alphanumeric string (in the range 1 and 63 alphanumeric charaters) that uniquely identifies the TD. Allows you to set the TLS UNI physical port to assign to the UNI ID. port indicates the slot/port number of the TLS UNI ID. Note: this parameter is used only for the local TLS access ports or the local server access ports. Allows you to set the TLS Server physical port to assign to the UNI ID. port indicates the slot/port number of the TLS Server UNI ID. Allows you to set the service type value for the UNI ID. tlstransparent sets the service type value to tls transparent mode. tlsswitched sets the service type value to tls switched mode. qnq1 sets the service type value to Q&Q (1) mode. qnq2 sets the service type value to Q&Q (2) mode. Allows you to enter a unique integer value, in the range of 1 and 254, which represents the ESU ring number that the Metro ESU 1850 is connected to. Allows you to enter a unique integer value (in the range of 1 and 24) that identifies the Metro ESU 1850, within the ring. Allows you to enter a unique integer value (in the range 1 and 28) that identifies the physical port on the Metro ESU 1850. Sets the standalone Id number for the port. Enter an integer value in the range 0 and 24.
Name
Port
ServerPort
ServiceType
RingId
EsuModId
EsuPort
StandaloneEsuId
320747-A
Configuring the Metro Ethernet Passport 8600 Switch using Device Manager 221 Table 23 UNI tab and UNI, Insert UNI dialog box field descriptions (continued)
Field StandaloneEsuPort AdminState Description Sets the ports that are to be used for ESU ring ports (ports 25 to 28). Set the administrative state of the UNI. enable sets the UNI state to enable. disable sets the UNI state to enable. OperState for UNI. Appears as one of the following states: Up Down If AdminStatus for the UNI is down, then OperStatus should be down. If AdminStatus is changed to up, then OperStatus should change to normal if the port assigned to the UNI has a valid link up state. If the OperStatus of the UNI is up, the UNI is available to transmit and receive network traffic. If the OperStatus is down and AdminState is up, it indicates the port assigned to the UNI is disconnected or the ports link is down. If the port for the UNI is connected and link appears to be up, but the OperStatus still appears down, there is a fault condition for the assigned UNI that prevents it from going to the up state.
OperState
Configuring a UNI MAC address

This section describes how to configure or modify a UNI MAC address, using Device Manager. To configure a UNI MAC address, using Device Manager: 1 Choose VPN > UNI Mac from the Device Manager menu bar. The UNI_Mac dialog box opens with the UNI Mac tab displayed (see Figure 64). 2 Click Insert in the UNI_Mac dialog box. The UNI_Mac, Insert UNI Mac dialog box opens (see Figure 64).
Figure 64 UNI_Mac dialog box UNI Mac tab
Click Insert to open the UNI_MAC, Insert UNI Mac dialog box.
320747-A
In the UNI_Mac, Insert UNI Mac dialog box ADDR field, enter an IP address of the destination UNI ID. Note: The destination UNI ID is restricted to a 32-bit IP address range, where the first octet (of the most significant bits) is in the range 0 and 255.
In the UNI_Mac, Insert UNI Mac dialog box MacOpm field, enter a MAC address for the destination UNI ID. Enter the destination UNI ID MAC address in the form: 00.00.00.00.00.00.
Click Insert. The new UNI MAC address appears in the UNI_Mac dialog box (see Figure 64 on page 222).
Configuring transparent domain identifiers

This section includes the following topics: Configuring a general TDI on page 225 Displaying TDI statistics on page 227 Configuring a destination UNI on page 232 Configuring a TDI endpoint on page 233 Displaying TDI endpoint statistics on page 239 Configuring a TDs User MAC address on page 241
320747-A
Configuring a general TDI

This section describes how to configure or modify a general TDI, using Device Manager. To configure a TDI, using Device Manager: 1 From the Device Manager menu bar, choose VPN > TDI. The TDI dialog box opens with the General tab displayed (see Figure 65).
Figure 65 TDI dialog boxGeneral tab
Click Insert to open the TDI, Insert General dialog box.
In the TDI dialog box, General tab, click Insert. The TDI, Insert General dialog box opens (see Figure 65).
In the TDI, Insert General dialog box, click in any field to edit the data. Refer to Table 24 for the TDI, Insert General dialog box dialog box field descriptions.
In the TDI, Insert General dialog box, click Insert to enter new data. The new data appears in the TDI dialog box (see Figure 65 on page 225).
Table 24 TDI, Insert General dialog box field descriptions

Field Id Description Allows you to enter a unique integer value, in the range 1 and 16 777 215, that represents the Transparent Domain identity. Allows you to enter a unique name that represents the Transparent Domain identity. Sets the Mapped NNI VLAN for the TDI. number is an integer value in the range 1 and 4 093 that represents the Mapped NNI VLAN ID. Sets the MUX mode for TLS-switched endpoints that are assigned to the TDI. oneToone sets the MUX mode value to one-to-one mode. manyToOne sets the MUX mode value to many-to-one mode Indicates the way the TDI handles learned MACs. Sets the administrative state of the TDI. enable sets the TDI state to enable. disable sets the TDI state to enable.
Name MappedVlan
MuxMode
Action AdminState
320747-A
Displaying TDI statistics

This section describes how to display TDI statistics using Device Manager. To reset the statistics counters, use the Clear Counter button. When you click this button, all Cumulative, Average, Minimum, Maximum, and LastVal columns are reset to zero and automatically begin to recalculate statistical data. Note: Device Managers Clear Counter function does not affect the switchs AbsoluteValue counter. The Clear Counter function clears all cached data in Device Manager (except AbsoluteValue). To reset AbsoluteValue(s), use the resetCounter function (Edit > Chassis > System). To display TDI statistics using Device Manager: 1 From the Device Manager menu bar, choose VPN > TDI. The TDI dialog box opens with the General tab displayed (see Figure 65 on page 225). 2 Click on the TDI Id you want to query. The Graph button becomes highlighted. 3 Click the Graph button.
The Statistics, TLS TDI tab opens and displays statistics for the selected TDI (see Figure 66).
Figure 66 Statistics, TLS TDI tab
Refer to Table 25 for the Statistics, UNI IP Service dialog box field descriptions.
320747-A
Table 25 Statistics dialog box field descriptions

Field Absolute Value Cumulative Average/Sec Minimum/Sec Maximum/Sec LastVal/Sec PremRxOctets PremRxDroppedOctets GoldRxOctets GoldRxDroppedOctets SilverRxOctets SilverRxDroppedOctets StndRxOctets StndDroppedOctets PremTxOctets PremMcastRxDroppedOCtets GoldMcastRxDroppedOCtets SilverMcastRxDroppedOCtets StndMcastRxDroppedOCtets PremRxMcastOctets GoldTxOctets GoldRxMcastOctets SilverTxOctets SilverRxMcastOctets Description The absolute value of the received/transmitted/dropped octets. The total number of received/transmitted/dropped octets. The average number of received/transmitted/dropped octets per second. The minimum number of received/transmitted/dropped octets per second. The maximum number of received/transmitted/dropped octets per second. This field does not apply to UNI IP Service Statistics. The number of received premium octets. The number of dropped received premium octets. The number of received gold octets. The number of dropped received gold octets. The number of received silver octets. The number of dropped received silver octets. The number of received standard octets. The number of dropped received standard octets. The number of transmitted premium octets. The number of dropped received multicast premium octets. The number of dropped received multicast gold octets. The number of dropped received multicast silver octets. The number of dropped received multicast standard octets. The number of transmitted multicast premium octets. The number of transmitted gold octets. The number of transmitted multicast gold octets. The number of transmitted silver octets. The number of transmitted multicast silver octets.
230 Configuring the Metro Ethernet Passport 8600 Switch using Device Manager Table 25 Statistics dialog box field descriptions
Field StndTxOctets StndRxMcastOctets PremCongestionDropOctets GoldCongestionDropOctets SilverCongestionDropOctets StndCongestionDropOctets PremCirDroppedOctets PremPirDroppedOctets GoldCirDroppedOctets GoldPirDroppedOctets SilverCirDroppedOctets SilverPirDroppedOctets StndCirDroppedOctets StndPirDroppedOctets PremTxDroppedOctets PremTxCongestionDropOctets GoldTxDroppedOctets GoldTxCongestionDropOctets SilverTxDroppedOctets SilverTxCongestionDropOctets StndTxDroppedOctets StndTxCongestionDropOctets PremTxCirDroppedOctets PremTxPirDroppedOctets GoldTxCirDroppedOctets Description The number of transmitted standard octets. The number of transmitted multicast standard octets. The number of premium octets dropped due to congestion. The number of gold octets dropped due to congestion. The number of silver octets dropped due to congestion. The number of standard octets dropped due to congestion. The number of dropped premium CIR octets. The number of dropped premium PIR octets. The number of dropped gold CIR octets. The number of dropped gold PIR octets. The number of dropped silver CIR octets. The number of dropped silver PIR octets. The number of dropped standard CIR octets. The number of dropped standard PIR octets. The number of premium dropped transmitted octets. The number of premium dropped transmitted octets due to congestion. The number of gold dropped transmitted octets. The number of gold dropped transmitted octets due to congestion. The number of silver dropped transmitted octets. The number of silver dropped transmitted octets due to congestion. The number of standard dropped transmitted octets. The number of standard dropped transmitted octets due to congestion. The number of dropped transmitted premium CIR octets. The number of dropped transmitted premium PIR octets. The number of dropped transmitted gold CIR octets.
320747-A
Configuring the Metro Ethernet Passport 8600 Switch using Device Manager 231 Table 25 Statistics dialog box field descriptions
Field GoldTxPirDroppedOctets SilverTxCirDroppedOctets SilverTxPirDroppedOctets StndTxCirDroppedOctets StndTxPirDroppedOctets RxMcastTotalOctets TxMcastTotalOctets Description The number of dropped transmitted gold PIR octets. The number of dropped transmitted silver CIR octets. The number of dropped transmitted silver PIR octets. The number of dropped transmitted standard CIR octets. The number of dropped transmitted standard PIR octets. The total number of received multicast octets. The total number of transmitted multicast octets.
Configuring a destination UNI

This section describes how to configure or modify a destination UNI ID for a TDI, using Device Manager. To configure a destination UNI ID, using Device Manager: 1 From the Device Manager menu bar, choose VPN > TDI. The TDI dialog box opens with the General tab displayed (see Figure 65 on page 225). 2 In the TDI dialog box, click the Dest UNI tab. The TDI dialog boxDest UNI tab opens (see Figure 67). 3 In the Dest UNI tab, click on the DestUniAddr field for the UNI Id. The TDI, Insert Dest UNI dialog box opens (see Figure 67).
Figure 67 TDI dialog boxDest UNI tab
4 5
In the TDI, Dest UNI tab, DestUniAddr field, enter the static destination UNI ID (in IP notation) of the transparent domain identifier. Click Apply. The new data appears in the TDI dialog boxDest UNI tab (see Figure 67).
320747-A
Configuring a TDI endpoint

This section describes how to configure or modify a TDI endpoint, using Device Manager. To configure a TDI endpoint, using Device Manager: 1 From the Device Manager menu bar, choose VPN > TDI. The TDI dialog box opens with the General tab displayed (see Figure 65 on page 225). 2 In the TDI dialog box, click the Endpoint tab. The TDI dialog boxEndpoint tab opens (see Figure 68).
Figure 68 TDI dialog box Endpoint tab
Click Insert to open the TDI, Insert Endpoint dialog box.
In the TDI dialog boxEndpoint tab, click Insert. The TDI, Insert Endpoint dialog box opens (see Figure 69 on page 234.)
234 Configuring the Metro Ethernet Passport 8600 Switch using Device Manager Figure 69 TDI, Insert Endpoint dialog box
In the TDI, Insert Endpoint dialog box, click in any field to edit the data. Refer to Table 26 on page 235 for the TDI, Insert Endpoint dialog box field descriptions.
When you are finished, click Insert. The new data appears in the TDI dialog boxEndpoint tab (see Figure 68 on page 233).
320747-A
Refer to Table 26 for a description of the Endpoint tab and TDI, Insert Endpoint dialog box fields.
Table 26 Endpoint tab and TDI, Insert Endpoint dialog box field descriptions
Field TdId Description Sets a unique numeric value, in the range 1 and 16 777 215, that represents the id of the transparent domain you are configuring. Sets the UNI ID (in IP notation) Allows you to enter a unique name that identifies the TDI endpoint. Enter a string length in the range 1 and 32 alphanumeric characters. Allows you to set the connection-type value for the endpoint. any2any sets the connection-type value to any-to-any mode. hub sets the connection-type value to hub mode. spoke sets the connection-type value to spoke mode. pt2pt sets the connection-type value to point-to-point mode. Sets the administrative state of the UNI. enable sets the UNI state to enable. disable sets the UNI state to enable. Sets the remote-destination UNI ID for point-to-point and spoke endpoints. Enter a destination UNI ID (in IP notation). Optional: Enter the MAC address of the destination UNI ID. Sets the MAC address for the endpoint in the format of 0x00:0x00:0x00:0x00:0x00:0x00
UniAddr Name
ConMode
AdminState
RemoteUni
MacAddr
236 Configuring the Metro Ethernet Passport 8600 Switch using Device Manager Table 26 Endpoint tab and TDI, Insert Endpoint dialog box field descriptions
Field BpduTraffic Description Sets the BPDU Traffic control for the specified endpoint. The default setting is normal. normal all BPDU traffic forwards without restriction. expedite sets the endpoint to expedite forwarding of BPDU packets by raising the QoS level to the highest level defined within the priority mapping values. drop drops selected BPDU traffic. This read-only field appears on the Endpoint tab only. Sets the MAC address ageing timer for locally learned customer destination MAC address. number is an integer value in the range 1 and 65 535 seconds, that represents the ageing time. Sets the MAC address ageing timer for customer destination MAC address learned from remote network UNI IDs. number is an integer value in the range 1 and 65 535 seconds, that represents the ageing time. Sets the maximum MAC table size for the endpoint. Enter an integer value in the range 0 and 97 000 entries, that represents the MAC table size. Note: If you enter a value of 0 (zero) you disable the MAC table size parameter. Defines a high-watermark threshold for the MAC table size. When this threshold is exceeded, the system sends an SNMP trap to inform you that the threshold limit has been exceeded. Enter an integer value in the range 0 and 100%, that represents the MAC table size threshold limit. Note: If you enter a value of 0 (zero) you disable the mac-table-watermark threshold parameter. Sets the Cos profile for the ingress endpoint. Choose from a predefined selection of cos profiles. Default value is Default_Profile.
Action LocalMacAgeTimer
RemoteMacAgeTimer
MacTblSize
MacTblWaterMk
IngressCosProfileName
320747-A
Configuring the Metro Ethernet Passport 8600 Switch using Device Manager 237 Table 26 Endpoint tab and TDI, Insert Endpoint dialog box field descriptions
Field EgressCosProfileName Description Sets the Cos profile for the egress endpoint. Choose from a predefined selection of cos profiles. Default value is Default_Profile. Allows you to enable or disable the specified endpoints ingress cos-profile command. enable enables the ingress cos-profile command. disable disables the ingress cos-profile command. Allows you to enable or disable the specified endpoints egress cos-profile command. enable enables the egress cos-profile command. disable disables the egress cos-profile command. Sets the SP priority mapping for the endpoint. Enter a string length in the format a:b:c:d:e:f:g:h. Where: Each string character represents a value in the range 0 and 7, which indicates the SP QoS remarking. Configures the endpoint to use DSCP/TOS bits for QoS classification. Checked indicates that the endpoint uses DSCP/TOS bits for QoS classification. Unchecked indicates that the endpoint uses P-bits for QoS classification. Sets the q-tags to the TLS-switched endpoints. Enter an integer value in the range 1 and 4 096, that represents the customer 802.1 q-tag ID. Note: Q-tag 4096 is a special tag ID for classifying untagged packets.
IngressPolicer
EgressPolicer
PriMapping
PriOverride
Qtags
238 Configuring the Metro Ethernet Passport 8600 Switch using Device Manager Table 26 Endpoint tab and TDI, Insert Endpoint dialog box field descriptions
Field OuterQtag Description Adds an outer q-tag parameter for a Q&Q -type endpoint. Enter an integer value in the range 1 and 4 095, that represents the customer 802.1 q-tag ID. OperState for Endpoint. Appears as one of the following states: Up Down If AdminStatusfor the Endpoint is down, then OperStatus should be down. If AdminStatus is changed to up, then OperStatus should change to "normal" if the UNI and the assigned TDI are in a valid up state. If the OperStatus of the Endpoint is up, the Endpoint is available to transmit and receive network traffic. If the OperStatus is down and AdminState is up, it indicates either the UNI or the assigned TDI is in a down state. Confirm the TDI AdminState is up and that the UNI is OperStatus up. If the assigned port (UNI) for the Endpoint is connected and link appears to be up, but the OperStatus for the Endpoint still appears down, there is a fault condition for the Endpoint that prevents it from going to the up state.
OperState
320747-A
Displaying TDI endpoint statistics

This section describes how to display TDI endpoint statistics, using Device Manager. To reset the statistics counters, use the Clear Counter button. When you click this button, all Cumulative, Average, Minimum, Maximum, and LastVal columns are reset to zero and automatically begin to recalculate statistical data. Note: Device Managers Clear Counter function does not affect the switchs AbsoluteValue counter. The Clear Counter function clears all cached data in Device Manager (except AbsoluteValue). To reset AbsoluteValue(s), use the resetCounter function (Edit > Chassis > System). To display TDI endpoint statistics using Device Manager: 1 From the Device Manager menu bar, choose VPN > TDI. The TDI dialog box opens with the General tab displayed (see Figure 65 on page 225). 2 Click the TDI Id for the endpoint you want to query. The Graph button becomes highlighted. 3 Click the Graph button.
The Statistics, TLS Endpoint tab opens and displays statistics for the selected TDI (see Figure 70).
Figure 70 Statistics, TLS Endpoint tab
Refer to Table 25 on page 229 for the Statistics, TLS Endpoint tab dialog box field descriptions. 4
320747-A
Click Clear Counters to reset the statistics.
Configuring a TDs User MAC address

This section describes how to configure or modify a User MAC address for a TDI, using Device Manager. To configure a User MAC address for a TDI, using Device Manager: 1 From the Device Manager menu bar, choose VPN > TDI. The TDI dialog box opens with the General tab displayed (see Figure 65 on page 225). 2 In the TDI dialog box, click the User MAC tab. The TDI dialog boxUser MAC tab opens (see Figure 71). 3 In the User MAC tab, click Insert. The TDI, Insert User MAC dialog box opens (see Figure 71).
Figure 71 TDI dialog box User MAC tab
Click Insert to open the TDI, Insert User MAC dialog box.
In the TDI, Insert User MAC dialog box TdId field, enter a unique numeric value, in the range 1 and 16,777,215, that represents the id of the transparent domain you are configuring. In the TDI, Insert User MAC dialog box Addr field, enter the static customer-destination User MAC address. Enter this parameter value in the form: 0x00:0x00:0x00:0x00:0x00:0x00.
In the TDI, Insert User MAC dialog box TdiUserUniAddr field, enter the remote destination UNI ID for the configured static customer-destination User MAC address. Click Insert. The new data appears in the TDI dialog boxUser MAC tab (see Figure 71 on page 241).
Refer to Table 27 for the TDI, Insert User MAC dialog box field descriptions.
Table 27 TDI, Insert User MAC dialog box field descriptions
Field TdId Description Represents the id of the transparent domain you are configuring. Enter a unique numeric value, in the range 1 and 16,777,215. Identifies the static customer-destination User MAC address. Enter this parameter value in the form: 0x00:0x00:0x00:0x00:0x00:0x00. The remote destination UNI ID for the configured static customer-destination User MAC address.
MacAddress
DestUni
320747-A
Displaying Metro ESM 8668 server-port statistics

Your Metro ESM 8668 module provides statistics that can help you monitor traffic utilization on a specified ESM-server port. Each Metro ESM 8668 server port can provide a full range of statistics on your Device Manager display, including the last 15 minute interval, hourly, and daily accumulation. MIBs can maintain up to 24 hours of data per Metro ESM 8668 server port, which you can access. The total number of entries stored per Metro ESM 8668 port is 1 440 entries: (24 hours x 60 minutes / Hour x 1 data collection / minutes = 1440 entries). Device Manager can display the following current information: Last 15-minute statistics Device Manager can display the previous 15 minutes on each quarter hour. The display includes minimum Bytes/sec, maximum Bytes/sec, and average Bytes/sec, for each 1-minute interval during the last 15 minutes. Hour level Device Manager can display the previous hourly stats, by ESM server port, for the past 24 hours collected, and up to the last quarter hour (for example, if it is currently 2:15 PM, the display starts at 2:15 PM of the previous day). The display includes only the average of the Bytes/sec to a granularity of 1 minute, for each 60 minute interval. If the current or last hour data is a partial hour, the last hour displayed is up to the last quarter hour and the average is for the total partial minutes received (for example, if the last hour entry is 2:00 to 2:14, average is for the 15-minute interval, not 60). Stats-daily-level Device Manager can display the previous 24-hour statistics, by ESM server port. The display includes only the average of the bytes per second to a granularity of 1 minute. For a 24-hour period, this is for the last 1 440 data statistics collected per ESM server port.
This section includes the following topics: Displaying current Metro ESM 8668 information, next Displaying ESM port statistics on page 247 Displaying ESM port statistics for the last 15 minutes on page 248 Displaying ESM port statistics for the last hour on page 249 Displaying daily ESM port statistics for all ports on page 250 Clearing ESM port statistics on page 251
320747-A
Displaying current Metro ESM 8668 information

You can use Device Manager to display current information about your Metro ESM 8668 module, including the ESM server port, legacy port, and UNI Id. To display current Metro ESM 8668 server statistics, using Device Manager: 1 From the Device Manager menu bar, choose VPN > ESM. The ESM dialog box opens with the ESM tab displayed (see Figure 72 on page 246).
246 Configuring the Metro Ethernet Passport 8600 Switch using Device Manager Figure 72 ESM dialog boxESM tab
ESM information: (ESM port, legacy port, UNI Id).
Hourly statistics.
Last 15-minutes statistics.
Statistics ESM port.
Use the scroll bar to display all rows.
320747-A
Displaying ESM port statistics

This section describes how to display ESM port statistics, using Device Manager. To display ESM port statistics, using Device Manager: 1 From the Device Manager menu bar, choose VPN > ESM. The ESM dialog box opens with the ESM tab displayed (see Figure 72 on page 246). 2 Click on the ESM port you want to query. The Stats, Stats: Last-15minutes, and Stats: Hour-Level buttons are highlighted. 3 Click Stats. The Stats dialog box opens with the ESM Statistics tab displayed (see Figure 73). Figure 73 Stats dialog boxESM Statistics tab
Displaying ESM port statistics for the last 15 minutes

This section describes how to display ESM port statistics, which occurred during the last 15 minutes, using Device Manager. To display the last 15 minutes of ESM port statistics, using Device Manager: 1 From the Device Manager menu bar, choose VPN > ESM. The ESM dialog box opens with the ESM tab displayed (see Figure 72 on page 246). 2 Click on the ESM port you want to query. The Stats, Stats: Last-15minutes, and Stats: Hour-Level buttons are highlighted. 3 Click Stats: Last-15minutes. The Stats: Last-15minutes dialog box opens with the Statistics: Last15minutes tab displayed (see Figure 74).
Figure 74 Stats: Last-15minutes dialog boxStatistics: Last15minutes tab
320747-A
Displaying ESM port statistics for the last hour

This section describes how to display ESM port statistics, which occurred during the last hour, using Device Manager. To display the last hour of ESM port statistics, using Device Manager: 1 From the Device Manager menu bar, choose VPN > ESM. The ESM dialog box opens with the ESM tab displayed (see Figure 72 on page 246). 2 Click on the ESM port you want to query. The Stats, Stats: Last-15minutes, and Stats: Hour-Level buttons are highlighted. 3 Click Stats: Hour-Level. The Stats: Hour-Level dialog box opens with the Statistics: Hour-Level tab displayed (see Figure 75).
Figure 75 Stats: Hour-Level dialog boxStatistics: Hour-Level tab
Displaying daily ESM port statistics for all ports

This section describes how to display ESM port statistics for all ports, which occurred during the previous 24 hours, using Device Manager. To display daily ESM port statistics for all ports, using Device Manager: 1 From the Device Manager menu bar, choose VPN > ESM. The ESM dialog box opens with the ESM tab displayed (see Figure 72 on page 246). 2 Click the Statistics: Daily For All Ports tab. The Statistics: Daily For All Ports tab opens and displays statistics for all ports, which occurred during the previous 24 hours (see Figure 76).
Figure 76 Statistics: Daily For All Ports tab
320747-A
Clearing ESM port statistics

To show or clear the current Metro ESM 8668 server statistics, using Device Manager: 1 From the Device Manager menu bar, choose VPN > ESM. The ESM dialog box opens with the ESM tab displayed (see Figure 72 on page 246). 2 Click the Clear Ports Stats tab. The Clear Ports Stats tab opens and displays all the ports. 3 Go to the Clear Stats field for the port you wish to clear the statistics for, click on the field and select true to clear the statistics (see Figure 77).
Figure 77 Clear Port Stats tab
Click Apply.
Configuring the Metro Ethernet Passport 8600 repeater feature

Your Metro Ethernet Passport 8600 Switch supports a repeater functionality that allows for MAC regeneration of data traffic over long haul connections. MAC regeneration is supported on 8608GBIC Gigabit links using any supported GBIC interface (for example, 1000SX, 1000LX, 1000T, and so forth.). All GBIC series modules are supported. Each repeater function comprises Gigabit port pairs, with unique VLAN Ids for each repeater. You can assign a total of 32 repeaters per chassis. To configure the Metro Ethernet Passport 8600 Switch repeater functionality, using Device Manager: 1 From the Device Manager menu bar, choose VLAN > Repeater. The Repeater dialog box opens with the Repeater tab displayed (see Figure 78 on page 253).
320747-A
Configuring the Metro Ethernet Passport 8600 Switch using Device Manager 253 Figure 78 Repeater dialog boxRepeater tab
Click Insert to open the Insert Repeater dialog box.
Click the ellipsis buttons to open the port dialog boxes.
Click Insert. The Repeater, Insert Repeater dialog box opens (see Figure 78).
In the Repeater, Insert Repeater dialog box, enter the following information into the display field: a b c d e f The Id number for the repeater (enter a unique integer value in the range 1 and 32). Click the First Port ellipses button and select the first repeater port. Click the Second Port ellipses button and select the second repeater port. Enter the VLAN Id number for the repeater VLAN (enter a unique integer value in the range 0 and 4 094). Enter a unique name for the repeater function. Click Insert.
320747-A
Configuring a UNI Customer IP VLAN

To configure the Metro Ethernet Passport 8600 UNI customer IP VLAN, using Device Manager you must follow these procedures: Creating an SP VLAN on page 256 Configuring a Customer IP VLAN on page 260 Showing UNI IP Statistics on page 264 Configuring a VLAN TLS-IPMC on page 267
Creating an SP VLAN
To create the Metro Ethernet Passport 8600 services provider VLAN, using Device Manager you will need to: 1 From the Device Manager menu bar, choose VLAN > VLANS. The VLAN dialog box opens with the Basic tab displayed (see Figure 79).
Figure 79 VLAN Basic tab
Click Insert. The VLAN Insert Basic dialog box opens (see Figure 80 on page 257).
320747-A
Configuring the Metro Ethernet Passport 8600 Switch using Device Manager 257 Figure 80 VLAN Insert Basic dialog box
Refer to Table 28 on page 258 for the VLAN, Inset Basic dialog box field descriptions. a b c d In the VLAN Insert Basic dialog box, ID field, type the ID of the VLAN. In the VLAN Insert Basic dialog box, name field, type in the name of the VLAN. In the VLAN Insert Basic dialog box, StgId field, select the spanning tree group id. In the VLAN Insert Basic dialog box, Type field, click a radio button for VLAN type.
e f g 3
In the VLAN Insert Basic dialog box, PortMembers field, click the ellipsis button and select the ports to be members. In the VLAN Insert Basic dialog box, QoSLevel field, click a radio button for the Quality of Service Level. Click Insert.
Click Apply and then Refresh. The port number appears in the PortMembers column (see Figure 81.)
Figure 81 VLAN Basic showing PortNumbers
If desired, enable the IP multicast for this Service Provider IP service by double-clicking on the TlsIpmc field and selecting enable.
Table 28 VLAN, Inset Basic dialog box field descriptions

Field Id Name Color Identifier Description Allows you to enter the number of the VLAN. Ranges from 1 to 4 093 Allows you to enter the name of the VLAN. Allows you to color code the VLANs for the optional VLAN manager application available through Nortel NMS applications such as ONMS. Allows you to define which spanning tree group to use for this VLAN. Allows you to select the ports to be members of the VLAN.
StgId PortMembers
320747-A
Configuring the Metro Ethernet Passport 8600 Switch using Device Manager 259 Table 28 VLAN, Inset Basic dialog box field descriptions (continued)
Field Type Description Allows you to define different protocol based VLANs. default is byport Note: Release 4.0 only supports byport. Allows you to set a Quality of Service for a VLAN. level 0: Standard level 1: Standard level 2: Silver level 3: Silver level 4: Gold level 5: Gold level 6: Premium level 7: Premium default QoS level for Port, VLAN and MAC-based filters is level 1.
QoS Level
Configuring a Customer IP VLAN

To configure the Metro Ethernet Passport 8600 UNI customer IP VLAN: 1 From the Device Manager menu bar, choose VPN > UNI. The UNI window opens with the UNI tab displayed (see Figure 82).
Figure 82 VLAN UNI tab
Click on the Cust IP Vlan tab. The Cust IP Vlan tab opens (see Figure 83).
Figure 83 VLAN Cust IP Vlan tab
Click Insert. The UNI, Insert Cust IP Vlan dialog box opens (see Figure 84 on page 261).
320747-A
Configuring the Metro Ethernet Passport 8600 Switch using Device Manager 261 Figure 84 UNI, Insert Cust IP Vlan
Edit the fields and click Insert to save your changes. The completed customer IP VLAN displays (see Figure 85).
Figure 85 VLAN UNI Cust IP Vlan showing details
Refer to Table 29 for the Cust IP Vlan tab and UNI, Insert Cust IP Vlan dialog box field descriptions.
Table 29 Cust IP Vlan tab and UNI, Insert Cust IP Vlan dialog box field descriptions
Field Addr CustIPVlan ServiceProviderIpVlan Name Description Allows you to enter the IP address of the destination UNI. Allows to enter a number for the Customer IP VLAN. range is 1 to 4 096. Allows you to enter a number for the SP Vlan range is 1 to 4 096. Allows you to enter the name of the UNI IP Service VLAN Entry. Enter an alphanumeric string up to 30 characters in length. By default, it is VLAN-<uni id>-<cust ip vlan>. Allows you to set the ageout timer in seconds. range is 1 to 1 966 020. Allows you to set the TLS UNI IP table watermark percentage value between 0 and 90%. Allows you to enter Ingress Cos Profile Table Name for Customer Ip Service. Choose from a predefined selection of cos profiles. Default value is Default_Profile. Allows you to enter Egress Cos Profile Table Name for Customer IP Service. Choose from a predefined selection of cos profiles. Default value is Default_Profile. Allows you to enable/disable to use Ingress Cos Profile table for this customer IP service. default is enable. Allows you to enable/disable to use Egress Cos Profile table for this IP service. default is disable.
Age Timer IPTable/WaterMark(%) IngressCosProfileName
EgressCosProfileName
IngressPolicer
EgressPolicer
320747-A
Configuring the Metro Ethernet Passport 8600 Switch using Device Manager 263 Table 29 Cust IP Vlan tab and UNI, Insert Cust IP Vlan dialog box field descriptions (continued)
Field Action Description Allows you manually flush the learned IP entries from the customer-IP-VLAN table. It is normally used after the entry is made and IP addresses have been learned. You click on the action field of the Cust IP VLAN tab (default is none) and select fluship. You then click apply, and the IP addresses learned for that UNI ID are flushed. default is none. Allows you to configure the administrative state of the IP service. enable allows IP service. disable turns off IP service. default is disable. OperState for Cust IP VLAN. Appears as one of the following states: Up Down If AdminStatusfor the Cust-IP-VLAN is down, then OperStatus should be down. If AdminStatus is changed to up, then OperStatus should change to normal if the assigned UNI is AdminState up and OperState up. If the OperState of the Cust-IP-VLAN is up, the IP Endpoint is available to transmit and receive network traffic. If the OperState is down and AdminState is up, it indicates either the UNI is AdminState down or OperState for the UNI is down. If the assigned port (UNI) for the IP Endpoint is connected and link appears to be up, but the OperStatus for the IP Endpoint still appears down, there is a fault condition for the IP Endpoint that prevents it from going to the up state. Allows you to configure the UNI IP service priority-mapping command. format is 00:00:00:00:00:00:00:00 each value is between 0 and 7. Allows you to set the Priority Override. default is unchecked. Allows you to set the IP Table size. range is 0 to 97 000.
AdminState
OperState
PriMapping
PriOverride IpTableSize
Showing UNI IP Statistics

To view UNI IP Statistics for a customer IP VLAN: 1 From the Device Manager menu bar, choose VPN > UNI. The UNI window opens with the UNI tab displayed (see Figure 82 on page 260). 2 Click on the Cust IP Vlan tab. The Cust IP Vlan tab opens (see Figure 83 on page 260). 3 Select a customer IP VLAN and click Graph. The Statistics, UNI IP Service window opens with the Statistics tab displayed (see Figure 83 on page 260).
320747-A
Configuring the Metro Ethernet Passport 8600 Switch using Device Manager 265 Figure 86 Statistics, UNI IP Services window
Refer to Table 25 on page 229 for the Statistics, UNI IP Service dialog box field descriptions.
320747-A
Configuring a VLAN TLS-IPMC

To configure the Metro Ethernet Passport 8600 UNI VLAN TLS-IPMC, using Device Manager you will need to: 1 2 From the Device Manager menu bar, choose VLAN > VLANS. The VLANS screen appears with the Basic tab open.In the VLANS, Basic tab, scroll right until you see the TLS-IPMC field for a VLAN that you want to change. Double-click on the cell for the VLAN that you want to enable (see Figure 87).
Figure 87 VLAN Basic tab
3 4
Select enable from the scroll down list. Click Apply.
Configuring a VLACP
To configure the Metro Ethernet Passport 8600 UNI VLACP: 1 From the Device Manager menu bar, choose VLAN > MLT/VLACP. The MLT_VLACP dialog box opens with the MultiLinkTrunks tab displayed (see Figure 88).
Figure 88 MLT_VLACP dialog box
Click on VLACP. The VLACP tab opens (see Figure 89).
Figure 89 VLACP tab
Change the values for VLACP and TimeoutScale, if necessary. Click Apply to save your changes.
320747-A
Refer to Table 30 for a list of VLACP tab field descriptions.
Table 30 VLACP tab field descriptions

Field Id Vlacp Description Identifies the VLAN. Enables or disables VLACP for the selected VLAN. The valid values are true (enable) or false (disable). To change the value, double click the field and select true to enable VLACP or false to disable it. Displays the number of milliseconds between periodic transmissions, using Short Timeouts. Specifies the scalar value used to calculate the timeout time from the periodic time. Timeout = PeriodicTime * TimeoutScale. To change the value, double-click the field and enter a new value. The default is 3.
FastPeriodicTimer TimeoutScale
320747-A
271
Glossary
Access port
Any port on the Metro Ethernet Passport 8600 that connects to customer equipment either directly or indirectly through the Optical Metro 1200 or ESU Ethernet Services Module (ESM).
Address Resolution Protocol (ARP)
ARP is the protocol used in routing tables to map an IP address to a MAC address for a device.
Asynchronous Transfer Mode (ATM)
ATM protocol is a connection-oriented, cell-based technology that relays traffic across a Broadband Integrated Services Digital Network (B-ISDN). ATM provides a cost-effective way of transmitting voice, video, and data across a network. This technology delivers 155 megabits-per-second (Mb/s) per-port performance over fiber-optic cable and shielded twisted pair wire.
Binding
Label Switched Routers (LSRs) create label bindings that map labels and Forwarding Equivalency Classes (FECs), and then inform other LSRs of these bindings.
Boundary port
A Bridge Port attaching an MST Bridge to a LAN that is not in the same region.
Bridge Protocol Data Unit (BPDU)
The control tag in a PDU for a bridge between networks.

Carrier Located Equipment (CLE)
A device owned by the service provider, which is used to provide services to the customer.
272 Glossary
Circuitless IP (CLIP)
An address that is bound to a device, not a specific port on the device.

Class of Service (CoS)
CoS and Quality of Service (QoS) are terms that are often used interchangeably. CoS consists of a localized policy and mechanism: Policy- service classification that assigns a stream to a particular class Mechanism- subjectively discriminates between streams based on current resource conditions and service classification
Command Line Interface (CLI)
The operating language for many Nortel products.

Common and Internal Spanning Tree (CIST)
The single spanning tree calculated by STP and RSTP together with the logical continuation of that connectivity through MST Bridges and regions, calculated by MSTP to ensure that all LANs in the Bridged Local Area Network are simply and fully connected.
Common Spanning Tree (CST)
The single spanning tree calculated by STP and RSTP, and by MSTP to connect MST Regions.
Customer Premise Equipment (CPE)
A device owned and operated by the customer desiring service from the service provider. The CPE requires an Ethernet port as the connection point to the service providers network. The CPE can be a Layer 2 Ethernet switch, Layer 2/Layer 3 routing switch, Layer 3 router, or a directly connected host or server.
Demux
The process of separating two joined or multiplexed channels.

Dynamic Host Configuration Protocol (DHCP)
DHCP is a protocol that allows network administrators to manage centrally through automation the assignment of IP address to devices in a network.
DiffServ Code point (DCSP)
320747-A
Glossary 273
DiffServ provides an architecture for scalable IP QoS implementations. Flows of traffic are mapped to a class based on the DSCP. The DSCP is then used to select the per hop basis (PHB) treatment of a packet. Thus, queuing, scheduling, and packet dropping are done on a PHB basis depending upon the DSCP.
Downstream node
Refers to the node that the packet enters on the downstream node.
Digital Subscriber Line Access Multiplexer (DSLAM)
A device used to mix and direct voice and digital traffic on a DSL line.
ESU Ring
The term used to refer to a series of ESU devices linked together and connected to the Primary and Secondary ports of a Metro Ethernet Passport 8600 Switch.
ESU Ring Trunk
The MLT connection between two Metro Ethernet Passport 8600 Switches when the Primary and Secondary ports for a ESU ring are on different switches as in the case of dual home rings.
Ethernet Services Module (ESM)
The ESM serves as the demarcation point between the enterprise customer and the service provider and utilizes an Ethernet UNI. See also: ESM 8668 Metro Ethernet Services Module (Metro ESM 8668) on page 273 Optical Metro 1200 Ethernet Services Module (ESM) on page 277 User-to-Network Interface (UNI) on page 281
ESM 8668 Metro Ethernet Services Module (Metro ESM 8668)
Provides service encapsulation for VPN-based services. The ESM supports (Nortel) Metro Ethernet Solutions integration with the Metro Ethernet Passport 8600 Switch backplane fabric.
Internet Group Management Protocol (IGMP)
274 Glossary
IGMP is a multicasting protocol used by IP hosts to report the IP addresses their networks to neighboring networks. The latest version of the protocol is IGMPv3 which allows blocking of unwanted multicast packets by listing IP addresses of desired traffic.
IGMP Proxy
Using IGMP, the ESU can filter multiple same messages coming in for different users on the ESU ring.
IGMP Snoop
Using IGMP, the ESU builds a database of group members by snooping IGMP reports from hosts on each port. Based on the group membership database that it has built, the ESU forwards multicast data only to ports that have participating group members.
Interior Gateway Protocol (IGP)
A term applied to a protocol that is used to increase network leachability and distribute routing information within an autonomous system. Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (IS-IS) are common IGPs.
Internal Spanning Tree (IST)
An internal Spanning Tree that runs in a given MST Region. Within a MST region, multiple Spanning Instances may be configured. Instance 0 within a region is known as the Internal Spanning Tree (IST).
Intra BAN Trunk (IBT)
The term used in CLI to refer to a ESU ring trunk. It is normally a Multiple-Line Trunk (MLT).
IP Multicast (IPMC)
IP multicasting provides services such as the delivery of information to multiple destinations with a single transmission and the solicitation of servers by clients. The source enjoys considerable efficiencies while a significant amount of bandwidth is saved. These services benefit applications such as audio/video conferences, interactive TV, video distribution, surveillance, and distance learning.
IP Unicast
The sending of information between two IP addresses.

320747-A
Glossary 275
MAC Address
The Media Access Control address for a device.

MAN
Metropolitan-area network. Network that spans a metropolitan area. Generally, a MAN spans a larger geographic area than a LAN, but a smaller geographic area than a WAN.
Metro Ethernet Network
A shared Ethernet-based network that supports standard 802.1D traffic. It is transmission-independent, supporting the range of OE transport implementations, including EoF, EoRPR, or even EoWDM.
Metro Ethernet Passport 8600 Switch
The Metro Ethernet Passport 8600 Switch is positioned as a Metro Ethernet Aggregation Switch. The Metro Ethernet Passport 8600 Switch is located at either the providers Central Office or in a building where the provider service encapsulation is performed. Multiple customer and multiple service aggregation are performed by the aggregation Switch.
Metro Ethernet Services Unit (1800 or 1850) (Metro ESU 1800/1850)
The Metro Ethernet Services Unit 1850 (Metro ESU 1850) is positioned as a Metro Ethernet Access device. The ESU can be located in a Single building or in multiple Customer buildings. It can be positioned as Carrier Located Equipment (CLE), which is controlled by the provider network management system.
Multiple-Link Trunk (MLT)
Multiple trunk links between switches are used to provide greater bandwidth or redundancy.
MST Bridge
A bridge capable of supporting the CST, and one or more MSTIs, and of selectively mapping frames classified in any given VLAN to the CST or a given MSTI.
MST Configuration Identifier
276 Glossary
A name for, revision level, and a summary of a given allocation of VLANs to Spanning Trees. Note: Each MST Bridge uses a single MST Configuration Table and Configuration Identifier.
MST Configuration Table
A table you configure that allocates each and every possible VLAN to the Common Spanning Tree or a specific Multiple Spanning Tree Instance.
MST Region
A set of LANs and MST Bridges physically connected through ports on those MST Bridges. Each LANs CIST Designated Bridge is an MST bridge. Each port is either the Designated Port on one of the LANs, or else a non-Designated Port of an MST Bridge that is connected to one of the LANs. The non-Designated Port of an MST Bridge MCID matches exactly the MCID of the Designated Bridge of that LAN. Note: The MCID is the same for all LANs and Ports in the region, and that the set of MST Bridges in the region is interconnected by the LANs.
Multiple Spanning Tree Algorithm and Protocol (MSTP)
The Multiple Spanning Tree Algorithm and Protocol allows multiple configurations of RSTP on the same switch.
Multiple Spanning Tree Bridge Protocol Data Unit (MST BPDU)
The MST BPDU specified.

Multiple Spanning Tree Instance (MSTI)
One of a number of Spanning Trees calculated by MSTP within an MST region The MSTI provides a simply and fully connected active topology for frames classified as belonging to a mapped VLAN. The VLAN is mapped to the MSTI by the MST Configuration Table used by the MST Bridges of that MST Region.
Multipoint-to-multipoint
A type of connectivity also known as any-to-any. VPLS Layer 2 VPNs are examples of a multipoint-to-multipoint solution.
Mux
The combining of two or more communications channels.

Mux tag
320747-A
Glossary 277
The packet tag that identifies the channel.

Next hop
The next hop to which a packet should be sent in order to advance the packet to the destination.
Network-to-Network Interface (NNI)
A switch-to-switch interface that establishes the fabric of a network. Parallel NNI links provide increased bandwidth and redundancy between Lattis Cell switches.
Open Shortest Path First (OSPF) protocol
A link-state protocol in the IP suite that enables routers in the same AS to exchange routing information by means of periodic updates. Each router periodically tests the status of the physical connection to each of its neighbors, and sends this information to its other neighbors. With this information, each router builds a shortest-path tree, with itself as the tree root, to identify the shortest path from itself to each destination, and to build its routing table.
Optical Metro 1200 Ethernet Services Module (ESM)
The Optical Metro 1200 Ethernet Services Module (ESM) is a PE-Edge device that provides a simple Ethernet interface to the customer. The ESM encapsulates customer traffic to securely separate it from other customers data. The ESM is the demarcation point between enterprise customers and the service provider.
Permanent Virtual Circuit (PVC)
A long-term virtual circuit between two devices.

Protocol Data Unit (PDU)
The protocol control unit or tag in a packet.

Protocol Independent Multicast-Sparse Mode (PIM-SM)
PIM-SM supports multicast groups spread out across large areas of a company or the Internet. PIM-SM sends multicast traffic only to routers that have specifically joined a multicast group.
278 Glossary
Protocol Independent Multicast-Source Specific Multicast (PIM-SSM)
PIM-SSM optimizes PIM-SM by simplifying the many-to-many model. Since most multicast applications distribute content to a group in one direction, SSM uses a one-to-many model that only uses a subset of the PIM-SM features. This model is more efficient and puts less of a load on multicast routing devices.
Point-to-point (P2P)
A type of connectivity also known as one-to-one. Connectivity here is through the data center interconnect, or virtual locations. In this scenario, the network provides a virtual leased line across a shared infrastructure.
Point-to-multipoint (P2MP)
A type of connectivity also known as one-to-many. In this scenario, multiple locations each connect to a central point. These locations can be branch offices connecting to a data center, or may be schools receiving an interactive video broadcast for remote distance learning. Switching here is based on a 802.1Q VLAN identifier.
PPPoE
PPP over Ethernet is a protocol used to allow multiple network hosts to communicate with each other. Each host has a specific stack tag.
Preside Service Provisioning (PSP)
A PSP tracks the availability of network resources required to provision services, or to diagnose troubles with provisioned services. In addition, PSPs also provide an automated work order system and integrated database to maintain accurate relationships between customers.
Prism
The IQ2200 CPU chip is the test chip.

Quality of Service (QoS)
QoS and CoS are terms that are often used interchangeably. QoS is a contract to provide transmission performance guarantees that can be measured objectively. QoS applies end-to-end.
Rapid Spanning Tree Algorithm and Protocol (RSTP)
320747-A
Glossary 279
The Rapid Spanning Tree Algorithm and Protocol which allows faster recovery of a network than STP by not flooding the network after a topology change.
Rapid Spanning Tree Bridge Protocol Data Unit (RST BPDU)
The RST BPDU specified.

Registration, Admission and Status (RAS)
The H.225 RAS conducts registration, admission control, bandwidth changes, status, and disengagement procedures on packet-based VoIP circuits between endpoints and gatekeepers.
Resilient Packet Ring (RPR)
The RPR is a protocol to ensure the integrity of the packet between various protocols. It is useful for supporting the ethernet ring topology and fast recovery from fiber cuts and broken links. It also solves problems in priority and congestion control.
Ring Resiliency Protocol (RRP)
A protocol used on an ESU ring to detect breaks in the ring.

Ring Topology Protocol (RTP)
A protocol used by the Metro Ethernet Passport 8668 to manage the ESUs on an ESU ring.
Routing policy
Any form of routing that is influenced by factors other than the default algorithmically best route, such as the shortest or quickest path.
Single Spanning Tree
A single Bridge Group domain consisting of one or more VLANs.

Single Spanning Tree (SST) Bridge
A Bridge capable of supporting only a single spanning tree, the CST. The single spanning tree may be supported by the Spanning Tree Algorithm and Protocol (STP) defined in IEEE Std 802.1D, 1998 Edition, or by the Rapid Spanning Tree Algorithm and Protocol (RSTP), defined in IEEE Std 802.1w-2001.
Spanning Tree
280 Glossary
A simply and fully connected active topology formed from the arbitrary physical topology of connected Bridged Local Area Network components. The spanning tree is formed by relaying frames through selected bridge ports and not through others. The protocol parameters and states used and exchanged to facilitate the calculation of that active topology and to control the bridge relay function.
Spanning Tree Algorithm and Protocol (STP)
The Spanning Tree Algorithm and Protocol described in Clause 8 of IEEE Std 802.1D, 1998 Edition.
Spanning Tree Bridge Protocol Data Unit (ST BPDU)
A Bridge Protocol Data Unit specified for use by the Spanning Tree Algorithm and Protocol, that is, a Configuration or Topology Change Notification BPDU as described in Clause 9 of IEEE Std 802.1D, 1998 Edition.
Spanning Tree Group (STG)
The use of the spanning tree protocol over a group of VLANs to enhance redundancy.
Synchronous Digital Hierarchy (SDH)
An international standard to for digital transmission. SDH allows for different types of service and speeds in the same frame such as voice, data, or video.
Tag
The layer header information for a packet.

Transparent Domain Connectivity (TDC)
TD Connectivity refers to one suite of tests used to test end-to-end pathways for OEL2 or TLS based packets. The term TD Connectivity is used with OPTera Metro 3500 Multi-services Platform Release 10.1 documents and tests.
Transparent Domain Continuity (TDC)
TDC refers to one suite of tests used to test end-to-end pathways for OEL2 or TLS based packets. The term TDC is used with the Metro Passport 8600 Ethernet switch.
Traffic Engineering (TE)
320747-A
Glossary 281
The process of mapping traffic demand onto a network in order to enhance its performance.
Transparent Domain Identifier (TDI)
A User-to-Network Interface (UNI) port configured as transparent service type assigns all traffic to its associated transparent domain using the TDI. (See also User-to-Network Interface (UNI)).
Transparent LAN Service (TLS)
TLS is the component of the Nortel OE solution that allows a group of customer sites to appear as one single LAN, regardless of their geographic location. See also Virtual Private LAN Services (VPLS) on page 282.
User-to-Network Interface (UNI)
A generic term used to indicate interfaces to both public or private networks. In the Nortel OE L2 VPN solution, an Ethernet UNI separates the customer environment from the service provider environment, clearly delineating the point of responsibility between the service providers network and the attached customer network.
Virtual Link Aggregation Control Protocol
Virtual LACP is an extension to LACP that detects end-to-end failure.

Virtual local area network (VLAN)
A logical group of user end-stations, servers, and other network devices that appear to be on the same LAN, regardless of their physical location.
Virtual Private Network (VPN)
A wide area communications network provided by a common carrier that offers the appearance, functionality, and usefulness of a dedicated private network. However, a VPN actually shares its backbone trunks among all customers, as in a public network. A VPN allows a private network to be configured within a public network.
Virtual Private Network Identifier (VPN-ID)
A globally significant VPN identifier.
282 Glossary
Virtual Private LAN Services (VPLS)
A VPN service that emulates an Ethernet LAN segment across a provider domain.
320747-A
283
Index
A
Access Network Topology PIM-SSM on the ESU Ring 107 Access port 271 Address Resolution Protocol (ARP) 271 Asynchronous Transfer Mode (ATM) 271 ATM module scalability 44 ATM PVC Endpoint rules and limitations 41 Endpoints 41 Overview 41 ATM throughput performance 45 Configuration guidelines 173 configuring Ban services with Device Manager 181 Connection Types 68 Any-to-any overview 73 Point-to-multipoint overview 71 Point-to-point overview 68 conventions, text 21 Customer IP VLAN 127 Customer Premise Equipment (CPE) 272
D
Demux 272 Designated forwarding port 80 DiffServ Code point (DCSP) 272 Digital Subscriber Line Access Multiplexer (DSLAM) 273 Downstream node 273 Dual-home ring Configure in JDM 202 Considerations 56 Overview 53 Dynamic Host Configuration Protocol (DHCP) 272
B
Binding 271 Boundary port 271 BPDU forwarding 135 Bridge Protocol Data Unit (BPDU) 271
C
Carrier Located Equipment (CLE) 271 Circuitless IP (CLIP) 272 Class of Service (CoS) 272 Class of Service Profile Configuring in JDM 212 Class of service profile Configuring in JDM 212 Command Line Interface (CLI) 272 Common and Internal Spanning Tree (CIST) 272 Common Spanning Tree (CST) 272
E
Edge device management Configuration rules 151 Endpoints 33 Configuration rules 135 BPDU forwarding 135
284 Index Default COS profile 136 Default VLAN for TLS-switched UNI 136 Destination MAC table size 138 Hub and spoke 137 Local switching 137 Creating a customer endpoint 34 Prerequisites to creating a customer endpoint 34 ESM 273 ESM 8668 Enhanced OESS capabilities 28 ESU-ring port 30 ESU-standalone port 30 Local port 31 Metro Ethernet Services Module Overview 30 ESU ISMP Snoop 104 ESU as an IGMP Proxy/Snoop device 103 ESU Ring 198, 200, 273 Configuring in JDM 194 ESU Ring port states Displaying in JDM 208 ESU Ring record Displaying in JDM 207 ESU Ring Topology PIM-SM 104 ESU Ring Trunk 273 ESU standalone Configuring in JDM 209 Ethernet UNI 59 Overview 31 QinQ(1) UNI 66 QinQ(2) UNI 67 TLS-switched UNI 61 Many-to-one 65 Q-tag classification 62 VLAN remapping 64 TLS-transparent UNI 60
I
IGMP ESU as a Proxy/Snoop device 103 ESU as a Snoop 104 Fast-leave 104 Host leave message 103 Host Membership Reports 102 Queries 102 IGMP Proxy 102, 274 IGMP Snoop 274 Interior Gateway Protocol (IGP) 274 Internal Spanning Tree (IST) 274 Internet Group Management Protocol (IGMP) 273 Intra BAN Trunk (IBT) 274 IP address spoofing 100, 173 IP Multicast Overview 88 IP Multicast (IPMC) 274 IP Unicast 274 IP VLAN Overview 88
L
Legacy access port and services Configuration rules 147 ESM server port 147 MAC aging 150 Setup and rules 148 Spanning tree 149
M
MAC Address 275 MAN 275 Managing the Switch Configuration rules 150 Mapped NNI VLAN Configuration rules 118 Switch address range 122
320747-A
Index 285 Metro ESM 8668 Displaying current information in JDM 245 Displaying daily ESM port statistics for all ports in JDM 250 Displaying ESM port statistics for the last 15 minutes in JDM 248 Displaying ESM port statistics for the last hour in JDM 249 Displaying ESM port statistics in JDM 247 Displaying server-port statistics in JDM 243 Metro ESU 1850 Port Rules 151 IP management 152 Ring port connections 152 Valid UNI port numbers 152 Metro Ethernet Network 275 Metro Ethernet Passport 8600 repeater feature Configuring in JDM 252 Metro Ethernet Passport 8600 Switch 275 Access connection types 49 Direct-access mode connection types 49 Ring-access node connection-type 52 Local-access 49 Local-server 51 Repeater function 57 Metro Ethernet Services Unit 1850 (Metro ESU 1850) 275 Metro Ethernet Solutions Overview 26 MST Bridge 275 MST Configuration Identifier 275 MST Configuration Table 276 MST Region 276 MSTP Advantages 83 Overview 75 Multiple Spanning Tree Algorithm and Protocol (MSTP) 276 Multiple Spanning Tree Bridge Protocol Data Unit (MST BPDU) 276 Multiple Spanning Tree Instance (MSTI) 276 Multiple-Link Trunk (MLT) 275 Multipoint-to-multipoint 276 Mux 276 Mux tag 276
N
Network-to-Network Interface (NNI) 277 Next hop 277 NNI ports Configuration rules 139
O
Open Shortest Path First (OSPF) protocol 277 OPTera Metro 1200 Ethernet Services Module (ESM) 277 Optical Ethernet Layer 2 Multicast and broadcast traffic for any-to-any connection types Overview 40 Overview 37 Packet destination 39 TLS Frame Check Sequence Overview 37 TLS Header Overview 39 TLS IP header Overview 38 TLS Multicast address for TDI Overview 38
P
per 179 Permanent Virtual Circuit (PVC) 277 Point-to-multipoint (P2MP) 278 point-to-point (P2P) 278 Point-to-point UNI Configuration rules 144 Configure a remote UNI ID 145 Defining a remote MAC address for a remote UNI 146 Remote MAC address rules 145 Policing Metro Ethernet Passport 8600 Switch 163
286 Index Configurable token buckets 166 Enhancements 164 Functionality 165 Rules 168 PPPoE 278 Preside Service Provisioning (PSP) 278 Prism 278 Protocol Data Unit (PDU) 277 Protocol Independent Multicast-Source Specific Multicast (PIM-SSM) 278 Protocol Independent Multicast-Sparse Mode (PIM-SM) 277 publications hard copy 23 Routing policy 279 RRP Statistics 198 RSTP Advantages 82 Overview 75 Port roles 77 Alternate blocking port 80 Differences in port roles 78 Edge Port 79 Master Port 78 Negotiation Process 81 Rapid convergent 81 Root forwarding port 79 RSTP/MSTP Interoperability with legacy STP 76 Path cost values 79 Regents 81
Q
QoS 45 General Rules 153 Mapping rules Metro ESU 1850 161 Metro ESU 1850 egress queueing for untagged packets 162 Metro Ethernet Passport 8600 Switch 153 802.1q p-bit override option 155 Mapping 157 Services configuration 153 TLS-Priority Override 156 Quality of Service (QoS) 278
S
Service Provider VPN VLAN overview 36 Single Spanning Tree 279 Single Spanning Tree (SST) Bridge 279 Spanning Tree 279 Spanning Tree Algorithm and Protocol (STP) 280 Spanning Tree Bridge Protocol Data Unit (ST BPDU) 280 Spanning Tree Group (STG) 280 Static UNI Configuration rules 140 Any-to-any destination tables 141 Destination-UNI 142 Predefining 140 Ring access ports 144 UNI-MAC 141 User-MAC 143 Synchronous Digital Hierarchy 280
R
Rapid Spanning Tree Algorithm and Protocol (RSTP) 278 Rapid Spanning Tree Bridge Protocol Data Unit (RST BPDU) 279 RDP statistics 200 Registration, Admission and Status (RAS) 279 Resilient Packet Ring 279 Ring Resiliency Protocol (RRP) 279 Ring Topology Protocol (RTP) 279 320747-A
T
Tag 280
Index 287 TD Continuity Configuring a test in JDM 191 Diagnosing problems 175 Displaying test in JDM 185 Flooding option 177 Limits and Rules 178 Overview 74 Priority Option 177 Round-trip time option 177 Running a current test in JDM 184 Troubleshooting 174 TDI Configuration rules 132 Mux mode 133 Configuring a general TDI 225 Configuring a TDs User MAC address in JDM 241 Destination UNI Configuring in JDM 232 Displaying TDI endpoint statistics in JDM 239 Displaying TDI statistics in JDM 225, 227 Many-to-one 33 One-to-one 33 Overview 32 TDI endpoint Configuring in JDM 233 technical publications 23 text conventions 21 Traffic Engineering (TE) 280 Transparent Domain Connectivity (TDC) 280 Transparent Domain Continuity (TDC) 280 Transparent Domain Identifier (TDI) 281 Transparent LAN Service (TLS) 281 Triple Play Access Network Topology (Local) 92 Customer Premise Topology (ESU Ring) 91 Existing Metro Ethernet Passport 8600 for IP Multicast 115 IP Aging 114 IP Multicast Processing 115 IP Subnet and VLAN Access Network Topology 100 IP-Based Services in the Access Network Topology 112 Access CO and IP Router 112 Address Learning 113 ARP Broadcast 113 IGMP Access Control List 114 QoS Support 113 IP-Based Services in the ESU Ring Topology 108 Access CO as an IP Router 108 ARP Broadcast in the ESU Ring 111 DHCP and BootP 112 ESU in Mux/Demux Mode 110 IP Address Learning on the access CO 111 Overview 88 Policing 114 Statistics 114 Tagged and Untagged Traffic 98
U
UNI Configuration Rules 122 Configuration rules 121 Customer IP VLAN 127 QinQ 123 Customer IP VLAN Configuring a services provider VLAN in JDM 256 Configuring a VLAN TLS-IPMC in JDM 267 Configuring in JDM 255, 260 UNI interface Configuring in JDM 218 UNI IP Statistics Clearing using JDM 264 Showing in JDM 264 UNI MAC address Configuring in JDM 222 User-to-network interface (UNI) 281
288 Index
V
Virtual local area network (VLAN) 281 Virtual Private LAN Services (VPLS) 282 Virtual Private Network (VPN) 281 Virtual Private Network Identifier (VPN-ID) 281 VLACP 57 considerations 179 VLACP configuring in JDM 268
320747-A
289
290 Index
320747-A

320747-A 00 PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

320747-A 00 PDF

Uploaded by

Copyright:

Available Formats

Part No.

320747-A September 2005 600 Technology Park Drive Billerica, MA 01821-4130

Copyright Nortel Networks Limited 2005. All rights reserved.

Nortel Inc. software license agreement

Chapter 2 Triple Play Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Chapter 3 Configuration considerations and limitations . . . . . . . . . . . . . . . . . . . . . 117

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

Before you begin

plain Courier text

Hard-copy technical manuals

How to get Help

Getting Help from the Nortel Web site

Getting Help over the phone from a Nortel Solutions Center

Getting Help from a specialist by using an Express Routing Code

Getting Help through a Nortel distributor or reseller

This chapter includes the following topics:

(Nortel) Metro Ethernet Solutions

(Nortel) Metro Ethernet Solutions overview

BayStack 425 switches

Service provider unmanaged devices (CPE) generic L2/L3 switches

Metro Ethernet Services Unit 1800 (Metro ESU 1800)

Customer separation End-to-end QoS

Policing Scalability Easy-to-administer Ethernet infrastructure

Enhanced Ring Resiliency Protocol

ESM 8668 Metro Ethernet Services Module

ESU ring port

ESU standalone port

ESM local (TLS) port

ESM server port

Prerequisites to creating a customer endpoint, next Creating a customer endpoint on page 34

Prerequisites to creating a customer endpoint

Creating a customer endpoint

Enable the Ethernet UNI ID.

SP VPN VLAN overview

Service provider Ethernet tunnel (VLANs 10, 20)

Customer Qtags V4, V5

Metro Ethernet Services Unit 1800 (Metro ESU 1800)

Optical Ethernet Layer 2 overview

TLS Frame Check Sequence

Data customer packet

TLS multicast address for TDI

Multicast and broadcast traffic for any-to-any connection types

ATM PVC endpoint rules and limitations

42 Concepts Figure 6 Locally switching two ATM PVCs

ATM UNI ID B A2AD A2AE PVC ID PVC ID ELAN ELAN

Provisioned VLAN ID 400

Switch Fabric TDI 100 end-point

Concepts 43 Figure 7 Two PVCs located on different ELANs

TDI 100 end-point A2AD A2AE PVC ID PVC ID ELAN ELAN

Provisioned VLAN/ELAN ID 400

TDI 200 ATM UNI ID B Switch Fabric

TDI 200 ATM UNI ID D

Figure 8 Supporting multiple PVCs on the same ATM port

Provisioned VLAN/ELAN ID 200

TDI 100 end-point PVC ID Hub E PVC ID ELAN ELAN

Provisioned VLAN/ELAN ID 400

TDI 200 ATM UNI ID B Switch Fabric

TDI 200 ATM UNI ID D

ATM module scalability

ATM throughput performance

(Nortel) Metro Ethernet QoS Solution

Concepts 47 Figure 9 Optical Ethernet QoS solution