DCN

NTR710AM
Nortel Networks
Optical Networks
Data Communications Network Planning Guide
Standard Issue 3 May 2002
Whats inside...
Data communications network overview Data communications paths OSI data communications Data communications network planning Data communications network applications Trouble clearing Appendix A: Physical interfaces Appendix B: Area address administration Appendix C: Data communications tools Appendix D: Software release baseline
*A0804565*
Copyright 20012002 Nortel Networks, All Rights Reserved

The information contained herein is the property of Nortel Networks and is strictly confidential. Except as expressly authorized in writing by Nortel Networks, the holder shall keep all information contained herein confidential, shall disclose the information only to its employees with a need to know, and shall protect the information, in whole or in part, from disclosure and dissemination to third parties with the same degree of care it uses to protect its own confidential information, but with no less than reasonable care. Except as expressly authorized in writing by Nortel Networks, the holder is granted no rights to use the information contained herein. Nortel Networks, the Nortel Networks logo, the Globemark, TransportNode, OPTera and Preside are trademarks of Nortel Networks. UNIX is a trademark of X/Open Company, Ltd. Telecordia is a trademark of Telecordia Technologies, Inc.
Printed in Canada and in the United Kingdom
iii
Publication history
May 2002 Issue 3
This document was updated to include data communications information for OPTera Connect DX Release 4.0 and OPTera Long Haul 1600 Release 7.0. A new section was added to introduce the planning considerations for operations, administration and maintenance (OAM) head-ending of metro network elements with OPTera Connect DX Release 4 network elements. Two sections were also added to describe the OAM TL1 Gateway and operations controller (OPC) Transport Bridge applications. March 2001 Issue 2.
Data Communications Network Planning Guide NTR710AM
Issue 3 Standard May 2002
iv Publication history
Optical Networks
NTR710AM
Issue 3 Standard May 2002
Contents
About this document Data communications network overview
Chapter overview 1-1 Data communications network (DCN) 1-1 Span of control 1-1 OAM&P 1-2 Data communication transmission 1-4 Preside-to-OPC communication 1-4 Preside-to-MOA/NP communication 1-5 OPC-to-network element communication 1-6 NP-to-network element communication 1-6 Network element-to-network element communication 1-6
0
ix 1-1
Data communications paths

Chapter overview 2-1 Internal data communications paths 2-2 External data communications paths 2-4 SONET data communication channels 2-4 Section DCC (SDCC) 2-5 Line DCC (LDCC) 2-5 Optical service channel 2-5 LAN Link 2-8 CNet rules 2-12 WAN Link 2-13 Path selection 2-14
2-1
OSI data communications

Chapter overview 3-1 OSI reference model 3-1 OSI network organization 3-3 Routing roles 3-4 Level 1 routing 3-5 Level 2 routing 3-5 OSI network addressing 3-6 NSAP structure 3-8 OSI basic routing algorithm 3-12 Update process 3-12
3-1
Data Communications Network Planning Guide NTR710AM Issue 3 Standard May 2002
vi Contents Decision process 3-13 Forwarding process 3-15 Level 1 areas and area addresses 3-15 Manual Area Address (MAA) sets 3-17 Computed Area Address (CAA) sets 3-18 OSI data link layer protocols 3-19 Link Access Procedure on the D-Channel Protocol 3-19 Logical Link Control protocol 3-21 OSI network layer protocols 3-22 Connectionless network service protocol 3-22 End system-to-Intermediate system routing exchange protocol 3-23 Intermediate system-to-intermediate system intra-domain routing exchange protocol 3-26 TID Address Resolution Protocol 3-28 Network Name Service (NNS) 3-32
Data communications network planning

Chapter overview 4-1 Span of control considerations 4-1 Level 1/Level 2 routing considerations 4-2 Maximum of 150 nodes in a Level 1 area 4-2 Maximum of 150 nodes in a Level 2 area 4-3 Contiguous path between Level 2 routers 4-3 Unique network element IDs or Target IDs across all areas 4-8 Network elements that can be provisioned as Level 2 routers 4-8 Nortel Networks default address 4-8 S/DMS TransportNode OC-48 Shelf Processor dependencies 4-10 Data communication ports requirements 4-10 Multivendors interoperability requirements 4-11 Level 2 routing checklist 4-11 Splitting a Level 1 area 4-12 Guidelines for splitting areas 4-15 Combining two Level 1 areas 4-16 OAM head-ending of subtending metro network elements 4-16 TL1 Gateway engineering rules and restrictions 4-18 OPC Transport Bridge engineering rules and restrictions 4-19 OPTera Connect DX Release 4.0 datacomm usage performance rules 4-20 OPTera Connect DX Release 4.0 datacomm usage planning guidelines and recommendations 4-24
4-1
Data communications network applications

Chapter overview 5-1 OAM&P traffic on shared DCC paths 5-1 Guidelines for OAM&P traffic 5-5 Establishing communications between DCC island 5-5 Linear system to bridge two areas 5-5 Network with Amplifiers or Dense Regenerators 5-9 Stacked ring 5-10 Back-to-back ADM chains 5-11 Nested rings 5-12
5-1
Optical Networks NTR710AM Issue 3 Standard May 2002
Contents vii Unified SOC and OPTera Connect DX 4-Fiber ADM network element 5-15 OAM TL1 Gateway 5-16 OPC Transport bridge 5-18 Supporting Push Button Equalization 5-19 Point-to-point system with terminating equipment (no regeneration) 5-21 Point-to-point system with terminating equipment (with regeneration) 5-22 Point-to-Point system with transparent Wavelength Translators 5-24 Point-to-Point system with transparent Wavelength Translators and multiple Level 1 areas interconnected by switches 5-25 Overlay ring application without regeneration 5-27 Overlay ring application with regeneration 5-29 PBE communication process 5-31 Multi-vendor interoperability 5-33 TARP support on the OPC for mixed-vendor networks 5-34 TARP support on the S/DMS TransportNode OC-48 network element for mixed-vendor networks 5-34
Trouble clearing
Chapter overview 6-1
6-1
List of procedures 6-1 Trouble clearing within the Level 1 area 6-2 6-2 Trouble clearing across Level 1 areas 6-7
Appendix A: Physical interfaces
7-1
Operations controller (OPC) 7-1 OPTera Metro 3000 network element 7-2 S/DMS TransportNode OC-12 TBM network element 7-2 S/DMS TransportNode OC-48 network element 7-3 S/DMS TransportNode OC-48 Lite Multiplexer network element 7-3 S/DMS TransportNode OC-192 network element and OPTera Long Haul 1600 7-4 OPTera Connect DX 7-5 Access Node 7-5
Appendix B: Area address administration

Assigning RD and AREA Assigning RD and AREA Assigning RD and AREA Assigning RD and AREA
8-1
according to geographic code 8-3 according to administrative groups or departments 8-3 according to network routes or network names 8-4 according to Preside regions 8-5
Appendix C: Data communications tools

Listnodes 9-1 Routes/Rib tool 9-2 Level 2 routers 9-3 nnsmon/nnsfmon 9-4 nnsmon 9-5 nnsfmon 9-5 tstatc 9-6 Remote login (rlogin, selectNE) 9-6 Preside Site Manager reach-through 9-7 PING 9-7
9-1
viii Contents
Appendix D: Software release baseline Index
10-1 11-1
ix
About this document
This document describes the optical network data communications in the Nortel Networks Synchronous Optical Network (SONET) access, Transport and optical network configurations. Described herein are the components of a data communications network (DCN), specifically: operations, administration, maintenance and provisioning (OAM&P) management, data communication paths, Open Systems Interconnect (OSI) data communications, DCN planning and applications. This planning guide covers the following product: OPTera Connect DX OPTera Long Haul 1600 S/DMS TransportNode OC-192 S/DMS TransportNode OC-48 S/DMS TransportNode OC-48 Lite Multiplexer S/DMS TransportNode OC-12 TBM OPTera Metro 3000 Note: OPTera Metro 5200 is not covered by this Planning Guide since its data communication is TCP/IP based and not OSI based. For more information, refer to the OPTera Metro 5200 Application and Planning Guide, NTOH67AC.
Audience
The following members of your company are the intended audience of this guide: strategic and current network planners provisioners network administrators
x About this document
References
This document refers to the following Nortel Networks technical publications (NTP): OPTera Metro 5200 Application and Planning Guide, NTOH67AC OPTera Long Haul 1600 Provisioning and Operations Procedures, 323-1801-310 OPTera Connect DX Provisioning and Operations Procedures, 323-1521-310 1600G Amplifier SLAT and Upgrade Procedures, 323-1801-226 1600G Amplifier Software Feature Guide, NTY317DG MOR Plus SLAT and Upgrade Procedures, 323-1801-225 This document refers to the following supporting documentation: ISO/IEC 8348, Information technology - Open systems interconnectionNetwork Service Definition, amendment 1, December 1998 ISO /IEC 8473-1, Information technology - Protocol for providing the connectionless-mode network service: Protocol specification, second edition November 1998 ISO 9542, Information processing systems - Telecommunications and information exchange between systems - End system to Intermediate System routing exchange protocol for use in conjunction with the Protocol for providing the connectionless-mode network service (ISO 8473), amendment 1, September 1999 ISO/IEC 10589, Information technology - Telecommunications and information exchange between systems - Intermediate system to Intermediate system intra-domain routing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473), amendment 2, September 1999 ISO/IEC 8802-2, Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements, Part 2 Logical Link Control (Ref. ANSI/IEEE Std. 802.2, 1998), October 2000 ITU-T: Recommendation Q.921 ISDN user-network interface- Data link layer specification, September 97 Telcordia Technologies GR-253-CORE SONET Transport Systems: Common Generic Criteria, Issue 3, September 2000
1-1
Data communications network overview

Chapter overview
1-
This chapter gives you an overview of the data communications network (DCN). Data communications network paths provide the ability to interconnect between network elements and subtending systems in a network. DCN paths transmit operations, administration, maintenance, and provisioning (OAM&P) information. This information is presented in the following sections: Data communications network (DCN) Data communication transmission
Data communications network (DCN)

A DCN consist of the following components: Span of control OAM&P Span of control A SONET network span of control (SOC) refers to collections of network elements managed by a network controller such as an operations controller (OPC) or network processor (NP). An SOC includes the network elements that a primary OPC, an NP or OPC pair can directly control or monitor. Normally, a pair of OPCs monitors an SOC. The primary OPC controls the network. The backup OPC takes over control if the primary OPC fails.
1-2 Data communications network overview
OAM&P Operations and management of Nortel Networks S/DMS TransportNode OC-192/OPTera Connect DX, OPTera Long Haul 1600, S/DMS TransportNode OC-48, S/DMS TransportNode OC-12 TBM, Access Node and OPTera Metro 3000 follows the Telecommunications Management Network (TMN) principles. A seven-layer Open Systems Interconnect (OSI) stack, as described by GR-253-CORE, is supported on each network element along with the element managers (operations controller and network processor) to allow each node to communicate with one another. The management hierarchy is illustrated in Figure 1-1. Table 1-1 lists the abbreviations and full product names used in Figure 1-1. The data communication network is only used for carrying OAM&P management traffic and is independent of the payload network. The OAM&P traffic carried on the data communication network includes the following: Common Management Information Service Element (CMISE) traffic between the OPC and the network elements within the OPC SOC. CMISE as defined by ISO 9595 is a protocol used to carry OAM&P such as: alarms events provisioning file transfer (FTAM, FTP) data synchronization between primary and backup operations controllers These messages are normally initiated via Preside AP, OPC user interface, network element user interface (NE UI) and Transaction Language 1 (TL1). messages received by the OPC from an Operations Support System (OSS) or via External Data Representation (XDR). XDR is a standard for the description and encoding of data. The XDR protocol is useful for transferring data between different types of systems. data synchronization between primary and backup operations controllers
Data communications network overview 1-3 Figure 1-1 Management hierarchy

OTP2073p
Preside AP
Network management layer
MOA Element management layer
NP
Partitioned OPC
OPC
OPC
OPC
OC-48 Lite
OPTera Metro 3000
OC-192/ OPTera Connect DX/ OPTera Long Haul 1600
OC-48
OC-12 TBM
Access Node
Network element layer
Legend AP MOA NP OPC = Applications Platform = managed object agent = network processor = operations controller = OSI over CNET = OSI over Ethernet = TCP/IP over Ethernet
Table 1-1 The full product names and abbreviations used in Figure 1-1 Product name S/DMS TransportNode OC-192 S/DMS TransportNode OC-48 Abbreviation OC-192 OC-48
S/DMS TransportNode OC-48 Lite Multiplexer OC-48 Lite S/DMS TransportNode OC-12 TBM OC-12 TBM
The data communications channel (DCC) paths within an area are a shared resource. Messages from network elements outside the SOC are given equal priority to messages from network elements within the SOC. SOCs that overlap result in traffic from different SOCs sharing the same DCC resource.
Data communication transmission

The management of different types of network element can be done through following connections: Preside-to-OPC communication Preside-to-MOA/NP communication OPC-to-network element communication NP-to-network element communication Network element-to-network element communication Preside-to-OPC communication Preside (formerly known as Integrated Network Manager) can communicate with multiple SOCs by connecting to an OPC in each SOC. Figure 1-2 shows a configuration in which Preside communicates with each SOC through an OPC.
Data communications network overview 1-5 Figure 1-2 Preside AP connections to multiple SOCs
OTP2284p
Preside AP
Printer External LAN
WAN
OPC 1
OPC 2
OPC 3
OPC 4
NE 1
NE 34
NE 35
NE 68
NE 69
NE 102
NE 103
NE 136
Maintenance interface
Span of control 1
Span of control 2
Span of control 3
Span of control 4
Note: Only the primary OPCs are shown.

Legend LAN = Local Area Network NE = Network Element OPC = OPerations Controller
Preside-to-MOA/NP communication Managed Object Agents (MOAs) are software applications that enable you to manage different types of network elements using Nortel Networks Preside. OAM&P traffic between an MOA/NP and its SOC is made up of the following: fault management remote network element login (TL1 command line UI or OPTera Metro 3000 Site Manager) to individual OPTera Metro 3000 network elements nodal connection management performance monitoring remote inventory and shelf level graphics
centralized software management network element Backup and Restore GUI
OPC-to-network element communication OAM&P traffic flows between an OPC and the network elements within the OPC SOC. OAM&P traffic between an OPC and its SOC is made up of the following: event reporting from network elements to OPC (alarms and logs) management and provisioning messaging from OPC to network element database backup from network element to OPC database restore from OPC to network element software download from OPC to network element file transfer from OPC to network element remote login from OPC to network element and vice versa This traffic can be initiated by a network management controller such as Preside or an OSS, or can be the result of scheduled operations. NP-to-network element communication The network processor (NP) circuit pack allows surveillance of all network elements in the NPs span of control. It also acts as an interface between S/DMS TransportNode Preside, OPTera Metro 3000 TL1 Managed Object Agent (MOA), TL1 based operations support systems (OSS), personal computers (PCs) that run OPTera Metro 3000 Site Manager and the OPTera Metro 3000 shelf for electronic software delivery (ESD) and remote monitoring. Network element-to-network element communication OAM&P traffic can also be transmitted between network elements. Some examples of network element to network element communication are: remote login from network element to network element management and provisioning messaging from network element to network element (such as selectNE command on S/DMS TransportNode OC-12/S/DMS TransportNode OC-48).
2-1
Data communications paths

Chapter overview
2-
The purpose of this chapter is to illustrate data communications paths as they apply to optical networks. The data communication paths of the data communications network (DCN) are used for carrying operation, administration, maintenance and provisioning (OAM&P) traffic and it is separate of the payload network. The advent of the optical amplifier and dense wavelength division multiplexing (DWDM) technology has not only increased the size of the available bandwidth pipe, but also the data network communications domain. Proper design of the data communications paths is necessary to ensure that OAM&P data communications integrity is not compromised when deploying DWDM network solutions. Unless otherwise specified, the examples in this section refer to S/DMS TransportNode OC-192/OPTera Connect DX and OPTera Long Haul 1600. There are two types of data communication paths: Internal data communications paths External data communications paths
2-2 Data communications paths
Internal data communications paths

Internal data communication paths to the network element exist between the network element controller and other network element circuit packs. The shelf controller is the central processor for the S/DMS TransportNode OC-192/OPTera Connect DX/OPTera Long Haul network elements. The network element controller handles all internal and external communications. It must communicate internally with all the other circuit packs. The network element controller circuit pack implements layer 3 to layer 7 of the Open System Interconnection (OSI) protocol application. The shelf controller communicates with other circuit packs through the maintenace interface (MI) or the message exchange (MX) circuit packs and the internal buses Ethernet and GraceLAN (see Figure 2-1). GraceLAN is used for shelf controller (SC) and transport control subsystem (TCS) communications. TCS-based circuit packs are optical circuit packs (high-speed tributaries, amplifiers), external synchronization interface (ESI) and Orderwire circuit pack. Ethernet bus is used for the SC-operations controller (OPC) communication.
Data communications paths 2-3 Figure 2-1 Network elements internal data communication paths
OTP2120p.eps
To Ethernet LAN, other NE, or OPC
To Ethernet LAN, other NE, or OPC
SCSI bus
POPC
Eternet bus Eternet bus
MI
Eternet bus Parallel bus (PEZ) Serial bus (S. PEZ)
PT
Serial bus
POPI
SC
Serial bus (S. PEZ)
GraceLAN GraceLAN GraceLAN
TCS
MX
TCS
GraceLAN
TCS Legend MI MX NE OPC POPC POPI POPS PT TCS = maintenance interface = message exchange = network element = operations controller = partitioned OPC controller = partitioned OPC interface = partitioned OPC storage = parallel telemetry = transport control subsystem
External data communications paths

External data communications paths to the network element exist between different nodes. External paths can be through: Optical link SONET overhead and optical service channel (OSC) LAN link Ethernet and CNet WAN link over circuit and packet switched network SONET data communication channels As specified by Telecordia (formerly known as Bellcore) GR-253, SONET network elements exchange SONET frames. In addition to a payload area to carry traffic, SONET frames contain a transport overhead divided into a line and a section overhead. The SONET overhead bytes establish the data communications channels (DCCs) between network elements (see Figure 2-2). DCCs are dedicated to carry OAM&P information between connected network elements.
Figure 2-2 SONET overhead data communication channels
OTP2197p
Framing A1 Section Overhead BIP-8 B1 Data Com D1 Pointer H1 BIP-8 B2 Line Overhead Data Com D4 Data Com D7 Data Com D10 Sync S1/Z1
Framing A2 Orderwire E1 Data Com D2 Pointer H2 APS K1 Data Com D5 Data Com D8 Data Com D11 FEBE M0M1/Z2
Section Trace J0 User F1 Data Com D3 Pointer Action H3 APS K2 Data Com D6 Data Com D9 Data Com D12 Orderwire E2
Section DCC
Line DCC
Data communications paths 2-5
Section DCC (SDCC) Three bytes in the section overhead (D1 through D3) are dedicated for data communications (see Figure 2-2). SDCC has a rate of 192 kbit/s and is used by section terminating equipment (STE) such as Terminal, Regenerator or add/drop multiplexer (ADM). STEs can exchange the OAM&P information through SDCCs. The DCCs at a regenerator site are bidirectional. The circuit pack groups at the regenerator site establish the SDCCs in both eastbound and westbound directions. The SONET overhead data that heads in an eastbound direction is received on the eastbound circuit pack. This SONET overhead is then transmitted on the westbound circuit pack. The westbound overhead data is received on the westbound circuit pack, and transmitted on the eastbound circuit pack. Line DCC (LDCC) Nine bytes in the line overhead marked D4 through D12 form the line data communications channel (LDCC). LDCC has rate of 576 kbit/s (3 times the capacity of SDCC) and is available between the line terminating equipment (LTE)- Terminal or ADM. LTEs can exchange the OAM&P information through LDCCs. LTEs are at the same time STEs, but not vice versa. Optical service channel Optical service channel (OSC) is an out-of-band channel on the DWDM optical link that carries various services between the amplifier based remote sites. Examples of amplifier sites are line amplifier network elements using MOR/MOR Plus technology and 1600G Amplifiers. Among the services carried by the OSC is a DCC channel that permits OAM&P access for tasks such as software upgrades and alarm retrieval. The DCC channel carried by the OSC has a rate of 576 kbit/s. SONET layer alarms follow the SONET standard alarm hierarchy (such as line AIS and RFI) and are communicated through the SONET section and line overhead bytes. The optical layer alarms and performance monitoring functions, which do not have access to the SONET overhead bytes, use the DCC-type information carried on the OSC. The OSC signals are coupled onto the optical fiber with traffic-carrying channels, but are extracted at the amplifiers sites. The OSC signal is converted into an electrical signal at the amplifier site and sent through the backplane to the network element controller to be processed. Communication on the optical link must be bidirectional.
The OSC signal is allocated outside of the Nortel Networks wavelength plan grid. The MOR/MOR Plus OSC wavelength options are centered at 1510 nm and 1625 nm (see Figure 2-3). 1510 nm OSC is integrated into the amplifier module and follows the red direction. The 1625 nm OSC is a separate circuit pack.
Figure 2-3 MOR/MOR Plus OSC (solutions)
OTP2352p
2-fiber solution Red In/ Blue Out MOR+ Pair (1510 OSC) Blue In/ Red Out
RED BLUE 1510 OSC BLUE
1510 OSC
1510 OSC
1510 OSC
Blue In/ Red Out MOR+ Pair (1510 OSC)
Red In/ Blue Out
RED 1510 OSC
1510 OSC
1510 OSC
1510 OSC
1-fiber solution 1625 OSC 1625 OSC RED BLUE 1625 OSC 1510 OSC Red In/ Blue Out 1510 OSC Blue In/ Red Out 1510 OSC 1625 OSC 1510 OSC
1625 OSC Module
MOR+ Pair (1510 OSC)
1625 WDM coupler
The 1600G Amplifier OSC circuit packs support both unidirectional and bidirectional applications. The unidirectional OSC is an out-of-band channel that operates across unidirectional optical links at wavelengths 1510 nm and 1615 nm.
Note: Legacy links may have deployed unidirectional OSC module operating at 1480 nm and 1510 nm. The bidirectional OSC is an out-of-band channel that operates across bidirectional optical links at wavelengths 1471 nm and 1486 nm. Bidirectional applications include L-Band only or MOR Plus/L-Band overlay application (see Figure 2-4).
Figure 2-4 1600G OSC solutions
OTP2312p
Unidirectional, 2-fiber solution OSC-1 1510 nm ADD Tx Rx OSC-2 1510 nm DROP
1615 nm DROP Rx Tx
1615 nm ADD
Bi-directional, 1-fiber solution OSC-1 1471 nm ADD 1486 nm DROP 1471 nm Tx OSC-2 1471 nm Rx 1486 nm ADD 1471 nm DROP Rx 1486 nm Tx 1486 nm
Legend - WDM coupler - Faceplate connector
LAN Link A local area network (LAN) is a collection of devices, contained within a site such as a building or a campus, which communicate by sending messages to one another. The Ethernet backplane bus in the network element can be extended to reach remote equipment, and form an Ethernet LAN (see Figure 2-5). The maintenace interface circuit pack has three Ethernet ports, while the OPC interface circuit pack has one Ethernet port located on the faceplate. An IP address can be assigned to the shelf controller, and can be used for remote access to the shelf controller. The Ethernet port can be used to interconnect network elements and/or OPCs to Preside. The MI Ethernet port can carry both OSI and TCP/IP traffic. However, do not interconnect the OPC Ethernet port and the maintenace interface Ethernet port, since OSI traffic and OPC TCP/IP traffic must be separated (see Figure 2-6). Ethernet also provides service for communication between OPTera Long Haul 1600 amplifiers, OPTera Connect DX and S/DMS TransportNode OC-192 network elements. S/DMS TransportNode OC-48 network elements equipped with a Phoenix Shelf Processor with an Ethernet port, can be connected to the S/DMS TransportNode OC-192/OPTera Connect DX network element by means of an Ethernet bridge. In that case, only Nortel Networks equipment must be part of the resulting Ethernet LAN.
Data communications paths 2-9 Figure 2-5 Ethernet link between two network elements
OTP0240
NT22K08AA 08 1600ASDF
NTCA42AA08 1600ASDF
Ethernet DCC bridge
Ethernet backplane connection
NTCA42AA08 1600ASDF
Ethernet faceplate connection
Ethernet backplane connection
SC
MI
MI
SC
1234567890
SC
MI
MI
SC
Network element 1
Network element 2
1234567890
2-10 Data communications paths Figure 2-6 Ethernet ports on the maintenace interface (MI) and OPC
OTP2353p
OPC Ethernet Port MI Ethernet Port 1 MI Ethernet Port 2 MI Ethernet Port 3
Breaker/filter module A
Breaker/filter module B
OPC controller SC
OPC storage
OPC I/F
ES1 G1
ES1 G2
MXG1
MXG2
PTG2
PTG3
Filler
A maximum of ten network elements should be interconnected by daisy-chain MI-to-MI connections. A switch or a hub could be used when more than ten colocated network elements need to exchange OAM&P data. A Repeater (hub) regenerates the signal received on a port and then transmits the new signal to the adjacent ports. Repeaters offer a simple means to extend the maximum transmission distance between devices without affecting transmission quality. They operate at a layer 1 of the OSI model. One of the design considerations for the repeater is the limitation that packets traverse no more than 4 repeaters in a network, hence 4 repeater rule. Broadcasts on repeaters can impede the performance of the network. Switches allow simultaneous conversation to occur over dedicated circuits increasing performance when compared with hubs. Switches are intelligent network interconnection devices that operate at the layer 2 of the OSI model. They have 7-hop maximum. In other words, the data cannot traverse more than seven switches on its way from source to destination. Switches extend
MI
Filler
OW
distances beyond unshielded twisted pair (UTP) cable limitations. The maximum length of the UTP cable in an Ethernet network is 100 m. The maximum supported distances between switches over fiber are greater than 20 km. Maximum speed between switches is 1 Gbit/s (see Figure 2-7). Note: Remember that the DCN network is separate from the SONET payload network.
Figure 2-7 Network elements OAM&P communications through the Layer 2 Ethernet switches
DX4431p
NE UTP cable Switch Switch UTP cable Switch
NE
NE
NE
Legend NE = network element UTP = unshielded twisted pair
Layer 2 switches use media access control (MAC) source and destination addresses. Each network element controller, OPC and NP have a hard-coded MAC address. A switch learns endstation addresses by reading the source address of the endstation that transmitted the frame and recording which LAN interface received the frame. The switch enters this information into a data structure called the forwarding table, which the switch continuously updates (see Figure 2-8). The Ethernet network must be loop-free. Even when network elements are daisy-chained together using Ethernet cables, never give in to the temptation to provide resilience by closing the daisy-chain into a loop. The daisy-chained Ethernet network is, in essence, a single CSMA/CD (Carrier-Sensed Multiple Access with Collision Detection) collision domain. Thus, if a loop is formed, the first broadcast packet will be regenerated at each network element, and the data communications network will become congested. BayStack switches support the Spanning Tree Protocol, an optional configuration which prevents looping.
2-12 Data communications paths Figure 2-8 Switch forwarding table

OTP2118p
Forwarding table Node MAC address 00:00:A2:00:00:01 00:00:A2:00:00:02 00:00:A2:00:00:03 00:00:A2:00:00:04 LAN A A B B
Update
LAN A Switch OPC Node 1 MAC address= 00:00:A2:00:00:01 SC Node 1 MAC address= 00:00:A2:00:00:02 SC
LAN B
OPC Node 2 MAC address= 00:00:A2:00:00:04
Node 2 MAC address= 00:00:A2:00:00:03
CNet rules The Local Area Control Network (CNet) provides the communication link between colocated network elements and the control circuit packets of multi-processor network element and is only supported on S/DMS TransportNode OC-12 and S/DMS TransportNode OC-48. The physical constraints imposed by CNET are: The CNET LAN bus (cables and backplane tracking) must not exceed 122m (400 ft) in length. The formula for calculating the length of the CNET bus is as follows: Total bus length (in meters) = (total cables length) + (1.22 m * the number of shelves connected by CNET) Each S/DMS TransportNode OC-48 and S/DMS TransportNode OC-12 TBM shelf has two CNET connectors. Unused CNET connectors on a shelf must be terminated by a CNET termination plug to prevent noise from being introduced into the CNET cable. When using CNET cables to connect shelves, shelves must be grounded to the same Transmission Ground Reference (TGR).
The recommended maximum number of nodes of S/DMS TransportNode OC-48, mixed S/DMS TransportNode OC-48/OC-12 and S/DMS TransportNode OC12 are summarized in Table 2-1 (a node is defined as a shelf processor or an OPC).
Table 2-1 Maximum number of nodes Node type S/DMS TransportNode OC-48 Mixed S/DMS TransportNode OC-48/OC-12 S/DMS TransportNode OC-12 Maximum number of nodes 12 12 10
WAN Link A wide area network (WAN) is a collection of LANs that are located in different sites and connected through a remote link such as fiber, copper, satellite or microwave. WAN connections can be: Dedicated leased lines T1/T3 fractional T1/T3 Switched Packet switched: X.25 and Frame Relay Variable-sized data packets are routed through network. Each is transmitted separately over its own individual circuit and reformed into the data at the destination. Each circuit remains in place for only as long it takes to transmit the individual data packet, than it is cleared. Circuit-switched: ISDN (Integrated Services Digital Networks) A temporary dedicated circuit is established between two locations before data is transmitted. It remains in place until data is exchanged. The data are transmitted in a continuous stream. A WAN link is a solution for remote OAM&P communications between network elements (see Figure 2-9). It can be applied tunneling through an IP data network or the OSI routing. BayStack ARN, ASN or Backbone Node routers can be implemented. Note: Network element-Network element network must be separate from the management controller (Preside) network.
2-14 Data communications paths Figure 2-9 Network elements OAM&P communications through the WAN
DX4432p
WAN Router Router Router
NE 2 NE 1
NE 151
NE 301 NE 300 NE 302
NE 152 NE 3
NE 153
Legend NE = network element WAN = wide area network
Path selection
Every circuit on the OSI network receives a default cost. Table 2-2 specifies the path cost.
Table 2-2 Pre-defined cost of each path Path Ethernet CNet OSC (over 1600G) LDCC SDCC OSC (over MOR/MOR Plus) Cost 4 4 5 5 6 6
During the decision process, the total path cost of forwarding a packet along each possible path toward the destination is calculated. The total path cost is the sum of the costs of the circuits that make up the path. When deciding among multiple paths to a destination, the path that is assigned a lower path cost over one assigned a higher cost is chosen, even if the lower-cost path is longer in the number of hops. For example, in Figure 2-10 the lowest-cost path from network element A to network element C is the path through D (cost of 10) rather than the direct path through B (cost of 12).
Figure 2-10 Data communication paths
OTP2356p
Ethernet LTE-A
MOR MOR G0 192T/R G9
OTP-B
MOR MOR G0 G1
OTP-C
MOR MOR G0 G1
Regen-D
192 192 X/R X/R
LTE-E
192T/R
sdcc OSC dcc OSC dcc Idcc
sdcc
The data communications path between source and destination should not exceed a maximum number of hops (see Table 2-3). A hop refers to a transmission path from one network element, OPC or NP to the other network element, OPC or NP. Table 2-3 shows the recommended maximum number of OSC hops and OSC wavelengths for different amplifiers.
Table 2-3 Maximum number of OSC hops Amplifier MOR MOR Plus 1600G Number of OSC hops 7 13 30 OSC Wavelengths (nm) 1510/1625 1510/1625 1510/1615 or 1471/1486
3-1
OSI data communications

Chapter overview
3-
This chapter provides a description of the Open System Interconnection (OSI) model. This information is presented in the following sections: OSI reference model OSI network organization Routing roles Level 1 routing Level 2 routing OSI network addressing NSAP structure OSI basic routing algorithm Level 1 areas and area addresses Manual Area Address (MAA) sets Computed Area Address (CAA) sets OSI data link layer protocols OSI network layer protocols Network Name Service (NNS)
OSI reference model

The Open Systems Interconnection (OSI) model is a standard communications architecture developed by the International Standard Organization (ISO). This standard is enhanced for SONET applications in Telcordia GR-253-CORE SONET Transport Systems: Common Criteria. This standard contains profiles that elaborate SONET operations, administration, maintenance, and provisioning (OAM&P) communications and allows systems from different vendors to communicate. The OSI basic reference model connects a structured computer system architecture with a set of common communication protocols. It comprises the following seven layers: application layer, presentation layer, session layer,
3-2 OSI data communications
transport layer, network layer, data link layer, and physical layer. Each layer provides a specific function or service, and follows the corresponding OSI communication protocols to perform those services. OSI is an open system architecture. This means that peer-to-peer common layers between systems abolish the vendor-specific restrictions imposed by other architectures. The principles of the OSI layering scheme include the following: Similar services are on the same layer. Services provided by lower layers are transparent to the layers above it. The lower the layer, the more basic the services it provides. The higher layers build upon the services offered by the layers below them. Figure 3-1 shows the protocol stacks for SONET operations communications as per Telcordia GR-253-CORE. Specifically, this document will elaborate the data link layer and network layer protocol for the DCC & LAN protocol stacks.
OSI data communications 3-3 Figure 3-1 Interactive protocol stacks for SONET operations communications
OTP2317p
Stack A. X.25 Application ACSE CMISE ROSE ASN.1 BER/ Kernel Kernel/ Full Duplex TP4 CLNP Network X.25 LAPB EIA-232-D V.35
Stack B. DCC ACSE CMISE ROSE ASN.1 BER/ Kernel Kernel/ Full Duplex TP4 ES-IS IS-IS CLNP LAPD
Stack C. LAN ACSE CMISE ROSE ASN.1 BER/ Kernel Kernel/ Full Duplex TP4 ES-IS IS-IS CLNP LLC1 CSMA/CD AUI 10 BASE2 10 BASE-T Layer 3 Layer 7
Presentation
Layer 6
Session
Layer 5
Transport
Layer 4
Data Link
Layer 2
Physical
DCC
Layer 1
Legend
ACSE CMISE ROSE ASN.1 BER TP4 CLNP LAPD IS-IS - Association Control Service Element - Common Management Information Service Element - Remote Operations Service Element - Abstract Syntax Notation 1 - Basic Encoding Rules - Transport Class 4 - Connectionless Network Protocol - Link Access Procedure - D Channel - Intermediate System to Intermediate System DCC LAPB LLC1 CSMA/CD - Data Communications Channel - Link Access Procedure - B Channel - Logical Link Control - Carrier Sense Multiple Access Collision Detection AUI - Attachment Unit Interface 10BASE2 - 10 Mb/s Baseband Coax Cable 10BASE-T - 10 Mb/s Baseband over Twisted Pair ES-IS - End System to Intermediate System
OSI network organization

An OSI network is made up of end systems (ES) and intermediate systems (IS) that are organized hierarchically. An ES is a node that can originate and terminate data, but does not route data within an area.
An IS is a node that performs the same role as an ES, as it can originate and terminate data. However, an IS is also responsible for routing and relaying data from one network element to another within an area. For example, a network element is an intermediate system. End systems and intermediate systems are organized into routing areas. A collection of routing areas that use common routing protocols is a routing domain. An entire group of routing domains that are under one administrative authority (for example, a company or a university) is an administrative domain (Figure 3-2).
Figure 3-2 OSI network organization
OTP2121p
Administrative Domain
Routing Domain
Area
End Systems and Intermediate systems
Routing roles
A Protocol Data Unit (PDU) is a generic name for a data packet, which is used by a source node to send data to a destination node. PDUs are routed through a network using Level 1 and Level 2 routing. A Level 1 area is created or defined by a unique set of area addresses. Messages originating from, and destined for nodes within the same area, are routed using Level 1 routing. Areas or islands that are to be interconnected require Level 2 routing for messages originating from within one area to be routed to a node in another area. Each system within an area takes on one of the following roles: an ES, a Level 1 IS, or a Level 2 IS. By definition a Level 2 IS is also a Level 1 IS (see Figure 3-3).
OSI data communications 3-5 Figure 3-3 Level 1 routing within an area and Level 2 routing between areas
OTP2122p
Routing Domain
Area A
Area B
Legend - L1 Routing - L2 Routing - End system - L1 Intermediate system (IS) - L1/L2 Intermediate system (IS)
Level 1 routing
As previously mentioned, a Level 1 IS exchanges data with systems located within its area, and forwards packets destined for a different area or domain to the nearest Level 2 IS for processing. When two network elements are within the same Level 1 routing area, they use the Level 1 routing protocol to communicate with each other. Without Level 2 routing, network elements in different Level 1 routing areas cannot communicate.
Level 2 routing
A Level 2 IS exchanges data with systems located in a different area. Level 2 routing allows two network elements that are in separate Level 1 routing areas to communicate with one another, using the Level 2 routing protocol.
To support routing between areas, every area must contain at least one Level 2 router, and there must be a continuous path connecting all of the Level 2 routers. For example, to establish communication between two Level 1 routing areas, you must set one network element as a Level 2 IS in each area and interconnect the two Level 2 IS network elements. Level 2 routing also increases the interoperability between Nortel Networks equipment and other vendors equipment.
OSI network addressing

The OSI addressing scheme is based on the hierarchical structure of the OSI network. A unique Network Service Access Point (NSAP) address identifies each node within a network. The complete set of NSAP addresses contained within the OSI network is the global network addressing domain. This domain is divided into subsets called network addressing domains (which can be further divided into various subdomains). A network addressing domain is a set of NSAP addresses regulated by the same addressing authority. The addressing authority is the administration responsible for allocating unique NSAP addresses to OSI networks. Each addressing authority operates independently of other authorities at the same Level. An addressing authority for a higher domain can authorize the addressing authorities for its subdomains to assign NSAP addresses (see Figure 3-4). The subdomain specifies the format of the NSAP addresses allocated to the network. Two of the addressing authorities that administer NSAP addresses for OSI networks in the United States are the United States General Services Administration (GSA), which allocates NSAPs that are intended primarily for government use, and the American National Standards Institute (ANSI).
OSI data communications 3-7 Figure 3-4 Hierarchical addressing authority structure
OTP2123p
Global Network Addressing Domain
Domain Addressing Authority A
Domain Addressing Authority B
Subdomain Addressing Authority A.1
NSAP
NSAP
NSAP
NSAP
NSAP structure
The basic NSAP address structure reflects the hierarchical assignment of NSAPs throughout the network addressing domain. NSAP addresses must be unique. They can be up to 20 bytes long and contain two basic parts: the Initial Domain Part (IDP) and the Domain Specific Part (DSP) (see Figure 3-5).
Figure 3-5 Basic NSAP address structure
OTP2124p
IDP
DSP
AFI
IDI
Legend AFI IDI DSP IDP - Authority and Format Identifier - Initial Domain Identifier - Domain Specific Part - Initial Domain Part
The IDP consists of an Authority and Format Identifier (AFI) and an Initial Domain Identifier (IDI). The AFI is one byte in length and specifies the format of the IDI, the network addressing authority responsible for allocating values to the IDI, and the abstract syntax of the DSP. The IDI is variable in length. It specifies the addressing authority responsible for allocating values to the DSP and the subdomain from which they come. The authority identified by the IDI determines the structure and semantics of the DSP. For example, if you register your OSI network with ANSI, it is assigned to the ISO Data Country Code (DCC) 840 subdomain (see Figure 3-6).
OSI data communications 3-9 Figure 3-6 ANSI NSAP address format
OTP2125p
IDP
DSP
AFI
IDI
DFI
ORG
Rsvd
RDI
Area
ID
bytes
Legend AFI - Authority and Format Identifier IDI - Initial Domain Identifier DSP - Domain Specific Part IDP - Initial Domain Part DFI - Domain Format Identifier ORG - Organization Identifier Rsvd - Reserved RDI - Routing Domain Identifier Area - Area Identifier ID - System Identifier S - NSAP Selector
The AFI for these NSAP addresses is 39, which shows that the network is registered with ANSI and belongs to a DCC subdomain. The IDI as specified by the ISO Data Country Code is two bytes in length. The Country Code is actually one and half bytes in length (i.e. 840) plus half byte of padding (encoded as 1111 in binary or F in hexadecimal). Note that an address displayed as 39840 + 80 according to the reference publication format is encoded as 39840F80 in hexadecimal. The IDI is 840, specifying the DCC 840 subdomain, which is reserved for use by networks located in the United States. For the United States, ANSI has been chosen as the organization responsible for the DSP format. The DFI portion of the DSP is 128 to identify the SONET DSP format. The Organization (ORG) Identifier portion of the NSAP address is a globally unique number that is assigned by the DCC 840 subdomain. It identifies the network within the DCC 840 subdomain where the NSAP resides and the authority responsible for organizing the network into routing domains and areas.
Table 3-1 describes the contents of each field for an ANSI NSAP address.
Table 3-1 SONET NSAP Address Structure Field Name AFI IDI DFI ORG Value 39 840 128 variable Meaning Identifies the subdomain as DCC 840. Specifies the syntax of the DSP as binary bytes. Indicates that the subdomain is DCC 840. Identifies the SONET DSP format. Specifies the network within the DCC 840 subdomain, where the NSAP resides, and the authority responsible for organizing the network into routing domains and areas. Indicates that this field is reserved. Identifies the routing domain where the NSAP resides (assigned by the authority identified in the ORG field). Specifies the local area where the NSAP resides (assigned by either the authority identified in the ORG field or the local administrative authority that the ORG authority has delegated to this routing domain). Identifies the system where the NSAP resides specified by the systems MAC address. Selects the transport layer entity the system uses. This entity is specified in the ID field.
Rsvd RDI Area
0000 variable variable
ID S
variable 0 or 1
The IDP and the first part of the DSP (called the high-order part of the DSP) are the NSAPs area address. The area address identifies the area in an OSI network where an NSAP resides (see Figure 3-7).
OSI data communications 3-11 Figure 3-7 NSAP area address

OTP2126p
IDP
DSP
AFI
IDI
DFI
ORG
Rsvd
RDI
Area
ID
Area Address
Legend AFI - Authority and Format Identifier IDI - Initial Domain Identifier DSP - Domain Specific Part IDP - Initial Domain Part DFI - Domain Format Identifier ORG - Organization Identifier Rsvd - Reserved RDI - Routing Domain Identifier Area - Area Identifier ID - System Identifier S - NSAP Selector
When a node receives a data packet, it examines the contents of the packets NSAP destination area address fields. The node then compares its own NSAP area addresses with the NSAP destination address contained in the header of the PDU. If they match, then the destination system is in the same area. If the addresses do not match, then the destination system is located in a different area, and the node must route the packet outside the local area, using Level 2 routing services.
OSI basic routing algorithm

The OSI routing algorithm is based on link state information. Each OSI system periodically generates link state packets (LSPs) that describe the status of all of the systems immediate or adjacent data links. The system propagates these link state packets throughout the network. It also compiles a database of the link state information from every system and uses it to calculate the paths to all reachable destinations in the domain. The OSI routing algorithm uses these three processes: Update, in response to changes in network topology, systems transmit and receive LSPs. Each time a system receives an LSP, the system uses it to update its link state database with the new link state information. Decision, each router calculates the shortest paths from itself to all other systems that it can reach, using information it retrieves from its link state database. It then stores the paths in a forwarding database. Forwarding, when the system receives a PDU packet, it forwards the packet to the next hop specified in its forwarding database. Update process In an OSI network, every node must decide which systems it can reach directly. It finds out the identity and reachability of its immediate or adjacent neighbors and adds an assigned link cost. The node then uses this information to construct an LSP. LSPs describe what the system knows about the network topology. OSI routing systems generate LSPs periodically and also when there is a change in the network topology. For example, in Figure 3-8, a new ES is added to Area A. Node 1 generates an Level 1 LSP and propagates it to all other Level 1 ISs in the area. Each router that receives the LSP uses it to update its link state database, then propagates it out all interfaces except for the one that it was received on.
OSI data communications 3-13 Figure 3-8 Router 1 propagates LSPs to Area A
OTP2127p
Area A
To other L1 routers in Area A ... 2 3 1
Legend - LSP Path - End system - L1 Router - New end system
Similarly, if a new Level 2 IS is added to the network, Level 2 routers propagates both Level 1 and Level 2 LSPs throughout the domain. When a Level 2 IS receives a new LSP, it updates its corresponding Level 1 or Level 2 link state database with the new information. The router then forwards the LSP on all links except the one that it was received on. Each node refers to its link state databases when deciding the shortest path between itself and all other systems it can reach. Decision process During the decision process, the OSI system uses the link state database information that it has accumulated during the update process to: define a set of paths to every reachable destination in the domain calculate the shortest path to each destination record the identity of the first hop on the shortest path to each destination into a forwarding database
The system uses a shortest path first (SPF) algorithm to define the set of paths to a destination. The system does not define shortest in terms of distance. The shortest path is defined as the lowest-cost path based on the relative cost (metric) of routing a packet along each path. Every circuit on the OSI network receives a default cost. During the decision process, the OSI router calculates the total path cost of forwarding a packet along each possible path toward the destination. The total path cost is the sum of the costs of the circuits that make up the path. The router chooses the lowest-cost path. When deciding among multiple paths to a destination, the router will choose the path that is assigned a lower path cost over one assigned a higher cost, even if the lower-cost path is longer in the number of hops. For example, in Figure 3-9, the lowest-cost path from router A to destination IS is the path through router B (cost of 15) rather than the direct path (cost of 20).
Figure 3-9 Lowest cost path (Router A to B to IS)
OTP2128p
(A to B to IS) = 15 B
(A to B cost) = 5
(B to IS) = 10
A Direct A to IS cost = 20
IS
Once the router determines the lowest-cost path to a destination, it stores the identity of the corresponding adjacent router into its forwarding database. The adjacent router is the next hop on the path toward the destination. The system executes the decision process separately for each routing Level and keeps separate forwarding databases for Level 1 and Level 2 routing. It uses the Level 1 link state database to calculate the Level 1 forwarding database, which describes the shortest paths to destination systems located in
OSI data communications 3-15
the same area. If a system also routes Level 2 traffic, it uses its Level 2 link state database to create an Level 2 forwarding database, which describes the shortest paths to other destination areas. The systems OSI router bases its routing decisions on the most current network topology, therefore its link state database is updated when the network changes. Forwarding process The IS begins the forwarding process after it receives a PDU. First, it examines the destination address contained in the packet to determine if the packet requires Level 1 routing or Level 2 routing. It then refers to the corresponding forwarding database for information about where to forward the packet: If the system is a Level 1 router and the packets destination address is within the local area, the system checks its Level 1 forwarding database and forwards the packet to the next hop along the path to the destination. If the destination address is not local, the system checks its forwarding database for the location of the nearest Level 2 router in the area. It then forwards the packet to the next hop along that path. When a Level 2 router receives a packet, it checks its Level 2 forwarding database to see which Level 2 router is the next hop on the path to the destination area. It then forwards the packet to that Level 2 router. It continues to forward the packet between Level 2 routers until the packet arrives at its destination area, at which point it will be routed (using Level 1 routing) to its destination system.
Level 1 areas and area addresses

As specified in ISO 10589 standard, the maximum number of unique area addresses that can be supported in a Level 1 area is three. Although subsequent drafts have proposed increasing this number, support for three area addresses in a Level 1 area is sufficient for multivendor applications. To route messages between different vendor equipment applications, a routing adjacency must be established between the nodes. Although a SONET DCC example is used to illustrate the concept of routing adjacency, the same rules apply for LAN based connections (CNET and Ethernet). Once a connection has been established over the SONET DCC, the network elements need to determine their routing compatibility, or their ability to route messages to and from the other network element. This is where the routing adjacency status is determined. The network elements can now exchange routing information. This routing information contains the network elements NSAP address, the number of area addresses that the network element supports, and a list of the area addresses that network element supports (up to three).
If the network elements do not support the same number of area addresses the link cannot be established. The network elements compare lists of supported area addresses at this point. If the network elements have at least one area address in common, a routing adjacency is established and messages can be routed between the two network elements. Otherwise, if no area address is in common, then the network elements view the link as unusable for the purposes of routing messages to or from each other. Once a routing adjacency is established, the network elements exchange additional information. The additional information exchanged include which adjacent network elements are accessible and by which port. All network elements within the Level 1 network exchange their information with all other network elements in the network. This information allows each network element to build the same view of the network and the network connectivity. This information is used by those network elements that are Level 1 routers in order to route messages throughout the Level 1 network. There are instances where network elements in different Level 1 areas must be joined into one Level 1 area. One example is when network elements from different vendors in the same network must be able to route each other s messages. In this instance, it is likely that each vendor s equipment uses different default area addresses. You can provision one vendor s area address on the others network element which it is connected to, such that one area address will be in common. (see Multi-vendor interoperability in Chapter 5) When joining two different Level 1 areas into a single Level 1 area, only the network elements from the two areas which are physically connected to each other need to have an area address in common. This is shown in Figure 3-10. In this example, network element X and network element Y require a common area address for network element W to send a message to network element Z. Either network element X needs to have area address B added or network element Y must have area address A added. Note that all the other network elements in area A and B require no changes. For those two network elements to communicate, they must have an area address in common.
OSI data communications 3-17 Figure 3-10 Joining Level 1 networks without using Level 2 routing
OTP2066p.eps
Node X
Node Y Level 1 IS
Node W
Level 1 IS
Node Z
Area B
Area A
Manual Area Address (MAA) sets

The Manual Area Address (MAA) set on a network element refers to the provisioned area addresses on a network element. For example, if network element X has area addresses A and B provisioned on it, then its MAA set is A and B. Network element Y only has area address B provisioned on it, therefore its manual area address set is B. Assuming no other provisioning was executed, all the other network elements in area A will have manual area address sets of A. Similarly, all the other network elements in area B will have manual area address sets of B. Of the set of manual area addresses on a network element, only one is designated for use in that network elements NSAP. The network element uses this NSAP as the source address of all the messages it originates. As mentioned previously, to establish a routing adjacency, the network elements exchange information on the area addresses they support. This information is passed from one network element to another throughout the entire Level 1 area. As a result, all network elements in a Level 1 area know all the area addresses provisioned within the Level 1 area.
Computed Area Address (CAA) sets

The union of all MAAs in one Level 1 area is the Computed Area Address (CAA) set. The CAA set is found on each network element within the Level 1 area. All nodes can support a maximum of three area addresses in their CAA set. As a consequence, additional area addresses are dropped from the network element. The algorithm used to determine which area addresses to keep and which to drop is described in ISO 10589, and paraphrased as follows: Compare all area addresses digit by digit starting from the left. Once a lower digit is found, that area address is deemed to be lower than the other. After all area addresses in the computed area address set are compared, the three lowest stay and everything else is dropped. For example, assume the following five manual area addresses are provisioned on nodes within a Level 1 area: 123456 23456789 34567890 4 5 Following the algorithm described in ISO 10589, the computed area address set for the node consists of addresses 123456, 23456789 and 34567890, while area addresses 4 and 5 are dropped. No leading zeroes are added to pad the addresses to be the same length. All addresses are left justified and then the comparison begins. In this example the comparison ends after the first digits are compared. Since area addresses 4 and 5 have now been dropped, any nodes which are using either of these area addresses in their NSAP addresses will have a problem. This scenario can result in a loss of association of the network elements with area addresses 4 and 5. Consider for example, node X which has area address 5 in its manual area address set and uses this area address in its NSAP. When X originates a message, it places its NSAP as the source address of the message. The destination node, Y for example, will receive the message (assuming Y was not using either 4 or 5 as part of its NSAP address). Should Y wish to respond to the message, it will use the source address NSAP from the message it received from X now as the destination NSAP for its response. Y, since it dropped area address 5 from its computed area address set would not know
how to route the message within this Level 1 area to the proper destination node, X. If only Level 1 routing were supported in this network, Y would throw the message away and node X would not get a response to its message.
OSI data link layer protocols

This section summarizes the following OSI data link layer protocols implemented by Nortel Networks products: Telcordia GR-253-CORE SONET Transport Systems: Common Criteria LAPD SONET Protocol, which defines the Link Access Procedure on the D-Channel protocol for the SONET DCC (Based on ITU-T recommendation Q.921). Telcordia GR-253-CORE SONET Transport Systems: Common Criteria LCC Protocol, which defines the Logical Link Control Protocol for the LAN communications (Based on ISO 8802-2 Annex C). Link Access Procedure on the D-Channel Protocol The Link Access Procedure on the D-Channel (LAPD) Protocol is the data link layer protocol that specifies the procedures for establishing a point-to-point connection on the SONET DCC. This protocol is independent of a transmission bit rate and requires a full duplex, bit transparent, synchronous channel. LAPD can handle multiple users on the same multiaccess interface. LAPD tranmits information in frames. Figure 3-11 depicts the LAPD frame as specified in ITU-T Q.921. All frames start and end with a flag sequence. The flag preceding the address field is defined as the opening flag, while the flag following the Frame Check Sequence (FCS) field is defined as the closing flag. LAPD defines two specific bytes for the address field, which identify the Terminal Endpoint Identifier (TEI) and the Service Access Point Identifier (SAPI). It is possible to associate a TEI with a single Terminal Equipment (TE) for a point-to-point data link connection. A TE may contain one or more TEIs used for point-to-point data transfer. The SAPI identifies a point at which data link layer services are provided by a data link layer entity type to a layer 3 or management entity. Consequently, the SAPI specifies a data link layer entity type that should process a data link layer frame, and also a layer 3. There are two additional fields coded within the address field. The command/response (C/R) bit is set to one to indicate if the frame is to be interpreted as a command; otherwise, it is interpreted as a response. The receipt of a command frame dictates certain actions at the receiver, such as responding immediately by sending back a certain type of frame. The extended address (EA) bits can be used to stipulate a larger address field if the data link connection identifier (TEI/SAPI) needs to be expanded.
The control field identifies the type of frame, and also contains sequence numbering. The information field contains data to set up the link. Finally, the frame check sequence is a cyclic redundancy check (CRC).
Figure 3-11 The LAPD frame
OTP2308p
E A E A
C R
SAPI TEI
Flag
Address
Control
Information (I)
FCS
Flag
8 bits
8 or 16 bits
8 or 16 bits
M*8 bits
8 bits
8 bits
Legend CR - Command/Response bit EA - Extended address bits FCS - Frame check sequence SAPI - Service access point identifier TEI - Terminal endpoint identifier * - Multiplication M - An integer value (maximum number of octets is defined as 260)
The following requirements must be met to establish a SONET DCC link using the LAPD protocol: The frame size on each end of the connecting link must be identical. The number of supported area addresses at each network element must be the same. The connected network elements must have at least one supported area address in common. The frame size at both ends of the link must be identical in order to establish a connection. There is no requirement in the LAPD protocol to verify that this condition is satisfied. Therefore, the user must ensure that the frame sizes at each end of the connecting link are identical. Once the link has been established, the network elements can freely exchange routing information.
Logical Link Control protocol The Logical Link Control (LLC) protocol is the data link layer protocol that specifies the procedures for establishing a LAN link between two systems. This protocol is based on ISO 8802-2. The LLC protocol can support multiple logical links concurrently. The LLC protocol generates and interprets command and response PDUs. In Table 3-2, there are two types of command PDUs and their counterpart response PDUs: Type 1 operations do not include definition of an acknowledgment PDU, while Type 2 operations do not include a command PDU counterpart for the frame reject (FRMR) response PDU.
Table 3-2 LLC command PDUs Operation type Command Unnumbered Information (UI) Type 1 Exchange Identification (XID) Test (TEST) Information (I) Receiver Ready (RR) Receiver Not Ready (RNR) Type 2 Reject (REJ) Set Asynchronous Balanced Mode Extended (SABME) Disconnect (DISC) No command Response No response Exchange Identification (XID) Test (TEST) Information (I) Receiver Ready (RR) Receiver Not Ready (RNR) Reject (REJ) Unnumbered Acknowledgment (UA) Disconnected Mode (DM) Frame Reject (FRMR)
Figure 3-12 shows the LLC PDU frame as specified in ISO 8802-2. Each frame consists of the following fields: destination service access point (SAP) (DSAP), source SAP (SSAP), control, and information field. The DSAP address field identifies the one or more service access points for which the LLC information is intended. The SSAP address field identifies the specific service access point from which the LLC information field was initiated. The control field consists of one or two bytes that designate command and response functions. It also contains sequence numbers when required. The format of the control field of the LLC PDU defines the type of operation (either Type 1 or Type 2).
The contents of the information field depend on the type of PDU in which it appears. For example, the information field of an I format PDU and a UI command/response PDU contains only user data. Whereas the information field of an FRMR PDU contains the reason for PDU rejection by an LLC.
Figure 3-12 LLC PDU format
OTP2307p
DSAP address 8 bits
SSAP address 8 bits
Control 8 or 16 bits
Information M*8 bits
Legend DSAP address SSAP address * M - Destination service access point address field - Source service access point address field - Multiplication - An integer value (maximum number of octets is defined as 260)
OSI network layer protocols

This section summarizes the following OSI network layer protocols implemented by Nortel Networks products: ISO 8473 Connectionless-mode Network Service Protocol (CLNP), which defines the data packet format procedures for the connectionless transmission of data and control information. ISO 9542 End System to Intermediate System Routing Exchange Protocol, which defines how end systems and intermediate systems exchange configuration and routing information to facilitate the routing and relaying functions of the network layer. ISO 10589 Intermediate System to Intermediate System Routing Exchange Protocol, which defines how L1 and L2 routing work. Telcordia GR-253-CORE SONET Transport Systems: Common Criteria TARP Protocol, which defines how the TID Address Resolution Protocol is used to map OSI NSAP addresses to target identifier (TID) addresses. Connectionless network service protocol Connectionless network service protocol (ISO 8473) is the network layer protocol that specifies the procedures for the connectionless transmission of data and control information from one network system to a peer network system using CLNP packets. CLNP performs all of the routing functionality from the information contained in the routing tables produced by the end
system (ES) to intermediate system (IS) routing exchange protocol, and the IS to IS intra-domain routing protocol (both of these protocols are explained in this chapter). A systems OSI router processes each CLNP packet it receives independently and does not require an established network connection. A system bases its decision on how to process a CLNP packet solely on the information found in the packet header. The header information tells the system whether the packet has reached its destination or requires additional processing. A system partitions a CLNP packet into two or more new packets (segments) if the size of the packet is greater than the maximum size supported by the outbound network. The values contained in the header fields of the segmented packets are identical to those contained in the original packet (except for the segment length and checksum fields). The system sends the partitioned packets out on the network. When all of the packet segments finally arrive at the destination system, the system reconstructs the original packet before sending it up to the next layer for further processing. To control data misdirection and congestion throughout the network, CLNP includes a lifetime control function. The originating system can assign a specific lifetime value (in units of 500 milliseconds) to the lifetime field of the packet header before sending the system the packet out onto the network. Every system that receives the packet decrements its lifetime. If the lifetime value reaches 0 before the packet reaches its destination system, the packet is dropped. A system also discards a packet if its checksum is incorrect, if the destination address is unknown, or if the network is too congested to process the packet. CLNP includes an error reporting option that, when enabled, sends an error report data packet back to the originating system whenever a data packet is lost or discarded. End system-to-Intermediate system routing exchange protocol The End System (ES) to Intermediate System (IS) Routing Exchange Protocol (ISO 9542) defines the ESs and ISs on the same subnetwork exchange configuration and routing information.
Configuration reporting
The ISO 9542 configuration report function allows end systems and intermediate systems that are attached to the same physical network (subnetwork) to dynamically discover each others identity by periodically generating and exchanging Hello packets. The Hello packet exchange process tells the router which NSAPs it can access.
End systems generate Hello packets that contain the end systems subnetwork address, and specify which NSAPs the end system services. When a router receives an end system Hello packet, it extracts the configuration information from the packet (matching the subnetwork address with the corresponding NSAPs) and stores it in its routing information base. System routers generate Hello packets that contain the router s own subnetwork address. When an end system receives a router Hello packet, the end system extracts the routers subnetwork address and stores it in its own routing information base. Two types of timers control how often Hello packets are exchanged: a configuration timer and a holding timer. The configuration timer, which is maintained by each individual system, determines how often a system reports its availability or any change in its configuration to the other systems attached to the same subnetwork. The holding timer, which is a value set by the originating system, is contained in the holding time field of a Hello packet. It specifies how long a receiving system should retain the configuration information before it is flushed from the routing information base.
Route redirecting
The ISO 9542 route redirection function allows system routers to inform end systems of the most desirable route to a particular destination in one of two ways: through a different intermediate system directly to an end system on the same subnetwork After the intermediate system forwards a data packet to the next hop toward the destination end system, the router checks to see whether a more direct route exists. The IS determines whether the next hop is one of the following: the destination system, and whether it is attached to the same subnetwork as the originating system (Figure 3-13, Example 1) another IS that is connected to the same subnetwork as the originating end system (Figure 3-13, Example 2)
OSI data communications 3-25 Figure 3-13 Route redirecting

OTP2129p
Example 1. Destination system is on the same subnetwork.
Example 2. Next hop is another router on the same subnetwork.
O D
Original Path
Original Path
O D
Preferred Path
Preferred Path
Legend
O - Originating End System D - Destination System

- L1 Router - New end system
If the next hop is either a destination system or another IS on the same subnetwork, then there is a better path (one that does not traverse the IS) to the destination. The IS constructs a redirect (RD) packet, which contains the following information: destination address of the original packet subnetwork address of the preferred next hop
network entity title of the next hop, unless it is the destination end system holding timer and maintenance, security, and priority options
The IS sends the RD packet back to the originating end system, which has the option of using the RD packet to update its routing information base with the more direct route. Intermediate system-to-intermediate system intra-domain routing exchange protocol The IS-to-IS intra-domain routing exchange protocol ISO 10589 defines the way in which intermediate systems within a routing domain exchange configuration and routing information. It works with ISO 8473 and ISO 9542 to define how ISs can communicate and route packets within and between areas.
Intra-domain routing
Intra-domain routing functions within a single routing domain. The domain may consist of various types of subnetworks that have been administratively divided into separate routing areas. Under this protocol, Level 1 routers keep track of the routing that occurs within their own areas. Thus, each Level 1 router must know the topology of its local area, including the location of all other routers and end systems (from LSP and Hello packets that are exchanged throughout the network). Note that an Level 1 router does not need to know the identity of those systems residing outside of its local area, because it forwards all packets destined for other areas to the nearest Level 2 router. Similarly, each Level 2 router must know the topology of the other Level 2 routers located in the domain and the addresses that are reachable through each Level 2 router (again, through LSPs and Hello packets). The set of all Level 2 routers is a type of backbone network for interconnecting all areas in the domain. Note that an Level 2 router that supports Level 1 routing also needs to know the topology within its local area. For example, when a Level 1 router receives a data packet, it compares the destination area address in the packet with its own area address. If the destination area address is different, then the packet is destined for another area and needs to be routed using Level 2 routing. The router forwards the packet to the nearest Level 2 router in its own area, regardless of what the destination area is. The Level 2 router then forwards the packet to a peer Level 2 router that is the next hop on the path to the destination system. The packet will continue to be routed between Level 2 routers until it reaches its destination area, where it will be forwarded (using Level 1 routing) to the destination end system.
Figure 3-14 illustrates intra-domain routing within Domain A and Domain B. Within Domain A, for example, intra-domain routing occurs within each area and between areas 1 and 2.
Figure 3-14 Static intra-domain routing
OTP2130p
Routing Domain A
Routing Domain B
Area 4 Area 2 Area 3 Area 1 Area 5
Legend - Intra-domain Routing - Inter-domain Routing - End system - L1 Intermediate system (IS) - L2 Intermediate system (IS) - L2 Bordering Router
Inter-domain routing
Inter-domain routing is possible when paths to other domains are statically defined. To enable inter-domain routing, you must manually enter the set of reachable address prefixes into each Level 2 router that is linked to an external domain. (Such routers are called bordering routers.) The address prefixes describe which NSAP addresses are reachable over that Level 2 router s external link. The next time the Level 2 routers in the domain exchange LSPs, they become aware of the existence of the reachable external addresses and update their link state databases with this information.
As traffic is routed throughout the network, a router directs packets to a bordering router if the leading bytes of the destination addresses match the statistically defined reachable address prefixes. The bordering router then transmits the packet out of the domain. The next domain assumes responsibility for routing the packet to its final destination. Inter-domain routing occurs between Level 2 routers only. Figure 3-14 illustrates inter-domain routing between Domain A and Domain B. For example, the Level 2 bordering router receives a packet from within Domain A and forwards it to the Level 2 bordering router in Domain B. TID Address Resolution Protocol The Target Identifier Address Resolution Protocol (TARP) is used by TL1 managed network elements to convert TL1 target identifiers (TIDs) into network service access points (NSAPs).
Application layer protocols
Within SONET networks, there are network elements which support different application layer protocols for interactive class communication, for example: Nortel Networks OPTera Metro 3000 network elements only support TL1 as the application layer protocol. These network elements use TIDs to address and identify other network elements. All other Nortel Networks SONET network elements, such as the OPTera Connect DX and OPTera Long Haul 1600, support Common Management Information Service (CMISE) as the application layer protocol. These network elements use NSAPs to address and identify other network elements. Real world networks often consist of a mix of the above network elements and third party vendor equipment, as illustrated in Figure 3-15.
OSI data communications 3-29 Figure 3-15 Target identifier address resolution protocol
OTP3090p
OS
TL1 messages
NE OPTera Metro 3000 series or other TL1-managed NE OPTera Long Haul 1600
NE Nortel Networks OC-12, OC-48, OC-192
NE Nortel Networks OC-12, OC-48, OC-192
NE OPTera Metro 3000 series or other TL1-managed NE OPTera Long Haul 1600
CMISE-based network
Legend: NE = Network Element OC = Optical Carrier OS = Operating System TL1 = Transaction Language 1 TARP = Target Identifier Address Resolution Protocol
TARP
Target Identifier Address Resolution Protocol (TARP) is a propagation protocol allowing network elements to translate between TID values and NSAP addresses. The TARP feature maps TID values to NSAP addresses, so TL1 messages reach the proper network element regardless of the application layer protocol (TL1 or CMISE). SONET data communications networks use network entity titles (NETs) internally as a means of addressing network elements. A TID is a user-friendly name assigned to a network element. Users and operations systems can use the TID instead of the NET at the user interface level. The TID-to-NET translation occurs internally to the data communications nodes. A TID is a name that applies to an entire network element. It can be any text string, up to 40 characters long, and is similar to a UNIX host name. OSI addresses also apply to an entire network element. An OSI NSAP address
consists of the domain address, area address, the network element ID, and a value called the N selector, which is always 00. The OSI NSAP address can be up to 13 bytes long. TARP locates either the OSI NSAP address of a particular TID address or the TID address of a particular OSI NSAP address.
Full TARP services
Nortel Networks OPTera Metro 3000 network elements support TL1 as the application layer protocol. These network elements require full TARP services.
TARP transparency
Nortel Networks OPTera Connect DX, OPTera Long Haul 1600, and S/DMS TransportNode network elements support CMISE as the application layer protocol. These network elements do not require TARP services, but they do provide minimal TARP support. By providing minimal TARP support, these network elements do not disrupt the operations of network elements that support TL1 as the application layer protocol. Nortel Networks CMISE network elements do not originate TARP messages but do propagate them. This type of support is known as TARP transparency (see Figure 3-16). TARP transparency is required for operations, administration, and maintenance (OAM) interoperability between CMISE-based network elements and TL1-based network elements. TARP transparency is supported on all tributaries with data communications channel (DCC) capabilities. This feature ensures successful OAM&P interoperability between Nortel Networks equipment and other vendors equipment.
How TARP works
TARP resolves the NSAP-to-TID mapping by flooding requests that network management stations originate throughout the OSI domain. When a request reaches the network entity that owns the requested TID or NSAP, that entity sends a response that contains its NSAP and TID back to the originator. When the management station obtains the address it requested, it can proceed with its operation, such as polling the device for alarms. The routers role is to propagate the requests throughout the network, forwarding them to Level 1 or Level 2 adjacencies, as appropriate. The following example is taken from GR-253-CORE, Issue 3, September 2000. See Figure 3-16, for an illustration of how TARP functions. In this example, a remote login session is being initiated from the network element with TID AA to the network element with TID HH.
The network element with TID AA originates a TARP Type 1 request protocol data unit (PDU). This request is propagated through the network until it reaches the network element with TID HH. At this point, the network element with TID HH originates a TARP Type 3 Response PDU, which is sent back to the network element with TID AA.
Figure 3-16 Target identifier address resolution protocol transparency
F3698
Initiate remote login session, locate NET for TID HH
TID AA
TID FF
TID BB
TID DD
TID EE
TID GG
TID CC
TID HH
Legend: = TARP request = TARP response
When TID AA initiates a Type 1 request PDU, it forwards the request to each of the adjacent nodes. A node with a broadcast subnet, such as a local area network (LAN), likely has more adjacencies than a node in a point-to-point subnetwork and thus sends out more messages. Each adjacent node that receives the Type 1 request in turn forwards the request to all adjacent nodes, except the one that the original request was received from. For example, when TID BB receives the Type 1 request from TID AA, it forwards the request to TID CC but not back to TID AA. This is how the request propagates throughout the entire network.
3-32 OSI data communications TARP packet types
TARP has five types of packets. TARP Type 1 message When a network element originates a TARP Type 1 message, the message is propagated to all adjacent nodes within the network elements routing area. TARP Type 2 message A network element originating a TARP Type 2 PDU sends a message to all adjacent nodes within and outside the network elements routing area within the network elements routing domain. TARP Type 3 message A TARP Type 3 message is a response to a TARP request PDU. The Type 3 response is sent only to the originator of the request and does not use the TARP propagation principle. TARP Type 4 message A TARP Type 4 message is an indication of a TID or protocol address change made at the network element that originates the notification. The PDU is sent to all adjacent nodes both within and outside the network elements routing area. TARP Type 5 message When a TARP Type 5 message is sent, the address of the destination is known and thus the PDU is only sent to that address. This message does not use the TARP propagation principle.
Network Name Service (NNS)

The Network Name Service (NNS) provides a mechanism for distributing a database containing names and addresses to all processors in a Nortel Networks data communications network. For NNS, a name consists of the information required for a software application to identify a single processor, such as an NE ID or system ID. An address is the information required by the communications software to identify a single processor, otherwise referred to as the Network Entity Title (NET). Table 3-3 shows the information that is kept in the Network Name Service (NNS) database.
OSI data communications 3-33 Table 3-3 Information distributed by the network name service Equipment Name Mnemonic Name Network ID System ID NE ID or NCF ID Character String Address Network Entity Title Additional Information Not Interpreted by Name Service
Given one of the two types of names or the address, the Network Name Service provides all fields of all records that match. The Network Name Service distributes this database to all nodes in the network so that each node has a copy of the information. The additional information carried by the NNS is not large. The total size of a single record, including this information, is less than 100 bytes. The NNS feature consists of two types of software elements that reside in nodes across the network: a name server and a name client. The name server maintains an up to date copy of the names-to-address mapping by continuously exchanging information with all other name servers in the network. The ISO Intermediate System Routing Protocol previously described in this section is used for this exchange of information. The name client runs on a node that is either unable to, or chooses not to, participate in the exchange of information between name servers. The client chooses a particular name server and asks it to provide the client with an up-to-date copy of the information. This is also accomplished using ISO transport layer protocols. The name-to-address mapping information is carried between name servers within the Link State Protocol Data Units (LSPs) of the IS-IS routing protocol. An LSP is generated periodically by the network layer software of each IS in the network. It contains the network layer address of the node and a list of nodes it is connected to. This information is propagated throughout the network by the routing software. On nodes that contain a name server, the network layer software also adds naming information to each LSP it generates. This allows the name-to-address mapping to be propagated to all name servers in the network as continuously and reliably as the routing information.
4-1
Data communications network planning

Chapter overview
This chapter describes the following aspects of data communications network (DCN) planning considerations: Span of control considerations Level 1/Level 2 routing considerations Nortel Networks default address S/DMS TransportNode OC-48 Shelf Processor dependencies Level 2 routing checklist Splitting a Level 1 area Combining two Level 1 areas OAM head-ending of subtending metro network elements
4-
Span of control considerations

The following span of control (SOC) considerations apply when you implement Level 2 routing in your network: Operations controller (OPC) and Network Processors (NP) SOC cannot span Level 1 areas: All network elements in the SOC of an OPC or NP must reside in the same Level 1 area. Primary and backup OPCs must reside in the same Level 1 area. This configuration ensures maximum protection against system failures. Software downloads from OPC or NP to network element are not supported across Level 1 areas. Planning for the division or growth of OPC SOCs in Level 1 areas must comply with these engineering rules: All network elements in one OPC span of control must run the same software release.
4-2 Data communications network planning
An OPC span of control can have a maximum of 34 network elements (of which a maximum of 24 can be line-terminating equipment (LTE), add/drop multiplexer (ADM) or transparent multiplexer (TMUX) network elements) a maximum of 12 single 4-Fiber ADMs and 2x4-Fiber hub network elements, plus additional regenerator network elements, up to a total 34 network elements are supported in an OPC span of control a maximum of 24 single 2-Fiber ADM network elements, with no other network elements are supported in an OPC span of control a maximum of 12 single 2-Fiber ADM and Nx2-Fiber hub network elements, with no other network elements are supported in an OPC span of control a maximum of eight unprotected hub (Nx0:1) network elements, with no other network elements are supported in an OPC span of control Planning for the division or growth of NP SOCs in Level 1 areas must comply with these engineering rules: An OPTera Metro 3500 NP SOC can have a maximum of 16 network elements. An OPTera Metro 3100, 3300 or 3400 NP SOC can have a maximum of 16 network elements. All network elements in one NP SOC must have compatible software releases.
For more information on the non-Level 1 area considerations for the OPC or NP span of control, refer to the provisioning procedures in the NTP library for your network element.
Level 1/Level 2 routing considerations

The first step in setting up a network is to determine the individual Level 1 areas and the Level 2 backbone for connecting those areas. The network must meet these requirements: Maximum of 150 nodes in a Level 1 area Maximum of 150 nodes in a Level 2 area Contiguous path between Level 2 routers Unique network element IDs or Target IDs across all areas Network elements that can be provisioned as Level 2 routers Maximum of 150 nodes in a Level 1 area The maximum number of nodes that can communicate and reside within a Level 1 area is 150. These nodes include OPCs, network element shelf processors or shelf controllers, and Network Processors, all of which intercommunicate using the OSI protocol.
Data communications network planning 4-3
Maximum of 150 nodes in a Level 2 area Level 2 routing allows you to increase the size of your network beyond 150 network elements by permitting two network elements in separate Level 1 areas to communicate with one another, using the Level 2 routing protocol. To establish communication between two Level 1 routing areas, you must set one network element as a Level 2 intermediate system (IS) in each area and interconnect the two IS network elements. The maximum number of nodes (IS network elements) that can communicate and reside within a Level 2 area is 150. There are two reasons why the maximum number of nodes in a Level 1 or Level 2 area is 150: The construction a routing database (Level 1 or Level 2) requires usage of the network element central processing unit (CPU) in order to compute the shortest path between each nodes in the area. Computing the shortest path between N nodes has a worst case of N2 computations. Supporting 150 Level 1 nodes: 1502 = 22,500 computations Supporting 150 Level 2 nodes: 1502 = 22,500 computations Therefore, to support 150 Level 1 areas of 150 nodes (22,500 nodes total), each Level 2 node maintain two routing tables requiring 22,500 computations each or 45,000 computations in total. In contrast, to support a single Level 1 area of 300 nodes (and no Level 2 nodes) requires: 3002 = 90,000 computations Maintaining a routing database (Level 1 or Level 2) with all its related information (what nodes are visible over what connections) requires memory from the network element. The bigger the routing database gets, the less memory is available for normal network element operations. Contiguous path between Level 2 routers All Level 2 routers must be connected to one another in order to route messages to all Level 1 areas in the network. Once connected, Level 2 router network elements form a Level 2 backbone through internal data communication paths such as: section data communications channel (SDCC) line data communications channel (LDCC) OSC Ethernet
It is also possible to use external data communication paths to connect Level 2 routers. These may include: overlay circuits leased lines tunneling through an IP data network Note: For more information see Chapter 2 Data communications paths. When using external data communication paths, you may require additional devices to interface the data communication paths with an interface supported by the network element (such as Ethernet). These interface devices can be a switch or router that takes the Ethernet traffic from the network element and then transmits the data onto one of the external circuits. In the simple case where there are only two areas, the boundary network elements can be configured as Level 2 routers. To illustrate this situation, a three dimensional representation in Figure 4-1 shows the Level 1 and Level 2 routing domains and concepts.
Figure 4-1 A 3D illustration of Level 1 and Level 2 routing sub-domains
OTP2068p
L2 routing sub-domain
L1IS
L2IS
The Level 1 and Level 2 routing subdomains are represented as two parallel planes. The Level 1 area is the lower plane and the Level 2 routing subdomain is the upper plane. The Level 1 router or intermediate system (L1 IS) is represented as a two-dimensional circle on the lower plane. The Level 1 router can only operate in the Level 1 area. It cannot operate in the Level 2 subdomain. The Level 2 router is represented as a three-dimensional cylinder, bridging both the upper and lower planes. The Level 2 router therefore operates in both Level 1 and Level 2 sub-domains. As a result, the Level 2 router also acts as a Level 1 router and can route packets within its area just
like any Level 1 router while it also routes packets between different areas in the Level 2 subdomain. As you add more areas, the situation become more complex. Figure 4-2 shows A Level 2 path between two areas and also shows the other concepts: Level 1 link, Level 2 link and connectivity within and between areas. In Figure 4-2, a Level 1 link connects two nodes in the Level 1 subdomains (Area A and Area B, represented by the lower planes).Within each area, Level 1 links connect all Level 1 ISs, plus any end systems (ESs). In both areas, the connections between the L1IS and the L2IS of the area are also Level 1 links. A Level 2 link connects the two network elements at the Level 2 subdomain, represented by the upper plane. Level 2 links provide connectivity between Level 1 areas through the Level 2 routing subdomain. Level 1 links provide connections only within a single Level 1 area. Level 2 links provide connections at Level 2 routing sub-domains only. Figure 4-2 presents a logical view of the Level 1 and Level 2 connections as separate links. Although the links are logically separate, the Level 1 and Level 2 links can actually share the same physical media.
Figure 4-2 Level 2 path between two areas
OTP2069p
A Level 2 link connecting Area A and Area B, providing Level 2 connectivity between areas.
A Level 1 link connecting L1IS and L2IS, providing Level 1 connectivity within areas.
L2 routing sub-domain Area A Area B L1 routing sub-domain L1IS L2IS L2IS L1IS
In addition, Level 2 connectivity between Level 1 areas exists only when there is a direct connection between the Level 2 routers in two Level 1 areas. Figure 4-3 illustrates this concept by showing three Level 1 routing areas with broken Level 2 connectivity.
The three Level 1 routing areas (Area A, Area B and Area C) are represented by the lower planes. The Level 2 router in Area A is connected to the left Level 2 router in Area B. The Level 2 router in Area C is connected to the right Level 2 router in Area B. The two Level 2 routers in Area B are connected by Level 1 link to the Level 1 router between them. Thus, there is no direct Level 2 connection between the Level 2 routers in Area B. As a result, Area A cannot communicate with Area C because there is no continuous Level 2 path bridging Area A and Area C. This example shows how Level 1 and Level 2 paths operate separately. When a packet is routed through the Level 2 subdomain, the Level 2 router cannot make use of Level 1 links or paths to forward the packet. A packet routed through the Level 2 subdomain must use Level 2 paths formed by Level 2 links.
Figure 4-3 Three routing areas with broken Level 2 connectivity
OTP2070p
A Level 2 link connecting Area A and Area B, providing Level 2 connectivity.
No Level 2 link between theses two L2 routers! Area A and Area C do not have Level 2 connectivity. The Level 2 path from Area A to Area C is broken. L2 routing sub-domain
Area A
Area B
Area C
L1IS
L2IS
L2IS
L1IS
L2IS
L2IS
L1IS L1 routing sub-domain
A Level 2 link connecting Area B and Area C, providing Level 2 connectivity.
There is more than one method to fix the broken Level 2 connection in Figure 4-3. Two methods are shown in Figure 4-4 and Figure 4-5. In Figure 4-4, a separate circuit is set up between the two Level 2 routers in Area B to extend the Level 2 link. This connection can be an LDCC while SDCC connections provide the Level 1 links in Area B. This example assumes a separate circuit is available to address the lack of Level 2 connectivity.
In cases where a separate circuit is not available, use the method shown in Figure 4-5 to bridge the two areas. In this method, the L1 IS network element between the Level 2 routers in Area B is also provisioned as a Level 2 router. In this case, packets routed between Area A and Area C pass through three Level 2 routers in Area B.
Figure 4-4 Fixing the broken Level 2 connectivity [Method 1]
OTP2071p
A Level 2 path connecting Area A and Area B, providing Level 2 connectivity.
Adding a Level 2 link between these two Level 2 routers provides the required Level 2 connectivity. Now Area A, Area B and Area C all have Level 2 connectivity. Note that this link is a separate circuit from the Level 1 links between the Area B L2 routers
Area A
Area B
Area C
L1IS
L2IS
L2IS
L1IS
L2IS
L2IS
A Level 2 path connecting Area B and Area C, providing Level 2 connectivity.
4-8 Data communications network planning Figure 4-5 Fixing the broken Level 2 connectivity [Method 2]
OTP2072p
A Level 2 path connecting Area A and Area B, providing Level 2 connectivity.
Configuring the middle node as a L2IS also completes the Level 2 connectivity path between all three areas. Note that the circuits between the L2IS in Area B are functioning as both Level 1 and Level 2 links. L2 routing sub-domain
Area A
Area B L1IS L2IS L2IS L2IS L2IS L2IS
Area C
A Level 2 path connecting Area B and Area C, providing Level 2 connectivity.
Unique network element IDs or Target IDs across all areas To be able to rlogin to any node in the network across Level 1 areas, all network element IDs (NEID), network element Names and Target IDs (TIDs) in the network must be unique. Problems may arise if the NEID, network element Name or TID is not unique and the user wishes to rlogin to a node across Level 1 areas. In this case the user will rlogin to the first node responding to the Directory Service request to resolve the NEID, network element name or TID to an NSAP address. Duplicate NEIDs, network element names and TIDs are alarmed within a Level 1 area but not across multiple Level 1 areas. Network elements that can be provisioned as Level 2 routers Only S/DMS TransportNode OC-192, OPTera Connect DX or OPTera Long Haul 1600 can be provisioned as Level 2 routers. For example, a Level 1 area that contains only OPTera Metro 3000, S/DMS TransportNode OC-12 TBM or S/DMS TransportNode OC-48 or OC-48 Lite can not be used as Level 2 router (it will remain an isolated DCC island).
Nortel Networks default address

The 49+0000 area address is the factory default area address used by Nortel Networks network elements. Nortel Networks originally chose the 49+0000 area address prior to the introduction of Telcordia standard GR-253-CORE which specifies the ISO DCC NSAP format. The 49 AFI indicates the area address as the local format according to ISO standards. The '0000' component
is consistent with the locally administered format. NSAP uniqueness is guaranteed due to the IEEE specifications on the system ID portion of the NSAP. As such, the 49+0000 area address is not a barrier to scaling networks as they grow larger in size. Prior to Level 2 routing, the 49+0000 addressing scheme was sufficient for network elements partitioned into islands without connectivity between islands. Older releases of Nortel Networks SONET products (specifically, up to S/DMS TransportNode OC-48 release 14 and S/DMS TransportNode OC-12 TBM release 13) can only support the 49+0000 area address (OPTera Metro 3000, S/DMS TransportNode OC-192, OPTera Connect DX and OPTera Long Haul 1600 do not share this dependency). Application software on the OPC and network elements assumed that the network elements used an area address of 49+0000. These software dependencies were removed in S/DMS TransportNode OC-48 release 15 and S/DMS TransportNode OC-12 release 14. With Level 2 routing, each of these islands can be configured as an area and connected via Level 2 routers to provide full connectivity across areas. This capability allows service providers to scale their network to a large routing domain without sacrificing connectivity among network elements. Level 2 routing relies on each Level 1 area operating under a set of unique area addresses (preferably only one per Level 1 area). The existing 49+0000 area address can only appear in one Level 1 area from the entire network domain. Nortel Network recommends that network providers not use 49+0000 area address in their Level 2 routing network during normal operations. There are two reasons behind this recommendation. First, the local format area address does not provide sufficient flexibility in area address administration when compared with other formats recognized by ISO. Assigning area addresses implies a planning effort in maintaining area addresses used by the network. It is recommended that you adopt a more flexible format such as the ISO DCC format recommended by Telcordia standard GR-253-CORE for actual network deployment use. It is, therefore, recommended in the deployment of Level 2 networks that the 49+0000 area address (a local format address) be removed entirely. Second, to avoid accidental merging of two or more areas. When two areas are provisioned with a common area address, they merge to form a single area. It is possible that older equipment in the network cannot take advantage of, or meet the baseline requirement for Level 2 routing. However, this equipment may be connected to a Level 2 routing capable network. This older equipment most likely uses the default area address and the effort required to isolate this older equipment by turning off selected DCC links may be too great. It may be more feasible to isolate the older equipment by configuring them as a different area. If the 49+0000 area address is used in the Level 2 capable network, it may
accidentally merge with other equipment using the same area address. If this happens, you can potentially exceed the node size limit and overload the DCC network.
S/DMS TransportNode OC-48 Shelf Processor dependencies

In planning the data communication network, it is essential to select the correct Shelf Processor (SP) for the task. Some key factors to consider in this selection include: data communication ports requirements multivendors interoperability requirements S/DMS TransportNode OC-48 Shelf Processor various capabilities are summarized in Table 4-1.
Table 4-1 Different SP models for S/DMS TransportNode OC-48 SONET network element Product Engineering Code (PEC) SH Processor NT7E20CC SH Processor NT7E20CD Multivendor Interoperability Functionality Non-interoperable SP Hard-coded firmware relies on the 49+0000 area address Limited interoperable SP Must perform system lineup and testing (SLAT) from a SLAT OPC in 49+0000 area address. Can be provisioned to operate in another area after that. Fully interoperable SP Area Address Learning capability
Phoenix SP (NT7E20GD, NT7E20GB, NT7E20KA, NT7E20LA)
Data communication ports requirements Different SP types offer different configurations of data communication ports. The number of SDCC ports can determine the effectiveness of setting up inter-site communications. Ethernet and CNET ports are used for intra-site communication. The type of port to use is also a factor of the other communicating equipment that has to be connected to the OC-48 network element. Additional SDCC ports are useful in communicating with tributary network elements. The NT7E20GD SP has ten SDCC ports. Two SDCC ports can be assigned for the DCC on the main optics. The additional eight SDCC ports can be used to provide DCC connectivity to the tributaries. This is most useful
when the tributary network elements are not colocated with the OC-48 network element and inter-site communication has to be provided by DCC. Refer to the Appendix A for additional information about the physical interfaces available on the different SPs. Multivendors interoperability requirements S/DMS TransportNode OC-48 interoperability requirements rely on the SP in the network element. The NT7E20CC S/DMS TransportNode OC-48 processor has a dependency on the 49+0000 area address due to its firmware. The firmware relies on this area address in order to communicate with an OPC to receive a software download. This comes into play when the network element is booting only, which will occur either during a fault scenario or an upgrade. The NT7E20CD processor for the S/DMS TransportNode OC-48 shelf was improved to the point that if the network element was properly provisioned, it would not be dependent on the 49+0000 area address to facilitate requesting and receiving a software load. The Phoenix-based processor cards (anything other than the NT7E20CC or NT7E20CD) provide a more flexible solution. These processor cards allow the firmware to be upgraded similar to a software upgrade on the processor. The firmware loads available for these processors have been significantly enhanced, and completely eliminate the firmware dependency on the 49+0000 area address even when there is no provisioning data (area address learning capability).
Level 2 routing checklist

Before starting to plan a Level 2 routing strategy, identify the following specific requirements for the network: ability to rlogin into any network element anywhere in the network ability to rlogin from certain specific network elements isolation of certain network elements from others
Then, collect the following data about the network layout: location of OPCs, NPs and SOCs identification of products (OPTera Metro 3000, OPTera Connect DX, etc.), to determine which network elements can be set as Level 2 routers identification of existing data communications (LDCC, SDCC, OSC, Ethernet, CNet) identification of types of network elements (ADM, AMP, REGEN, etc.) This will determine data communication termination. identify amplifier network elements where Push Button Equalization (PBE) is to be used
Full data communication to all subtending network elements is mandatory.
Splitting a Level 1 area

To illustrate how to split a Level 1 area, consider an existing Level 1 area consisting of 150 nodes that must be split into three areas, A, B and C, consisting of 50 nodes each. The routing area currently supports nodes with area address A. Figure 4-6 shows Area A before the split, and Figure 4-7 shows Area A after the split.
Figure 4-6 Area to be split into 3 areas
OTP2084p
Figure 4-7 Area A split into 3 smaller areas, A, B and C

OTP2085p
To split Level 1 area into three new areas (A, B and C), you must first determine which nodes belong in each of areas. Next, remotely log in to each node assigned to area B and provision the area address in their manual area address set to area B. Last, remotely log in to each of the nodes assigned to area C and provision for area address in their manual area address set to area address C. The provisioning steps can result in a problem when each node generates its set of computed area addresses. Each node in area B states that it supports the set of manual area addresses {A, B}. Each node in area C states that it supports the set of manual area addresses {A, C}. Each node in area A states that it
supports the set of manual area addresses given by {A}. When each node puts these area addresses together they will generate a computed set of area addresses consisting of {A, B, C}. This computed set of area addresses now contains the maximum number of area addresses supported on each node. Incorrectly adding an area address can result in problems. If, for example, you enter address D instead of address B, each node will generate a computed area address set of {A, B, C, D}. Because each node can only support a maximum of three area addresses in its computed set of addresses, it must drop one address. According to ISO 10589, the three lowest area addresses are retained, and the highest area address is dropped. If A is the area address that is dropped, then all nodes whose NSAP address uses address A will lose connectivity to the network. If OAM information flows over this connection, then, from an OAM perspective, that node is isolated. It is easiest to split an existing area into two areas first, and then further split these resulting areas into smaller areas, as required. Thus, the way to split Area A into three areas, is to first split it in two, as shown in Figure 4-8.
Figure 4-8 First split of Area A
OTP2086p
Once Area A is split as shown in Figure 4-8, the nodes in Area B will support two manual area addresses, A and B. The nodes in area A will support area address A. The last step in splitting the areas is to remove area address A from the list of supported manual area addresses on the nodes in Area B. By doing this, OAM connectivity will be lost between the two areas. To maintain OAM connectivity between these two areas you must configure Level 2 routing before removing area address A from the list of manual area addresses supported by the nodes in area B. To support OAM connectivity between both Level 1 areas, a node in Area A and a node in Area B must be connected and configured as Level 2 routers. Once the Level 2 routers are connected, the nodes in Area B can have area
address A removed from their list of supported area addresses. OAM connectivity is maintained through the Level 2 routing connection between the two areas, as shown in Figure 4-9.
Figure 4-9 Areas A and B connected via Level 2 routers
OTP2087p
With the area now setup as shown in Figure 4-9, Area A can now be further subdivided to create Area C. The result is shown in Figure 4-10.
Figure 4-10 Area A further split into Area C
OTP2088p
You can apply the same methodology to further split Areas A, B or C, if necessary. When partitioning the new areas, it is advisable to partition them so that one node in each area can interconnect the new areas via Level 2 routing. The best case scenario is to have one Level 2 router in each domain interconnected via one link between each pair, as shown in Figure 4-11. Note: Redundancy can be created by having pairs of Level 2 routers interconnected (e.g. a pair of Level 2 routers in area A connected to a pair of Level 2 routers in area B and so on).
Data communications network planning 4-15 Figure 4-11 Areas A, B and C connected via Level 2 routers
OTP2089p
An alternative configuration is to have one Level 2 router in Area A connected to a Level 2 router in B, and another Level 2 router in A connected to a Level 2 router in C. Similarly B would have two Level 2 routers in its area, one connected to A and one connected to C. Last Area C would also have two Level 2 routers, one connected to the Level 2 router in B and one connected to the Level 2 router in A. Since ISO 10589 states that each Level 2 router must be connected to another Level 2 router, you must ensure that the pair of Level 2 routers in each routing area are physically connected. If there is no physical connection, then you must add one. This is shown in Figure 4-12.
Figure 4-12 One pair of Level 2 routers per area pair
OTP2090p
Guidelines for splitting areas An area should not be split into more than two areas at any one point in time. If more areas are required, then perform the splitting in an iterative fashion i.e. split the area first into two smaller areas, then split one of the newly created areas, and so on. Before removing the area address that is common to the two areas, Level 2 routers must to be provisioned and connected to maintain OAM connectivity. Once the Level 2 routers are configured and connected, the common area address can be deleted from the newly created area.
Note: Care should be taken that while splitting an area, the OPCs SOC boundaries are not violated.
Combining two Level 1 areas

Combining Level 1 areas is a simpler process than splitting an area. The areas to be joined must have an area address in common. In fact, only the nodes that have a link across the area boundary need to have an area address in common. The rest of the nodes within the area will pick up the new area address when they calculate the computed area address set. By remotely log in to the nodes that have a link that crosses the boundary between the areas to be joined and provisioning an area address to be common to both, a Level 1 routing adjacency will be created. Once the adjacency is created the nodes in each area are able to route to each other. The Level 2 routers used previously to route between these areas can now be removed. Since it may be desirable to have only one area address in use across these newly joined areas, the following should be done. Provision the common area address to be used on all nodes in the newly formed area. Once all nodes have been provisioned with this information all other area addresses in use in the area other than the one in common may now be deleted from the nodes. (For more in formation refer to OPTera Long Haul 1600 Provisioning and Operations Procedures, 323-1801-310, and OPTera Connect DX Provisioning and Operations Procedures, 323-1521-310). For simplicity, you should only join two areas to a time. This way, if a problem should occur there will be a free area address available to be used to rectify the problem.
OAM head-ending of subtending metro network elements

The introduction of the subtending unidirectional path switched ring (UPSR) feature in OPTera Connect DX Release 4.0 creates a stronger demand to use the OPTera Connect DX network element as a head-end data communications gateway. In this section, usage of the OPTera Connect DX network element as a head-end datacomm gateway refers to the case where the network element is acting as an interface between the customer TCP/IP network and the OSI DCC network. It is essential to first determine a strategy for how the subtending metro network elements will be managed prior to examining the data communications guidelines for a particular OPTera Connect DX network element.
There will be a trade-off between carrying the OAM information via DCC channels versus handing it off to the IP-oriented network on route to upstream management systems. Some factors that will influence this decision are: quantities of subtending network elements location of key network elements relative to TCP/IP network access approximate fill of the OPTera Connect DX network elements (which translates to expected utilization of OPTera Connect DX shelf controllers) comfort with Level 1 area address planning For example, when several OPTera Metro 3500 network elements are subtending off an OPTera Connect DX network element, it is possible to connect them to the TCP/IP network at: the Shelf Processor (SP) on each OPTera Metro 3500 network element the Network Processor (NP) on the gateway OPTera Metro 3500 network element the shelf controller (SC) on the closest OPTera Connect DX network element an operations controller (OPC) dedicated strictly to providing an OPTera Metro 3500 transport bridge (i.e. not managing any OPTera Connect DX network elements) the shelf controller (SC) on the OPTera Connect DX network element with the biggest pipe into the TCP/IP network the operations controller (OPC) managing a group of the OPTera Connect DX network elements as its primary role These choices are illustrated in Figure 4-13. For A and B, the OPTera Connect DX is not head-ending because the traffic does not pass through the shelf controller for routing. In cases C, D, E and F, the OPTera Connect DX network element is used as a head-end data communications gateway for the subtending metro network elements. The increased demand for head-ending on the OPTera Connect DX network element adds to the processing requirements of various components of the OPTera Connect DX network element. These include the shelf controller (SC), the message exchange (MX), the maintenance interface (MI), and the port circuit packs that are connected to the subtending equipment.
4-18 Data communications network planning Figure 4-13 Possible routes for OAM traffic to flow to the TCP/IP network
DX4430p
TCP/IP A B C NP SP DX D Dedicated OPC E F Primary OPC
DX
DX SP SP
TL1 Gateway engineering rules and restrictions Only one instance of the gateway may exist per shelf controller, and therefore per OPTera Connect DX network element. The following engineering rules and restrictions apply when TL1 Gateway sessions provides a mechanism for the external management system to logically connect with a subtending network element (or its gateway entity) through the TL1 Gateway application running on the OPTera Connect DX shelf controller: the TL1 Gateway feature is supported on all S/DMS TransportNode OC-192 and OPTera Connect DX (SONET) network elements (except for OC-192 regenerators) running OPTera Connect DX Release 4.0 software and above the TL1 Gateway supports a maximum of four TCP/IP connections from TL1 clients (on the TCP/IP side) to the gateway the TL1 clients can launch up to 16 TL1 sessions via the TL1 Gateway the Level-5 User Privilege Code (UPC) cannot be used with the TL1 Gateway to log in as surveil on a NP and continuously monitor all the SPs in its SOC For more information on the OAM TL1 Gateway feature, refer to Chapter 5 Data communications network applications.
OPC Transport Bridge engineering rules and restrictions TPB provides three application transport bridging services in one package: TL1 Gateway remote login (rlogin) ESWD TL1 OAM sessions are used with an NP while the rlogin sessions can be used with an individual SP. ESWD sessions must be to an NP. Only one instance of the TPB application may exist per OPC. It is possible for an OPC to run TPB while having a SOC to manage but in some cases, it may be preferable to deploy additional OPCs to perform strictly a TPB function. The following engineering rules and restrictions apply when OPC Transport Bridge (TPB) sessions provide a mechanism for an external management system to logically connect with a subtending network element (or its gateway entity) via a TL1/Telnet/FTP gateway application running on an OPTera Connect DX OPC. the OPC Transport Bridge supports a maximum of four TCP/IP connections from managing clients (on the TCP/IP side) to the OPC a maximum of 99 entries can be entered in the OPCs TPB commissioning list (entering NPs is recommended to reduce the overall number of sessions but individual SPs can also be entered) the managing clients can launch up to 40 sessions for TL1 OAM and/or rlogin via the OPC Transport Bridge the managing clients can launch up to 40 sessions for ESWD via the OPC Transport Bridge (in addition to the 40 for TL1 OAM and/or Rlogin) the OPC Transport Bridge does not support connecting to nodes in other Level 1 areas only Nortel Networks network elements can be managed via the OPC Transport Bridge This OPC does not need to manage the OPTera Connect DX network elements (i.e. have them in its span of control) in order to provide a gateway service to network elements subtending from them. For more information on the OPC Transport Bridge feature, refer to Chapter 5 Data communications network applications.
OPTera Connect DX Release 4.0 datacomm usage performance rules The engineering rules described below apply to the case where the OPTera Connect DX network element is used as a head-end gateway between the customer TCP/IP network and the OSI DCC network. The following data communications performance rules should be taken into account during network planning. These rules are not enforced by software and, if exceeded, they could potentially degrade the performance of the network, proportionally with the amounts exceeded. The impact will not be noticed if OAM DCC throughputs have excessive short bursts for short durations, but when planning the network, the Performance Rules should not be exceeded as this would mean a steady state of excessive CPU usage.
Performance Rule #1 (TL1 Gateway managed nodes rule)
No more than 16 OPTera Metro 3000 or S/DMS TransportNode OC-48 Lite Multiplexer individual subtending network elements (or their gateway entities) can be managed by the TL1 Gateway.
Performance Rule #2 (TPB TL1 OAM managed nodes rule)
No more than 150 individual subtending network elements (or their gateway entities) can be managed via TPB TL1 OAM.
Performance Rule #3 (tributary card-level rule)
For a tributary circuit pack supporting one SDCC (192 kbit/s) and one LDCC (576 kbit/s), no more than 333 kbit/s should be reaching the circuit pack. Note: When only the SDCC is turned in-service (IS) on the tributary circuit pack as it is the case for the Nortel Networks subtending network elements, the limit of 192 kbit/s should not be exceeded. Therefore, no more than 16 or 84 OPTera Metro 3000 or S/DMS TransportNode OC-48 Lite Multiplexer subtending entities (NPs or SPs) should concentrate their OAM head-end data communications through a single tributary circuit pack when managing via TL1 Gateway or TPB respectively. These performance rules related to OPTera Metro 3000 or S/DMS TransportNode OC-48 Lite Multiplexer network elements are illustrated in Figure 4-14.
Data communications network planning 4-21 Figure 4-14 OPTera Connect DX Release 4.0 datacomm performance rules for Nortel Networks subtending network elements
DX4328p
Maximum subtending entities: - 16 managed via TL1 Gateway or - 84 managed via TPB Maximum subtending entities using the OPTera Connect DX bay as an OAM Head-end Gateway: - 16 managed via TL1 Gateway and - 150 managed via TPB
SDCC N/A N/A N/A
Quad OC-3/12 1 LDCC 1 SDCC
Maximum subtending entities: - 16 managed via TL1 Gateway or - 84 managed via TPB
SDCC
OC-48 1 LDCC 1 SDCC
N/A HD OC-3 0 LDCC 0 SDCC N/A
As per OPC SOC rules
OC-192
Legend OPC SDCC SOC OAM NE TPB = Operations controller = Section data communication channel = Span of control = Operations, administration and maintenance = Network Element = Transport bridge
The formulas that were used to establish the performance rules described above to determine the maximum number of Nortel Networks subtending OPTera Metro network elements that an OPTera Connect DX network element can head-end are described in Table 4-2. These formulas characterize the average-high DCC OAM output for a Nortel Networks OPTera Metro 3000 or an S/DMS Transport Node OC-48 Lite Multiplexer network element. It is defined as raising a large number of alarms plus retrieving all performance monitoring data and it is assumed that only one node in ten will generate the average-high DCC OAM at the same time. When other vendors metro nodes are characterized in terms of average-high DCC output, their values can be used to determine their own Performance Rules.
The formulas of Table 4-2 can also be used to determine the impact when an OPTera Connect DX network element that support subtending OAM traffic also contains an OPC being used to manage a group of OPTera Connect DX network elements.
Table 4-2 DCC characterization formulas Maximum SC CPU% allowed TL1 Gateway 40% or SC CPU% Usage formula Head-ending kbit/s 2.8 kbit/s for a Nortel Networks Metro network element managed through TL1 Gateway Other vendor nodes TBD
SC CPU% = 5.513 + 0.0825 * X * <Head-ending kbit/s> where X is the number of subtending entities managed through TL1 Gateway
30% if the OPTera Connect DX network element is set as a Level 2 router (X is 16 for Nortel Networks Metro network elements) OPC Transport Bridge SC CPU% = 4.785 + 0.0274 * Y * <Head-ending kbit/s> where Y is the number of subtending entities managed through Transport Bridge (Y is 150 for Nortel Networks Metro network elements) OPTera Connect DX OPC span of control (SOC) SC CPU% = 0.06 * Z * <Head-ending kbit/s> where Z is the number of OPTera Connect DX network elements in the SOC managed by the OPC (Maximum for Z is as per OPC SOC rules)
2.28 kbit/s for a Nortel Networks Metro network element managed through Transport Bridge
N/A
2.25 kbit/s for an OPTera Connect DX network element managed via an OPC
N/A
Here are some examples that illustrate how the formulas from Table 4-2 can be used to determine Performance Rules.
Example #1: TL1 Gateway and TPB Head-ending to the same OPTera Connect DX network element
If 16 nodes are monitored via the TL1 Gateway, how many nodes can be monitored via the TPB? When an OPTera Connect DX node acts as a Head-end for both TL1 Gateway and TPB sessions, the allowed maximum of sessions between them can be calculated with the formulas provided in Table 4-2. Calculation: 40 = 5.513 + 0.0825 * 16 * 2.8 + 4.785 + 0.0274 * Y* 2.28 This gives Y = 504 nodes. However, we must reduce this number to the 150 nodes limit for a Level 1 area and the fact that TPB does not support connecting to nodes in other Level 1 areas (Performance Rule #2). Therefore we get a 16/150 combination for TL1 Gateway/TPB.
Example #2: Impact of a co-located OPC having a SOC on Performance Rules #1 and #2
What will be the impact on Performance Rules #1 and #2 if the Head-ending OPTera Connect DX network element has a co-located OPC that also has a SOC to manage? Calculation: We will assume a full SOC of 34 nodes for this calculation. The CPU% impact for the OPTera Connect DX OPC SOC is calculated as follow: SC CPU% = 0.06 * 34 * 2.25 = 4.59%. We now have to subtract this value from the available CPU% of 40% and redo the Performance Rules calculations. The new equations to determine the performance rules are: Performance Rule #1 (for TL1 Gateway) 40 - 4.59 = 5.513 + 0.0825 * X * 2.8 This gives X = 129 nodes. If the OPTera Connect DX network element is provisioned as a Level 2 router, the available CPU% will be 30% and this gives X = 86 nodes. This value must be reduced to 16 for Nortel Networks metro network elements. Performance Rule #2 (for TPB) 40 - 4.59 = 4.785+ 0.0274 * Y * 2.28 This gives Y = 490 nodes. Again, we must reduce this value to a maximum of 150 nodes per Level 1 area, so the TPB limit stays at 150. If the OPTera Connect DX network element is provisioned as a Level 2 router, the available CPU% will be 30% and Y = 150 also.
OPTera Connect DX Release 4.0 datacomm usage planning guidelines and recommendations The following are guidelines and recommendations when planning DCC networks with OPTera Connect DX Release 4.0: To stay within the limits of the tributary circuit pack-level rule (Performance Rule #3), you should distribute subtending network elements to different port circuit packs to balance DCC processing and routing within the OPTera Connect DX network element. Nortel Networks recommend that the OPTera Connect DX network elements that support subtending OAM traffic not contain an OPC being used to manage a group of OPTera Connect DX network elements. You should transfer OAM traffic from subtending network elements into customer s TCP/IP network at the first site containing DCC connectivity. This reduces the number of internal DCC hops. As a work-around, you can connect Metro Network Processors (NPs) directly to the TCP/IP network, where possible, thus avoiding the usage of the OPTera Connect DX network element as an OAM head-end gateway.
5-1
Data communications network applications

Chapter overview
This chapter provides a description of data communications network applications in the following sections: OAM&P traffic on shared DCC paths Establishing communications between DCC island
5-
Unified SOC and OPTera Connect DX 4-Fiber ADM network element OAM TL1 Gateway OPC Transport bridge Supporting Push Button Equalization Multi-vendor interoperability
OAM&P traffic on shared DCC paths

Operations, administration, maintenance, and provisioning (OAM&P) traffic primarily occurs between an operations controller (OPC) and the network elements within its span of control (SOC). Each OPC and its associated SOC have to reside within a single Level 1 area, although each such Level 1 area may contain multiple OPCs and their associated SOC. Figure 5-1 shows shared communications among different SOCs. Two SOCs are represented, a Regen SOC in grey and an add/drop multiplexer (ADM) SOC in white. All nodes can communicate through section data communications channel (SDCC), ADM nodes can communicate through line data communications channel (LDCC) as well. For example, the communication path from RGN OPC to Regen 4 will be OPC through LAN to ADM NE 3, through LDCC to ADM NE 4, and then through SDCC to Regen 4. Now the communication path from ADM OPC to ADM NE 3 will be OPC through LAN to ADM NE 1, through LDCC to ADM NE 4 and then through LDCC to ADM NE 3. Even though ADM NE 3 and ADM NE 4
5-2 Data communications network applications
belong to the ADM SOC, the Regen SOC will be using the LDCC link between ADM NE 3 and ADM NE 4 as well, no SOC will have priority over the other. The DCC paths within a Level 1 area are a shared resource.
Figure 5-1 Shared communications among different SOCs
OTP2074p
ADM NE 4
ADM NE 3 NE SP/SC Regen 3 LAN RGN OPC
Regen 4
Regen 2
ADM OPC LAN
NE SP/SC Regen 1 ADM NE 2
ADM NE 1
Legend - SDCC - LDCC
Figure 5-2 shows an Operations Support System (OSS) and a Gateway network element (GNE) being used to provide network management. In Figure 5-2, the OSS is a TL1 based management system. The GNE can be a third party digital cross connect system located in a central office (CO) with a connection to the OSS. The GNE is connected to ADM NE1 through SDCC. The OSS generates TL1 messages and transmits them over the DCC to the OPC for processing. (An OPTera Metro 3000 network element processes the TL1 messages itself). The OPC generates common management information service element (CMISE) messages and transmits them to the network elements (e.g. to provision a circuit or retrieve information) over the same DCC paths. The network elements respond to the CMISE messages through the same DCC paths. Finally, the OPC generates TL1 responses to the OSS,
Data communications network applications 5-3
and transmits them over the same DCC paths. The regular data communication (such as alarm reporting, database backup and restore, etc.) will share the DCC bandwidth with the TL1 traffic from the OSS. The volume of TL1 traffic from the OSS can affect regular data communications, such as alarm reporting and database backup and restore, because both sources of traffic must compete for the same DCC bandwidth. Because of the amount of messaging between the OSS and the OPC, it is recommended that you reduce the number or DCC hops between the GNE and the OPC, by placing the GNE as close to the OPC as possible. An extrapolation of the previous example is when another vendors network elements are subtended from the ADMs. You must consider the impact of the OAM&P traffic from the other vendors management system when communicating with those subtended network elements. The DCC traffic from the other vendors equipment share the same DCC bandwidth as the Nortel Networks network elements. The Nortel Networks cannot characterize the traffic patterns from other vendors network elements, and consequently the impact of additional traffic from other vendors equipment on the Nortel Networks network elements SDCC traffic. The only applicable guideline here is to minimize the amount of shared DCC bandwidth between the Nortel Networks equipment and the others vendors equipment.
5-4 Data communications network applications Figure 5-2 OAM traffic considerations with an OSS Gateway
OTP2075p
ADM NE 4
ADM NE 3
NE SP/SC Regen 3 LAN
RGN OPC
TL-1 OSS
Regen 4
Ring 1
Regen 2
OSS Gateway NE (GNE)
ADM OPC LAN
NE SP/SC Regen 1 ADM NE 2 Where is a better place to put the OPC? At NE 3 or NE 5? As it turns out, NE 5 is a better location. Putting the OPC in NE 5 reduces the distance between the Gateway NE and OPC, therefore reducing the number of DCC hops the OSS messages have to go through.
ADM NE 1
ADM NE 5
ADM NE 6
NE SP/SC LAN Regen 5
Regen 8
Ring 2
Regen 6
Regen 7 ADM NE 8 ADM NE 7
Legend - SDCC - LDCC
Guidelines for OAM&P traffic The guidelines for Level 1 area planning with respect to OAM&P traffic are the following: Plan the OPC SOCs by using a minimum of shared DCC paths with other SOCs. Minimize the amount of shared DCC paths between Nortel Networks network elements and other vendor s equipment or external OSSs.
Establishing communications between DCC island

This section looks at some specific configurations and how to apply Level 2 routing concepts to them. The following examples are used to illustrate the concepts: Linear system to bridge two areas Network with Amplifiers or Dense Regenerators Stacked ring Back-to-back ADM chains Nested rings
Linear system to bridge two areas All Level 2 routers must be connected in the Level 2 subdomain to provide continuous Level 2 connectivity. Due to physical or geographical constraints of the underlying SONET network, there may be no physical connection available to connect the Level 2 network elements. An example is shown in Figure 5-3. In Figure 5-3, there are two areas (Area 1 and Area 2) that must be connected. The Level 2 network elements of each area are located in different sites such that a LAN connection is not an option. There is no tributary or fiber connection between the two network elements, and therefore no DCC connection is available. If there happens to be another linear system between the two sites, we can consider using it to bridge the Level 2 path gap without using any external circuits. To connect the two Level 2 network elements of Area 1 and Area 2, each can be connected with Ethernet to the LTE. This is possible because they are colocated. The LTEs are configured as Level 2 routers to complete the Level 2 path. Note that in this example, the LTEs are configured as a third area, but this is the network operator's choice. In this example, the linear system is a simple two node system. As a result, the LTEs can communicate with both SDCC and LDCC. If there are regenerators between the LTEs, by assuming the regenerators are Level 1 network elements, LDCC can be used to connect the Level 2 LTEs, but SDCC cannot be used. Another example is given in Figure 5-4. In Figure 5-4, there are three areas to connect using Level 2 routing. Area 1 is connecting both Area 2 and Area 3. The Level 2 routing network elements in Area 1 happens to be located at extreme ends. Note that we have a broken Level 2 connectivity path, like in
Figure 4-3. To complete the Level 2 connectivity without using external circuits, one option is to configure all the network elements between Site A and B of Area 1 as Level 2 routers. This, however, is not an attractive solution for two reasons. First, there are many network elements between Site A and B, requiring a significant provisioning effort. Second, this option consumes Level 2 subdomain size limit and resources without connecting any additional areas. If a linear system exist between Site A and B, a similar bridging technique can be used. In this way, the LTEs are configured as Level 2 routers in another area. This allows connectivity to another area without configuring to many additional network elements as Level 2 routers.
Data communications network applications 5-7 Figure 5-3 Using a linear system to bridge a Level 2 path gap
OTP2078p
No physical circuits available to connect these two level 2 routers
Site A
Site B
Area 1 (arbitrary topology)
Area 3 (linear topology)
LTE
LTE
Site A
Site B
Legend - L1 IS Network element - L2 IS Network element - Network element site - LAN - SDCC - LDCC
5-8 Data communications network applications Figure 5-4 Using a linear system to bridge a Level 2 path gap
OTP2079p
Broken Level 2 connectivity at L2IS in Site A and L2IS in Site B. Area 2 and Area 3 are not connected. To Area 2 To Area 3
Site A
Site B
To Area 2
Area 4 (linear topology)
To Area 3
LTE
LTE
Site A
Site B
Area 1 (arbitrary topology) Legend - L1 IS Network element - L2 IS Network element - Network element site - LAN - SDCC - LDCC
Network with Amplifiers or Dense Regenerators A Dense Regenerator acts as a data communication hub where it terminates numerous DCCs or OSCs by allowing multiple spans of network elements to meet at a single point. Since the regenerator acts as a hub, it may be the natural choice to be the Level 2 router. ADM chains, Dense Regenerators and Amplifiers must be considered as candidates for Level 2 backbones. Network elements connected to the regenerator but not in the same area as the regenerator must be configured as Level 2 routers (see Figure 5-5).
Figure 5-5 Dense regenerator as a Level 2 routing hub
OTP2080p
Any Ethernet Device
Legend - L1 IS Network element - L2 IS Network element - OSC - LAN - SDCC - LDCC - ADM/LTE - Regen - Dense Regen - Amplifier
Stacked ring Figure 5-6 illustrates the stacked ring topology. In Figure 5-6, there are three rings with each ring configured as an area. There are many choices in connecting the areas in this example. The figure shows a possible solution where the Dense Regen (on Ring 3) is selected as the Level 2 router for Ring 3. The Dense Regen is connected to the ADMs on Ring 1 and Ring 2, which are also configured as Level 2 routers for the respective rings. Another possible solution is, assuming the ADMs on all the rings are colocated in one site, to connect them using Ethernet. The local area network (LAN) segment serves as a Level 2 backbone. It is possible to configure two Level 2 routers per area to offer additional redundancy in case of failure. Note that the two backbones must be connected. The connection between the backbones can be through DCC (LDCC in this case) horizontally between the ADMs in each ring. One horizontal connection is required for correct Level 2 connectivity. The other two horizontal connections are redundant. Selecting adjacent ADM sites to form a redundant backbone provides a simpler configuration. If the two LAN backbones are not adjacent to each other and separated by additional network elements, to complete Level 2 connectivity path between the backbones, one of the network elements on a ring must be configured as Level 2 routers.
Data communications network applications 5-11 Figure 5-6 Stack rings network
OTP2081p
Ring 1 Area 1 Ring 2 Area 2 Ring 3 Area 3 Ring 3 L2IS
Candidates for a backup Level 2 backbone
Ring 2 L2IS Ring 2 L2IS Legend - L1 IS Network element - L2 IS Network element - Network element site - OSC - LAN - SDCC - LDCC - ADM/LTE - Regen - Dense Regen - Amplifier
Back-to-back ADM chains The configuration shown in Figure 5-7 consists of three ADMs linear chains joined together in a back-to-back configuration. Assume these are OPTera Connect DX ADMs so each network element has SDCC and LDCC. Each chain is in its own area respectively.
To connect Area 1 to Area 2, the boundary ADMs in each area must be configured as a Level 2 router. In Figure 5-7, the two ADMs are colocated in Site A3, so they can be connected by Ethernet or DCC. Alternatively, both Ethernet and DCC can be used to provide redundancy. Boundary ADMs for Area 2 and Area 3 are configured as Level 2 routers to route traffic between the two areas. In this case, the ADMs are located at different sites so DCCs (SDCC and LDCC) are used to connect the ADMs. To complete the Level 2 connectivity path, the middle ADM in Area 2 must be configured as a Level 2 router (this example is an application of the theories described in Chapter 4, see Contiguous path between Level 2 routers). ADM terminates LDCC as well as SDCC. The Level 2 path between the three ADMs in Area 2 is provided by the LDCCs. If LDCC is not available, SDCC can be used to connect network elements in Area 2, and then the Regenerators between the ADMs must be configured as Level 2 routers to complete the Level 2 path.
Figure 5-7 Three ADM chains back-to-back
OTP2082p
Site A1
Site A2
Site R1
Site A3
Site R2
Site A4
Site R3
Site A5
Site A6
Site R4
Site A7
Site A8
ADM
ADM
ADM
ADM
ADM
ADM
ADM
ADM
ADM
Area 1
LAN
Area 2
Area 3
Legend - L1 IS Network element - L2 IS Network element - Network element site - Regen - LAN - SDCC - LDCC
Nested rings Figure 5-8 shows a configuration which consists of six rings, five of them nested inside a large outer ring. Each ring is configured in an area of its own. The first task in connecting the six rings with Level 2 routing is to pick the Level 2 backbone for this network. A backbone is usually a path that crosses the most areas. In Figure 5-8, the backbone is the path that runs north-south (vertically) along the west side of Ring 3, running along the east side of Ring 2, Ring 5, and Ring 6. This path does not pass through every area. Ring 4 (Area 4) is not reachable, so a shorter horizontal path is extended from the vertical backbone south along Ring 2, north of Ring 5 and finally reaching Ring 4.
After identifying the backbone path, identify the network elements along the path that must be configured as Level 2 routers. The most straight-forward approach is to configure every network element on the path as a Level 2 router. However, this is not the most efficient approach. Instead, identify the network elements that must be configured as Level 2 routers to complete the Level 2 connectivity. Each area requires a minimum of one Level 2 router to perform area routing for its area. You may also configure two Level 2 routers per area with one serving as a backup in case the other fails. This is illustrated for Ring 1 (Area 1) where there are two Level 2 routers configured. One is located at the top of the main vertical backbone and one at the bottom. Ring 2, Ring 4 and Ring 6 only have one Level 2 router for each area, so no redundancy is provided for these areas. The Level 2 router for Ring 2 and Ring 4 is located at the upper right corner of the respective ring. For Ring 6, the Level 2 router is located at the lower right corner of the ring. The upper left and right corner of Ring 5 are configured as Level 2 routers. The main reason for configuring two routers for Ring 5 is to connect the Level 2 router of Ring 4. The two routers for Ring 5 use LDCC to communicate. Ring 3 is more elaborate example, which extends the configuration for Ring 5, showing more network elements configured as Level 2 routers to complete the Level 2 path.
5-14 Data communications network applications Figure 5-8 Level 2 routing in 6 areas rings network
OTP2083p
Ring 1 Area 1
Ring 2 Area 2
Ring 5 Area 5 Ring 3 Area 3
Ring 4 Area 4
Ring 6 Area 6
Legend - L1 IS Network element - L2 IS Network element - Network element site - OSC - LAN - SDCC - LDCC - ADM/LTE - Regen - Dense Regen - Amplifier
Unified SOC and OPTera Connect DX 4-Fiber ADM network element

The OPTera Connect DX software provides the unified SOC capability so that OPTera Connect DX ADM nodes can be deployed in an existing S/DMS TransportNode OC-192 ADM ring. Different network element types (OPTera Connect DX ADMs, S/DMS TransportNode OC-192 4-Fiber ADMs and regenerators) can exist within the same SOC. Each OPTera Connect DX SOC can manage either SONET or SDH network element types, but not both. The unified SOC follows the same engineering rules as the separate SOC (as explained in Chapter 4 Data communications network planning). The maximum number of network elements in a unified span of control is 34 and each SOC requires a primary and a backup OPC. If the network size is larger than 150 nodes, Level 2 routing is required. OPTera Connect DX Release 3 introduced two new switch modules, the DX100 and DX140. These switch modules allow support of up to 20 Gbits/s of protected add/drop capability in a single network element. The introduction of a 2x4-Fiber ADM in OPTera Connect DX Release 3 implied some important changes in the OPC management and provisioning of 4-Fiber Rings. Normally, an OPC can manage up to 24 ADM nodes in a span of control for a ring or ADM chain configuration. But if one or more of these nodes is a 2x4-Fiber ADM, the maximum number of ADM nodes in the OPC SOC becomes 12. Since the 2x4-Fiber ADM reduces the maximum number of ADMs in an OPC span of control, there is a possibility that a single ring can be managed by more than one OPC. You must use a unique network element identifier (NE ID) for each configuration provisioned on an OPC. The network element IDs must be unique within the entire DCC island. The ability to support 2x4-Fiber Rings requires modification of the current Level 2 protocol. Until Release 3, you would hand off traffic connections traversing two rings via back-to-back tributaries. If you were concerned about reaching the 150 maximum node limit in a particular domain for DCC connectivity, you simply turned the DCC off at these tributaries, or used Level 2 routing to segregate the rings. However, using OPTera Connect DX Release 3 and above, with rings connected to a single 2x4-Fiber Ring network element, users cannot turn DCC off at the switch module where connections between rings occur. Therefore, the Level 2 protocol has been enhanced to accommodate this scenario. Figure 5-9 shows an example of how the areas could be divided when a 2x4-Fiber is used to connect two rings.
5-16 Data communications network applications Figure 5-9 Dividing two area when a 2x4-Fiber is used to connect two rings
OTP2358p
Area A
Area B
2 Ring A
5 Ring B
Level 2 Routers 7
2 x 4-FR Network element
Two different areas are provisioned and network elements 4, 5 and 6 are defined as Level 2 routers. By defining those network elements as Level 2 routers, the Level 2 routing backbone continuity is maintained between the two different areas and a remote login can be done from any network element in either area A or B to any network element in the network. Also, network elements 1 to 4 can be S/DMS TransportNode OC-192 and OPTera connect DX network elements running OPTera Connect DX Release 3 or above software in a Unified Span of Control. The same applies to the network elements 5, 6 and 7.
OAM TL1 Gateway

OPTera Connect DX Release 4.0 introduces the OAM TL1 Gateway feature that provides the capability for a remote TL1 client application (e.g. a TL1 GUI or TL1 OSS) to access a remote TL1 Server (e.g. OPTera Metro 3000, OC-48 Lite or any TL1 based network element) via the OPTera Connect DX SONET network element. The TL1 Gateway in OPTera Connect DX Release 4.0 provides the capability on the S/DMS TransportNode OC-192 or OPTera Connect DX network element to route the TL1 messages it receives on a pre-defined TCP port to the destination TL1 remote node. It would also route back the message it received from the remote node to the TCP port. The TL1 Gateway resides on the shelf controller (SC) (see Figure 5-10).
Data communications network applications 5-17 Figure 5-10 General TL1 OAM Gateway concept
DX3932t
Local OC-192/SONET DX node
Remote Subtending node TL1 engine
OSI stack
OSI DCN network
OSI stack
TL1 GW
TCP/IP Up to 16 remote TL1 sessions
A typical usage of the TL1 Gateway functionality is illustrated in Figure 5-11, where a craftsperson at site A has the capability to connect to a remote node Z (a TL1 node) through the OPTera Connect DX node. Note: The TL1 Gateway does not support local sessions in OPTera Connect DX Release 4.0. Only remote sessions are supported.
5-18 Data communications network applications Figure 5-11 Typical TL1 Gateway application
DX3913t
Site A
Site Z
TL1 GW
OSI DCN network
TCP/IP
WS
16 remote TL1 sessions Legend: = = = =
SONET OC-192/DX network element Subtending TL1 network element OSI communication path Ethernet/RS232
OPC Transport bridge

The Preside Applications Platform (AP) interface communicates with the TL1 managed object agent (MOA) through a transmission control protocol/internet protocol (TCP/IP) interface. The TL1 MOA maps the Preside AP interface calls onto management services that exist between the MOA and the OPTera Metro 3000 series network processor (NP). When these facilities are not available, an OPC can be used. The OPC must have TCP/IP local area network (LAN) access and section data communications channel (SDCC) connectivity to the remote network processor. The OPC Transport Bridge (TPB) sessions provide a mechanism for an external management system to logically connect with a subtending network element (or its Gateway entity) via a TL1/Telnet/FTP Gateway application running on an OPC. The OPC Transport Bridge functionality is supported on the S/DMS TransportNode OC-12 TBM, S/DMS TransportNode OC-48 and S/DMS TransportNode OC-192/OPTera Connect DX.
For more information on the OPC Transport Bridge feature, refer to the Software Administration Procedures in the NTP library for your network element.
Supporting Push Button Equalization

Push Button Equalization (PBE) is a software feature introduced in OPTera Long Haul 1600 Release 5 that automates the adjustment of transmitter output power values during the equalization process. The PBE feature automates the equalization process. The main function of the PBE is to apply the power adjustments to each transmitter based on Power Optimizers transmitters recommendations. For more information about PBE and Power Optimizer for 1600G, refer to 1600G Amplifier SLAT and Upgrades Procedures, 323-1801-226 and 1600G Amplifier Software Feature Guide, NTY317DG. MOR/MOR Plus systems do not support PBE, however, they can support manual equalize with Power Optimizer and Channel Power Recommendations. Refer to the MOR Plus SLAT and Upgrade Procedures, 323-1801-225 for details. To adjust the transmitter output power properly by PBE, your system must have the following: All transmitters must support WaveID and be provisioned as AM2. The WaveID feature enables the 1600G amplifier link to associate each wavelength with the correct circuit pack in the correct network element (For more information, refer to 1600G Amplifier Software Feature Guide, NTY317DG). A physical interconnection (Ethernet) between the terminal amplifier and the subtending transmitters that feed the amplifier, to enable PBE to issue commands to the subtending transmitters. The proper client/server protocols on subtending transmitter network elements. These protocols are available in the OPTera Connect DX Release 2 or OPTera Long Haul 1600 Release 4 software loads (or later). See the following sub-sections for schematics of the Ethernet connections required to enable PBE in various amplifier chain scenarios. Ethernet connections are required between OPTera Long Haul 1600 or OPTera Connect DX network elements and the first amplifier in the chain of 1600G Amplifiers. When DCC communication is available, as you are using transponder regenerator (XR) or transmit/receive (T/R) circuit packs, Ethernet connections are required only at one terminal site. When using wavelength translator (WT) circuit packs which do not terminate DCC, Ethernet connections are required at both terminal sites to ensure communication between amplifiers and transmitters.
Table 5-1 summarizes the baseline software, hardware and data communication requirements.
Table 5-1 PBE interoperability Requirements Software load Hardware Amplifier Rel. 5 or higher Optical Service Channel (OSC) Analog Maintenance 2 transmitters Communication (see Note 1) Level1 area OSC, or DCC, or DCC, or DCC, or Combiner (see Note 2) Rel. 4 or higher Analog Maintenance 2 transmitters Repeater Rel. 4 or higher Analog Maintenance 2 transmitters Connect DX Rel. 2 or higher Analog Maintenance 2 transmitters
MI-to-MI (Ethernet) MI-to-MI (Ethernet) MI-to-MI (Ethernet) MI-to-MI (Ethernet) Level 2 routing required to perform required to perform required to perform required to perform PBE across PBE across PBE across PBE across Level 1 areas Level 1 areas Level 1 areas Level 1 areas
Note 1: For more information about the Level1 areas and Level 2 routing, see Chapter 3 OSI data communications. Note 2: From Release 6 onwards, the combiner is no longer a network element type. The combiner is an application of the Repeater network element type.
The remainder of this section covers network deployment guidelines specific to OPTera Long Haul 1600 applications. Note: Since PBE requires communication between the 1600G amplifiers and all of the subtending OPTera Long Haul 1600 or OPTera Connect DX network elements, the DCC islands can potentially increase greater than 150 nodes depending on how many transmitters and network elements are provisioned. Considering this, the following scenarios take into account Level tracking. If your network application has less than 150 nodes, Level 2 routing is not required and a single Level 1 area can be used. Six applications are covered as follows: point-to-point systems with terminating equipment (no regeneration) point-to-point systems with terminating equipment (with regeneration) point-to-point systems with transparent WTs point-to-point systems with transparent WTs and multiple Level 1 areas interconnected by switches
overlay ring applications without regeneration overlay ring applications with regeneration
Point-to-point system with terminating equipment (no regeneration) This application consists of 1600G Amplifiers with DCC terminating transmitters that are housed in OPTera Long Haul 1600 Repeaters or in OPTera Connect DX bays. This application is not intended to be used when WT circuit packs are required since they are transparent interfaces without any access to the data communications channel. The configuration shown in Figure 5-12 consists of DCC terminating interfaces feeding the 1600G Amplifiers. The network has been segregated into two Level 1 network areas, Area 1 and Area 2.
Figure 5-12 Point-to-point system with DCC capabilities at the edges of the network
OTP1216
L1 Area (1) L1 Area (2)
OSC DCC Legend = OPTera Long Haul 1600 (and Connect DX) NE = 1600G Amplifier = Level 2 routers = Ethernet connection = Fiber connection
Area 1 consists of two groups of network elements (which can be either OPTera Long Haul 1600 Repeaters using S/DMS TransportNode OC-192/STM-64 XR circuit packs, OPTera Long Haul 1600 Combiners or
OPTera Connect DXs) at either edge of Area 1. The network elements at the head-end terminal site where the Level 2 routers reside are interconnected together through Ethernet. The Level 1 area exists between each transmitter bay through DCC. One network element at the left edge of Area 1 is designated as the Level 2 router. Area 2 consists of a 1600G Amplifier chain. The Level 1 area exists between each Amplifier bay through OSC. The first Amplifier in the chain is designated as the Level 2 router. Since DCC is available for the service interfaces, the network elements of the Area 1 network communicate through DCC. The amplifiers of Area 2 communicate through OSC. Since the amplifiers and transmitters reside in different network elements, an Ethernet connection between a network element in Area 1 and Area 2 is required to bridge them. This connection allows the DCC network to be bridged to the OSC network. An Ethernet connection between the two designated Level 2 routers permits Level 2 routing between Area 1 and Area 2. Point-to-point system with terminating equipment (with regeneration) This application is similar to the previous application with the exception that section terminating regeneration is required. The configuration shown in Figure 5-13 consists of DCC terminating interfaces feeding the 1600G Amplifiers. The network has been segregated into two Level 1 network areas, labelled Area 1 and Area 2.
Data communications network applications 5-23 Figure 5-13 Point-to-point system with DCC capabilities at the edges of the network (with regeneration)
OTP1217
L1 Area (1)
L1 Area (2) OSC DCC Legend = OPTera Long Haul 1600 (and Connect DX) NE = 1600G Amplifier = Level 2 routers = Ethernet connection = Fiber connection OSC DCC
Area 1 consists of two groups of network elements (which can be either OPTera Long Haul 1600 Repeaters (XR circuit packs), OPTera Long Haul 1600 Combiners or OPTera Connect DXs) at either edge of Area 1. In addition, XR circuit packs with SDCC termination are used for regeneration in Area 1. The Level 1 area exists between each transmitter bay through DCC. In addition, a Repeater is colocated with the amplifier bays. The Repeater is designated as the Level 2 router. Area 2 consists of a 1600G Amplifier chain. The Level 1 area exists between each Amplifier bay through OSC. The first Amplifier before the Repeater is designated as the Level 2 router. The Level 2 routers (the Repeater and the first line amplifier before the Repeater in Direction 1) are colocated at the Repeater site.
The network elements of Area 1 communicate through DCC. The amplifiers of Area 2 communicate through OSC. You require an Ethernet connection between the colocated Repeater and Amplifier, and the other Amplifier to bridge the DCC to the OSC. The two designated Level 2 routers permit Level 2 routing between Area 1 and Area 2. Point-to-Point system with transparent Wavelength Translators This application consists of OPTera Long Haul 1600 Wavelength Translators, which are transparent to the data communications channels at both the section and line level. The configuration shown in Figure 5-14 consists of Wavelength Translator interfaces and 1600G Amplifiers. The network has been segregated into three Level 1 network areas: Area 1, Area 2, and Area 3.
Figure 5-14 Wavelength Translator application
OTP1218
OSC L1 Area (2) L1 Area (1)
OSC L1 Area (3)
Legend = OPTera Long Haul 1600 (and Connect DX) NE = 1600G Amplifier = Level 2 routers = Ethernet connection = Fiber connection
Area 1 consists of a 1600G Amplifier chain and a Wavelength Translator that is used for transparent regeneration. The last Amplifier before the Repeater, the Repeater, and the first Amplifier after the Repeater are interconnected through Ethernet. Since the Level 2 routers must be connected to form one contiguous path, all the amplifiers in the optical chain must be designated as Level 2 routers. Area 2 consists of a group of OPTera Long Haul 1600 Repeaters located at the same site at the head end of the network. The Repeaters within Area 2 are interconnected through Ethernet. One network element is designated as a Level 2 router, and it has an Ethernet connection to the first amplifier in Area 1. Area 3 consists of another group of OPTera Long Haul 1600 Repeaters located at the same site at the tail end of the network. The Repeaters within Area 3 are also interconnected through Ethernet. One network element is designated as a Level 2 router, and it has an Ethernet connection to the last amplifier in Area 3. Since the Wavelength Translators are transparent to DCC, the network elements of Area 2 and Area 3 at either end of the path do not communicate through DCC. The Ethernet connections described in the preceding paragraphs allow for end-to-end data connectivity. The amplifiers of Area 1 communicate through OSC. An Ethernet connection between the designated Level 2 routers permits Level 2 routing between Area 1, Area 2 and Area 3, and Level 1 communication within each area. Point-to-Point system with transparent Wavelength Translators and multiple Level 1 areas interconnected by switches This application is similar to the previous application, with the exception that multiple Level 1 areas are interconnected by switches. The configuration shown in Figure 5-15 consists of Wavelength Translator interfaces and 1600G Amplifiers. The network has been segregated into seven Level 1 network areas: labeled Area 1 to Area 7.
5-26 Data communications network applications Figure 5-15 Wavelength Translator application and multiple level 1 areas interconnected by switches
OTP2285p
L1 Area (6)
L1 Area (7)
L1 Area (4)
L1 Area (5)
OSC L1 Area (2) L1 Area (1)
OSC L1 Area (3)
Legend = OPTera Long Haul 1600 (and Connect DX) NE = 1600G Amplifier = Level 2 routers = Ethernet connection = Fiber connection = Ethernet switch
Area 1 consists of a 1600G Amplifier chain and a Wavelength Translator that is used for transparent regeneration. The last Amplifier before the Repeater, the Repeater, and the first Amplifier after the Repeater are interconnected through Ethernet. Since the Level 2 routers must be connected to form one contiguous path, all the amplifiers in the optical chain must be designated as Level 2 routers.
Areas 2, 4 and 6 consist of groups of OPTera Long Haul 1600 Repeaters, each with one such Repeater located at the same site at the head end of the network. One network element per area is designated as a Level 2 router, and has an Ethernet connection to each of the other Level 2 routers at that site through a switch, the first amplifier in Area 1 has an Ethernet connection to the switch as well. Areas 3, 5 and 7 consist of groups of OPTera Long Haul 1600 Repeaters, each with one such Repeater located at the same site at the tail end of the network. One network element per area is designated as a Level 2 router, and has an Ethernet connection to each of the other Level 2 routers at that site through a switch, the last amplifier in Area 1 has an Ethernet connection to the switch as well. The amplifiers of Area 1 communicate through OSC. The Ethernet connections between the designated Level 2 routers at each end, through the switch, permit Level 2 routing between Areas 1, 2, 3, 4, 5, and 7. This specific example deals with seven Level 1 areas but can be applied to multiple Level 1 scenarios. A switch is used at each end site to provide Ethernet connectivity between large numbers of Level 2 routers. Overlay ring application without regeneration In principle, the overlay ring application is similar to a point-to-point system. Therefore, you can apply the concepts introduced in the previous applications when the system requires ring overlays. The configuration shown in Figure 5-16 consists of three Level 1 network areas: Area 1, Area 2, and Area 3. In this Figure, Area 1 network elements are labeled A, Area 2 network elements are labeled B, and Area 3 network elements are labeled C. Area 2 and Area 3 represent independent ring networks that are overlaid onto the 1600G Amplifiers. At each physical site, transmitters in the same ring are designated to the same area.
5-28 Data communications network applications Figure 5-16 Overlay ring application without regeneration
OTP2095p
C B B
A OSC
A OSC OSC
A OSC
B C
A DCC
B C
Area 1 consists of a OPTera Long Haul 1600 optical amplifier chain. The first amplifier in the chain is designated as a Level 2 router. The Level 1 Area exists between each Amplifier network element through OSC and Ethernet. Area 2 and Area 3 consist of transmitter network elements as in the first three applications. Each area contains ring networks overlaid on each other. To contrast with point-to-point systems, more than one area can be required at the head-end Amplifier site, depending on the number of network elements in the Level 1 Area. One transmitter in each area is designated as a Level 2 router, and it has an Ethernet connection to the Level 2 router Amplifier in Area 1. Consider the following additional guidelines: If the number of nodes in an area exceeds 150 nodes, you must further segregate the area. If the number of nodes in a Level 1 Area has exceeded 150, you may be required to add more Level 2 routers at one site. Bear in mind that 150 Level 2 routers are supported. It is recommended to establish as many nodes as possible as Level 1 areas, before you establish a Level 2 route. Overlay ring application with regeneration The guidelines for designing data communication networks in ring overlay applications with regeneration is almost identical to the guidelines described in the previous application. Refer to the previous application for guidelines if you require regeneration. Some additional guidelines are as follows: Locate the Repeater in the same Level 1 Area as one of the rings, to ensure data communications. At the Repeater site, Ethernet connections between the Amplifiers are required. The configuration shown in Figure 5-17 consists of a ring overlay network with regeneration. In Figure 5-17, Area 1 network elements are labeled A, Area 2 network elements are labeled B, and Area 3 network elements are labeled C.
5-30 Data communications network applications Figure 5-17 Overlay ring application with regeneration
OTP2096p
C B B
A OSC
A OSC
A OSC OSC
A OSC OSC
B C
B DCC
B C
PBE communication process PBE communicates through the OSI to its subtending OPTera Connect DX or OPTera Long Haul 1600 network elements through two applications: A Communications Server (CS) that exists on the shelf controller of the network element (OPTera Connect DX or OPTera Long Haul 1600) which has the transmitter circuit packs. A Communications Client (CC) that exists on the shelf controller of the post-amp network element (1600G). Messages sent to different network elements fully support Level 2 routing. Figure 5-18 illustrates the messaging process used while PBE is being performed at the AMP1 post-amp on a point-to-point system (no regeneration) with terminating equipment in the context of Level 2 routing. The terminating equipment have DCC communications. The communication process between AMP1 and NE1 is as follows: 1 The CC at AMP1 tries to connect to the CS at NE1 with its NSAP address. Since NE1 is in a different Level 1 area (it is not listed in AMP1s Computed Area Address), AMP1 communicates with its closest Level 2 router (in this case AMP2) 2 AMP2 looks up its Level 2 routing table and routes the message to NE2 which is the Level 2 router supporting the area address of NE1. 3 NE2 looks up NE1 in its Level 1 routing table and routes the message to NE1s CS which processes the command from AMP1. 4 NE1s CS sends back as response to its Level 2 router, NE2, through Level 1 routing. 5 NE2 sends back the response to the Level 2 router supporting AMP1s area address, AMP2, through Level 2 routing. 6 AMP2 forwards NE1s response to AMP1s CC through Level 1 routing.
5-32 Data communications network applications Figure 5-18 PBE communication process
OTP2114p
L1 Area (1)
NE2 L1 Area (2)
NE1
AMP2
AMP1
NE2
AMP2
AMP1
NE1
1. Command
2. L2 routing
3. L1 routing
Process command
4. Response
5. Response
6. Response
Multi-vendor interoperability
In the same way that older releases of Nortel Networks SONET products require the 49+0000 area address to operate, some third-party vendor equipment can require specific addresses to communicate correctly. To add a third-party vendor's equipment into a network of Nortel Networks system requires the following steps: Identify the area address being used by the third-party vendors equipment. Identify the Nortel Networks network elements that are adjacent to the third-party equipment. Verify that no more than three area addresses are in use in this network (if not, the network must be repartitioned to make room for additional area addresses). Add the third-party equipment address to the Nortel Networks equipment, if it is not present. In the case of enabling data communications on the SONET DCC, execute the following additional steps: Determine if section and/or line DCC connectivity is required, along with the corresponding facility. Adjust the length of link service data unit (LSDU, otherwise referred to as the frame size) of the corresponding facility. Nortel Networks SONET products can provision the line and section LSDU length to a value between 512 and 1492. This enables successful interoperability with third-party vendors equipment whose LSDU length is different, and often fixed to 512. Enable the corresponding DCC port (provision in service) for the facility at the network element. These steps allow the third-party network element to communicate in the same Level 1 area. If the third-party network element does not depend on specific area addresses, the third-party network element can be added into the same Level 1 area with Nortel Networks network elements by provisioning the same area address on all the Nortel Network and third-party network elements. For example, if the area address to be used is 39840+80000000000000000000, it can be provisioned into all the Nortel Network and third-party network elements. If the third-party network element must operate in a different area, one of their network element can be provisioned as a Level 2 router and an adjacent Nortel Networks network element can be provisioned as a Level 2 router to route between the areas. Level 2 routing concepts presented in this document are generic, and apply to all third-party vendor network elements in a network using Nortel Networks systems.
TARP support on the OPC for mixed-vendor networks The OPC supports the target identifier address resolution protocol (TARP) as specified by Telcordia GR-253-CORE SONET Transport Systems: Common Criteria. Data communications interoperability between the OPC and other vendors network elements through the TL1 interface requires the TARP feature to be enabled. The OPC can accept TL1 communications from other vendors equipment by way of S/DMS TransportNode OC-48 network elements. Electronic software delivery to the OPC over an Open Systems Interconnect (OSI) network from a remote software repository also requires TARP. For a description of the TARP protocol, see Overview of the TARP protocol on TID Address Resolution Protocol in Chapter 3. TARP support on the S/DMS TransportNode OC-48 network element for mixed-vendor networks TARP transparency is required for operations, administration, and maintenance (OAM) interoperability between S/DMS TransportNode OC-48 network elements and TL1-based network elements. The TARP transparency feature is supported on all tributaries that have SONET section data communications channel (SDCC) capabilities. S/DMS TransportNode OC-48 network elements support TARP transparency in all linear and ring configurations, including across matched nodes in rings. S/DMS TransportNode OC-48 network elements are not TL1 based and as such do not require TIDs. Therefore, TARP messages do not originate from an S/DMS TransportNode OC-48 network element. The S/DMS TransportNode OC-48 network element does not respond to TARP messages addressed to it that request its TID. The S/DMS TransportNode OC-48 network element propagates other TARP messages addressed to it that require propagation. For a description of the TARP protocol, see Overview of the TARP protocol on TID Address Resolution Protocol in Chapter 3.
6-1
Trouble clearing
Chapter overview
This chapter provides trouble clearing guidelines for routing related data communications problems. These steps can be modified or the procedure shortened, as you become familiar with the tools available, and develop experience in clearing problems in this area. This information presented in two sections: Trouble clearing within the Level 1 area Trouble clearing across Level 1 areas
6-
6-2 Trouble clearing
Procedure 6-1 Trouble clearing within the Level 1 area

Indications
Normally, data communications problems in a local area are observed when an operations, administration and maintenance (OAM) association is lost to a remote network element or when trying to log in remotely to another node. The high level idea of the debugging steps described in this section is to guess a routing path between the source and destination nodes that experience a data communication problem. Once identified, narrow down the problem by using the appropriate tools iteratively along the routing path until the source of the problem is found. Please note that the procedures for using these tools may vary from product to product. For more information refer to Appendix C: Data communications tools or the applicable Nortel Networks technical publications (NTP) sections for the given product.
Possible causes
A loss of association problem in a local area may often be caused by the misprovisioning of an area address on a network element. Refer to the applicable NTPs for area address provisioning on a particular product. A high-level flow chart of this debugging procedure is shown in Figure 6-1.
continued
Trouble clearing 6-3 Procedure 6-1 (continued) Trouble clearing within the Level 1 area
Actions
Step 1 Action Verify that the area addresses provisioned at the local operations controller (OPC) are correct. Specifically, recall that area address misprovisioning is a common cause of data communication problems. Since area addresses must be entered as a string of a maximum of 26 characters (often comprised of several zeros), it is common to make an error when entering a new area address. Verify that all area address have been properly provisioned. Obtain a UNIX shell session from OPC UI and enter the following command: nnsmon -s. From the output, check the server address line. Select the appropriate step: If the server address line has a value the server address line does not have a value 4 Then step 5 step 4
2 3
Check the consistency of the set of provisioned area addresses at the OPC, the network element that houses the OPC, and any other network elements connected through control network (CNET). If all area addresses are consistent, then the problem is not related to area addresses. Call Nortel Networks support. Log in to the network element. (Example of a log in data string is: nelogin -a 39840+8000000000000000000000755039EB01 Check that this intermediate network element has the right set of area addresses (see Appendix B: Area address administration or the applicable provisioning procedures NTPs for product specific details on provisioning steps). Perform a routes/rib/RTRV-RTG-TBL command and verify that the target node is in the list of nodes. Select the appropriate step: If the target node is in the list of nodes is not in the list of nodes
continued
5 6
7 8
Then step 9 step 12
6-4 Trouble clearing Procedure 6-1 (continued) Trouble clearing within the Level 1 area Step 9 10 Action Perform a connection-less PING to the target node. Select the appropriate step: If the PING works the PING fails 11 12 13 14 Then step 11 step 12
The original loss of association or rlogin problem may not be related to multiple routing areas. Call Nortel Networks support. Check the network diagram and identify the node that is the closest to the target node (call this the neighbor node). Perform rlogin to the neighbor node. Select the appropriate step: If the rlogin to the neighbor node fails the rlogin to the neighbor node is successful Then step 15 step 16
15
Check the network diagram and select a neighbor of the neighbor node (such that the new neighbor is closer to the node we are logged in at this step). In this case the old neighbor node becomes the target node and the new neighbor will be considered as the neighbor node. Go to step 8. At the neighboring node: a. Look for data communications alarms, warnings, and logs and use the corresponding NTP documentation to clear the fault(s). b. Verify that the DCC port connecting this neighbor to the target node is in the UP state and that data is being transmitted and received over this channel (see Appendices B-E for product specific details of this provisioning step). c. Check the set of area addresses. d. Look for the target node in the output of the routes/ribs command.
continued
16
Trouble clearing 6-5 Procedure 6-1 (continued) Trouble clearing within the Level 1 area Step Action e. If the target is in the list of nodes, then PING it. If the PING works, the original problem may not be a routing problem, contact Nortel Networks support. If the PING does not work, then a site visit to the current target node will be necessary in order to access the target node locally. Once connected locally verify that the set of area addresses of the target node is consistent. If the area addresses are consistent, the problem may not be related to routing. Call Nortel Networks support. f. If the target node is not in the list of nodes, check the set of area addresses provisioned at the target node and correct inconsistencies. If the area addresses are consistent, the problem may not be related to routing, call Nortel Networks support.
17
The target node is now free of communication problems: if this is the original target node, then the communication problem(s) has been solved, if this was one of the neighbors of the original target node, then repeat step 8 through step 16.
end
6-6 Trouble clearing Figure 6-1 Local area troubleclearing procedure

OTP2092p
Local area trouble shooting procedure
Login to first NE/OPC Try to check the connectivity between the OPC and the NE that routes packets for the OPC. If problem is between the OPC and the mentioned NE, one should concentrate on this part of the network. Otherwise, should login to the mentioned NE.
Is first node an OPC?
Yes
No
Check problems that may lie between this NE and the target NE.
Problem found? No
End Yes
Check for problems between this NE (that we are logged into) and a neighbour of the target NE that is on the shortest path between this and target NE.
Check for problems between the target NE and the neighbour NE.
Problem found? No Deal with problems on the target or neighbour NEs.
Yes
Make the neighbour as the target NE.
End
Trouble clearing 6-7
Procedure 6-2 Trouble clearing across Level 1 areas

Indications
Typically, a routing problem to a remote node located in another routing area is observed when trying to do a remote login. Resolving the remote login problem can be divided into three smaller steps: verifying connectivity from the local node to the Level 2 router of the local area verifying connectivity from the local area's Level 2 router to the Level 2 router of the target node verifying connectivity from the Level 2 router of the target area to the target node
Possible causes
A loss of association problem in a local area may often be caused by the misprovisioning of an area address on a network element. Refer to the applicable NTPs for area address provisioning on a particular product. A high level flow chart of this debugging procedure is shown in Figure 6-2 Trouble clearing procedure for across areas data communication problems.
continued
6-8 Trouble clearing Procedure 6-2 (continued) Trouble clearing across Level 1 areas
Actions
Step Action
Verify the connectivity from the local node to the Level 2 router of the local area.
1 Verify that the local node has the right set of area addresses.
Note 1: Area address misprovisioning is a common cause of data communications problems. Since area addresses must be entered as a string of a maximum of 26 characters (often comprised of several zeros), it is common to make an error when entering a new area address. Verify that all area address have been properly provisioned.
2 From the local node, perform a routes/rib and verify that all nodes in the local area that are provisioned to function as Level 2 routers are included in the local node's routes/rib output. Select the appropriate step: If Then
there are discrepancies between the planned Level 2 step 4 routers and those perceived by the local node there are no discrepancies between the planned Level end of procedure 2 routers and those perceived by the local node 4 There may be a provisioning problem. The provisioning problem may be on the affected Level 2 router, or in one of the nodes located between the local node and the affected Level 2 router. To fix the problem in the local area, follow these steps: a. Get local access to the affected Level 2 router. Once connected locally, perform a rib and verify that the initial local node is visible. If local node is visible, PING the initial node and if successful, go to step 5. Otherwise, the problem is most probably in the local area, go to step b. b. Rlogin from the original node to the first neighboring node that is on the shortest path to the Level 2 router. If the rlogin session along the shortest path to the Level 2 router fails, rlogin to the closest reachable node and verify the following: Check that there are no data communications related alarms, warnings, and logs. Clear any alarms and warnings before proceeding. Check the set of area addresses at this intermediate node. If the set of area addresses is consistent with the planned set, the problem may not be routing dependent, call Nortel Networks support. Otherwise, correct the area address provisioning. End of procedure.
continued
Trouble clearing 6-9 Procedure 6-2 (continued) Trouble clearing across Level 1 areas Step Action
Verify the connectivity from the local area's Level 2 router to the Level 2 router of the target node
5 At this stage, the problem is deemed to be outside of the local area. From the local node, login to each of the Level 2 routers of the local area in turn. At each Level 2 router network element, perform a rib command and verify that the entire set of visible Level 2 routers is consistent with the planned set. If there are any missing Level 2 routers, then a site visit to the missing Level 2 network element must be made to check the area address and other data communication port provisioning. If all area address provisioning is consistent, then the problem will need further investigation by Nortel Networks support. Call Nortel Networks support. At each Level 2 router, perform a PING to verify that all Level 2 router network elements are reachable. If there are any Level 2 network elements not reachable, then the investigation should concentrate on the affected Level 2 network elements. In such a case, a site visit may have to be made to check the area address and other data communications provisioning of each affected Level 2 network element. If all area address provisioning is consistent, then the problem will need further investigation by Nortel Networks support. Call Nortel Networks support.
Verify the connectivity from the Level 2 router of the target area to the target node
6 If all Level 2 network elements are reachable from all Level 2 routers of the local area, the user will have to rlogin to each Level 2 network element (not in the local area) to determine which one serves as the target node. If the Level 2 router serving as the target node is known, rlogin to that Level 2 router directly. If the Level 2 router serving as the target node is not known, rlogin to each Level 2 router and do the following: Perform a routes/rib and check to see if the target node is listed. If target node is not in the list, try another Level 2 router network element. If the target node is found at one of the Level 2 router network elements, then try to PING the node. If PING fails, then an iterative process is needed to narrow down the scope. The iterative process will involve doing PINGs to nodes on the shortest path to the target node. When the farthest node to which PING fails is found, do the following: Rlog in to the node that could not be logged in to and check the area addresses and communications provisioning, alarms, warnings, and logs. After addressing all the mentioned factors, if problem still resolved, call Nortel Networks support. If none of the Level 2 routers have the target node in the routes/rib, then call Nortel Networks support.
continued
6-10 Trouble clearing Procedure 6-2 (continued) Trouble clearing across Level 1 areas Step 7 Action If this was the last check in the area: if all the communication problems have been resolved the procedure is complete for this area, therefore select another area and consider it the current area, otherwise if the communications problems persists, call Nortel Networks support.
end
Trouble clearing 6-11 Figure 6-2 Trouble clearing procedure for across areas data communication problems
OTP2093p
Across areas trouble shooting procedure
Login to first NE/OPC
Check the provisioned area address of the local node.
Check to see if there are connectivity problems between this NE and any if the L2 routers in the
Problem in local area? No
Yes
Fix L2 router connectivity problem in the local area. Run the "Local area trouble shooting procedure" if necessary.
Check L2 connectivity between each L2 router of the local area and all other L2 routers in other areas.
No
Original problem solved?
Yes End
L2 routing problem?
No
Check all the NEs that are to act as L2 router. If all area address and other provisioning are OK. Contact NT support for additional trouble shooting.
Yes Login to one of the L2 routers of the current area. See if the target NE is in the RIB of this NE. No Original problem solved? Yes
End
Target NE there No
Yes
Local area trouble shooting procedure
If this was the last area check, then call NT support. Else, select another area and consider it as the current area.
End
6-12 Trouble clearing
7-1
Appendix A: Physical interfaces

Operations controller (OPC)
7-
There are two types of OPCs: the Legacy OPC, which manages the S/DMS TransportNode OC-48, S/DMS TransportNode OC-12 TBM and Access Node network elements, and the partitioned OPC, which manages the S/DMS TransportNode OC-192, OPTera Connect DX and OPTera Long Haul 1600 family of network elements. The data communications physical interfaces supported are listed in Table 7-1 and Table 7-2.
Table 7-1 Physical data communications interfaces on the Legacy OPC Interface CNET 0 Description Internal CNET port for connecting the OPC to OC48 or S/DMS TransportNode OC-12 TBM Shelf Processor residing on the same shelf as the OPC For connecting to external OS via Q3, or connecting to Preside via TCP/IP. At any time, a maximum of one of the RS-232 ports can be configured to act as an X.25 interface. Each port supports DTE up to 19200 baud rate. The recommended X.25 port is Port B.
Ethernet (RJ45) Three RS-232 ports
Table 7-2 Physical data communications interfaces on the partitioned OPC (POPC-1 card) Interface lan1 Description Internal Ethernet port for connecting the OPC to the S/DMS TransportNode OC-192/OPTera connect DX/OPTera Long Haul 1600 Shelf Processor (SP) residing on the same shelf. For connecting to external OS via Q3, or connecting to Preside via TCP/IP. Supports DTE up to 19200 baud rate.
lan0 (9 pin 10BaseT) one RS-232 port
7-2 Appendix A: Physical interfaces
OPTera Metro 3000 network element

The physical data communications interface supported on the OPTera Metro 3000 is shown in Table 7-3, and Table 7-4.
Table 7-3 Physical data communications interface on the network processor (NP) of OPTera Metro 3000 Interface 1 X.25 port ILAN-1(RJ45), ILAN-2 (RJ45) ILAN-SP ILAN-NP CO-LAN Ethernet port for TL1 messaging over TCP/IP. Description For connecting to OS for Transaction Language 1 (TL1) messaging. The port supports data terminal equipment (DTE) up to 19200 baud. External Ethernet ports to connect to other SPs or NPs for OSI communication Backplane Ethernet ports for connecting to other SPs and NPs
Table 7-4 Physical data communications interfaces on SP of OPTera Metro 3000 Interface 10 SDCC ports ILAN-NP Description For communication with remote SONET network elements over the fiber. Backplane Ethernet port for connecting to NP as well as ILAN-1, ILAN-2
S/DMS TransportNode OC-12 TBM network element

The data communication physical interface supported by S/DMS TransportNode OC-12 TBM network element is shown in Table 7-5.
Table 7-5 Physical data communication interface on the S/DMS TransportNode OC-12 TBM network element Interface 2 CNet port 10 SDCC ports Description For connecting to other co-located S/DMS TransportNode OC-48 network element or the OPC. For communication with remote SONET network elements over the fiber.
Appendix A: Physical interfaces 7-3
S/DMS TransportNode OC-48 network element

Depending on the type of Shelf Processor deployed, different data communications interfaces are offered by Nortel Networks family of S/DMS TransportNode OC-48 network elements. This is detailed in Table 7-6.
Table 7-6 Physical data communications interfaces on S/DMS TransportNode OC-48 network element Shelf Processor Type NT7E20CC, NT7E20CD 2 CNET port Interface 2 SDCC LAPD ports Description For communication with remote SONET network elements over the fiber. For connecting to other collocated S/DMS TransportNode OC-48, S/DMS TransportNode OC-12 TBM network elements or an OPC. For communication with remote SONET network elements over the fiber. For connecting to other collocated S/DMS TransportNode OC-48, S/DMS TransportNode OC-12 TBM network elements or an OPC.
NT7E20GB
10 SDCC LAPD ports 2 CNET port
S/DMS TransportNode OC-48 Lite Multiplexer network element

There are two physical data communications interfaces offered by Nortel Networks S/DMS TransportNode OC-48 Lite Multiplexer network elements. This is detailed in Table 7-7.
Table 7-7 Physical data communications interfaces on S/DMS TransportNode OC-48 Lite Multiplexer network element Interface Ethernet (RJ45) Description Supports Telnet TL1 over Telnet and FTP via TCP/IP one RS-232 port Supports DTE up to 19200 baud rate.
S/DMS TransportNode OC-192 network element and OPTera Long Haul 1600
The data communications physical interfaces supported by S/DMS TransportNode OC-192 and OPTera Long Haul 1600 network elements is shown in Table 7-8.
Table 7-8 Physical data communications interfaces on the S/DMS TransportNode OC-192/OPTera Long Haul 1600 network element Interface Ethernet hub with 3 ports (9-pin 10BaseT) SDCC Description For connecting to other collocated S/DMS TransportNode OC-192 network elements, an OPC or S/DMS TransportNode OC-48 network elements which supports Ethernet interface. For communication with remote SONET network elements over the fiber. SDCC is terminated on the port cards, and is only limited by the number of such port cards supported by the software release deployed. For communication with remote SONET network elements over the fiber. LDCC is terminated on the S/DMS TransportNode OC-192 port cards, and is only limited by the number of such port cards supported by the software release deployed For communication with remote WDM network elements over the fiber. optical service channel (OSC) is terminated on the MOR/MOR plus cards and OSC circuit pack on 1600G Amplifier, and is only limited by the number of such port circuit packs supported by the software release deployed.
LDCC
OSC
Appendix A: Physical interfaces 7-5
OPTera Connect DX
The data communications physical interfaces supported by OPTera Connect DX is shown in Table 7-9.
Table 7-9 Physical data communications interfaces on the OPTera Connect DX Interface Ethernet hub with 3 ports (9-pin 10BaseT) SDCC Description For connecting to other collocated S/DMS TransportNode OC-192 network elements, an OPC or S/DMS TransportNode OC-48 network elements which supports Ethernet interface. For communication with remote SONET network elements over the fiber. SDCC is terminated on the port cards, and is only limited by the number of such port cards supported by the software release deployed. For communication with remote SONET network elements over the fiber. LDCC is terminated on the OC-192 port cards, and is only limited by the number of such port cards supported by the software release deployed
LDCC
Access Node
The data communication physical interfaces supported on the Access Node are shown in Table 7-10.
Table 7-10 Physical data communications interfaces on the Access Node Interface 1 CNET port Description For connecting to other co-located S/DMS TransportNode OC-48, S/DMS TransportNode OC-12 TBM network elements or the OPC.
3 SDCC ports (1 main OC-3 optical For communication with remote SONET network elements over link plus 2 OC-3 tributary links) the fiber.
8-1
Appendix B: Area address administration
8-
The management of the routing domain (RD) and AREA portion of the address is the responsibility of the service provider. Service providers can devise a policy that best fits their needs. There are many ways to use the RD and AREA fields of the network service access point (NSAP). These fields can be used to further sub-divide all the networks owned by the provider into smaller administrative domains. For instance, one can encode RD and AREA to represent the geographic location of where the network is located or the administrative group that administers that portion of the network. The following examples will demonstrate how the different fields in the International Organization for Standards (ISO) data communications channel (DCC) NSAP format are used. All the examples below apply to the United States. There are a number of fields with values that are already pre-defined by standards bodies. We will briefly cover them first and then examine the fields that a service provider has to manage internally. Each example will refer to a network operator, called X, who operates a number of SONET networks in the United States. X is going to assign ISO DCC format addresses to the network elements. The portion of the address that X has to assign is the area address portion. The vendor already assigns the System ID portion of the address, so X does not have to worry about assigning the System ID. There are also a number of fields in the address that are pre-specified, such that all that X has to do is to fill them in. The specified Authority and Format Identifier (AFI) value for ISO DCC NSAP is 39. Since X operates in the United States, the data country code for United State should be filled into the Initial Domain Identifier (IDI) portion of the IDI. The country code for U.S.A is 840.
8-2 Appendix B: Area address administration
The NSAP used by X may look like Figure 8-1.

Figure 8-1 Example of NSAP
OTP2166p
IDP Area Address AFI 39 IDI 840 + DFI 80 ?
DSP Org ID ? ? Res 00 00 RD ? ? Area ? ? System ID Sel
<assigned by vendor>
00
The standards body in the United States for administrating the domain specific part (DSP) potion of OSI address is American National Standards Institute (ANSI). ANSI broke down the DSP into a number of fields. The first DSP field in an ISO DCC format address is the DSP Format Identifier (DFI). ANSI specified the value 80 (hex) for use in SONET. Since the value of this field is fixed, X just has to fill it in. The second field is the three bytes long Org ID field. The next two bytes following OrgID are reserved, so they should be filled with zeros. To ensure interoperability, X should obtain an OrgID from ANSI. In the following example, ANSI has assigned an OrgID of 11-22-33 to X. Now X can fill in the OrgID field, illustrated in Figure 8-2:
Figure 8-2 Example of NSAP with Org ID field assigned
OTP2167p
IDP Area Address AFI 39 IDI 840 + DFI 80
DSP Org ID 11 22 33 Res 00 00 RD ? ? Area ? ? System ID Sel
00
The remaining fields X has to complete are the Routing Domain (RD) and AREA fields. The administrative responsibility of these two fields lies with X. For the rest of the examples, we will focus on how these two fields can be used. Each of these fields is two bytes long. Please refer to Chapter 3 OSI data communications of this document for additional details about assigning NSAP addresses.
Appendix B: Area address administration 8-3
Assigning RD and AREA according to geographic code

X can administer its network addresses based on geographic location of the network elements. X is going to split up its network into domains based on geographic regions. X can therefore assign a code to RD to represent a location where the network is located. A state, city or a telephone area code calling region can bound a geographic region. X can either devise a proprietary method for representing geographic regions or it can use the telephone area code as a representation. Either method is acceptable, as long as it can satisfy administrative requirements. Here, X chooses to use the telephone area code to represent a region. The three digit area code can easily fit into the two bytes space (4 hex digits) of the RD field. For example, for area code 512, network elements in this region can be assigned with RD=0512.
Figure 8-3 Example of NSAP with RD field assigned
OTP2168p
DSP Org ID 11 22 33 Res 00 00 RD 05 12 Area ? ? System ID Sel
00
It is probable that within each domain, the operator has to further sub-divide the region. The AREA field can then be used to represent these sub-regions within a domain. This method may work quite well with short-haul networks that are contained in a relatively localized region. This method may not work well with long-haul networks.
Assigning RD and AREA according to administrative groups or departments

As another example, in X's organization, a number of departments manage the entire network. Each of these departments may only manage a portion of the network. In such a case, we can define each portion as a domain. Each department can obtain a unique RD value for the domain that it manages. A planning group within X gives out this RD value so that uniqueness can be guaranteed within the organization. Within each department, it manages a number of network clusters. These clusters can be assigned with individual values for the AREA field. This RD and AREA administration method follows the administrative landscape instead of geographic landscape. The advantage is obvious when there are networks that span many geographic regions.
Assigning RD and AREA according to network routes or network names

Another method for administering RD and AREA fields is to assign RD and AREA based on the route the network takes or the name of the network. This idea is similar to interstate highway numbering. First of all, all backbone networks are identified. An RD value can be assigned to each backbone and all its respective tributaries. The backbone can be assigned into one area, call it AREA 0000. Tributary networks connected to a backbone will be in the same domain but they can be assigned with an individual AREA. Let's say X has two main groups of long-haul backbone network across the United States. One group runs across the country in the east-west direction and the other one runs north-south. East and westbound networks can be assigned with even numbers for the RD, while odd numbers can be assigned to north-south bound networks. Tributary networks connected to each of these backbones can be grouped in areas by assigning each one of them an AREA value (see Figure 8-6 Assigning RD and AREA to a network). The whole network (backbone and tributaries) are given one RD value, in this example, RD=0007. The backbone network is assigned with AREA = 0000. Each tributary network is also assigned unique AREA values, say from 0001. For this example, the network elements in the backbone will have NSAPs that look like Figure 8-4.
Figure 8-4 Example of NSAP with Area field assigned
OTP2169p
DSP Org ID 11 22 33 Res 00 00 RD 00 07 Area 00 00 System ID Sel
00
A network element on the tributary network, say, number 5, may have an NSAP that appears as Figure 8-5.
Figure 8-5 Example of a NSAP with the fields assigned
OTP2170p
DSP Org ID 11 22 33 Res 00 00 RD 00 07 Area 00 05 System ID Sel
00
Appendix B: Area address administration 8-5 Figure 8-6 Assigning RD and AREA to a network
OTP2077p.eps
Domain, RD = 0007
Network route #7
Tributary AREA = 0005
Backbone AREA = 0000
- Backbone network, AREA = 0000 - Tributary network, AREA > 0
Assigning RD and AREA according to Preside regions

In this example, X wishes to administer its network addresses based on Preside controlled regions. Preside workstations are capable of controlling up to 10 000 network elements. It is therefore capable of supporting a large number of Level 1 areas. X may want to assign a particular segment of the RD and AREA to any particular Preside workstation. For example, if X wanted to have about 100 network elements per Level 1 area, then a Preside workstation could support 100 Level 1 areas. Therefore, each Preside workstation could be assigned an RD and AREA combination that represents a block of 100 Level 1 areas (example: RD=0000, AREA=0000 to RD=0000, AREA=0064). This method will work quite well for networks that are very large. Each Preside workstation can represent and monitor a Level 2 area, which can contain up to 150 Level 1 areas (the maximum for the number of Level 2 routers supported within a network). If the network grows, additional Preside stations can be added and additional Level 2 areas can be created. So as not to exceed the 150 Level 2 router limit, it is important that the Level 2 routers do not have direct connectivity between Level 2 areas.
9-1
Appendix C: Data communications tools

Listnodes
9-
The following section lists the available data communications tools and state how they are used in the context of Level 2 routing.
Nortel Networks SONET network elements use a proprietary directory service protocol, Network Name Service (NNS), to distribute information such as network element ID and network element name in the network. The listnodes tool uses the NNS in order to display a list of the Nortel Networks nodes within the Level 1 area along with their associated network element IDs and names. The only exception is the OPTera Metro 3000 SP/NP that only shows the NNS entry of the node you are logged in to. Since NNS is designed to work within a Level 1 area, with inclusion of Level 2 routing functionality, listnodes will be limited to list nodes in the local Level 1 area as opposed to the entire routing domain. Table 9-1 includes NTP references for this tool.
Table 9-1 Listnodes tool NTP reference Network element type OPtera Long Haul 1600 OPTera Connect DX OPTera Metro 3000 TransportNode OC-12 TBM S/DMS TransportNode OC-48 NTP 323-1801-195 323-1501-195 323-1051-302 323-1111-301 323-1201-846 323-1201-222 S/DMS TransportNode OC-48 Lite Multiplexer S/DMS TransportNode OC-192 323-1231-310 323-1301-195
9-2 Appendix C: Data communications tools
The information included in the above table is based on the NTP releases that are available at the time of writing. The corresponding information will also exist in the NTPs of the baseline software release as listed in Table 9-1. A sample output of the listnodes tool on S/DMS TransportNode OC-192, OPTera Connect DX and OPTera Long Haul 1600 is shown in Figure 9-1.
Figure 9-1 Sample output of the listnodes tool on S/DMS TransportNode OC-192, OPTera Connect DX and OPTera Long Haul 1600
OTP2112p
> listnodes Name OPC1613p Ottawa Montreal Toronto Type OPC NE NE NE ID 1.1.1 1.1.1613 1.1.1614 1.1.1615 Eqptype Primary OC-192 OC-192 OC-192 Status Active
The NE or OPC name
The Node type
The NE or OPC ID
The equipment type of the node
OPC status (if the node is an OPC)
Routes/Rib tool
The routes/rib tools provides a display of the Level 1 routing information base from a given network element. Such information includes: network element ID, name, or system ID of nodes reachable in the local routing area routing cost of reaching nodes in the routing area type of nodes (ES, L1IS, L2IS) in the routing area in OC-192 network elements, the route via information to indicate which link layer port shall be used to reach a given node in the local area as well as the system ID and /or network element ID of the node next to the target node for OC-48/OC-12 TBM network elements, the set of the computed area addresses for OC-48/OC-12 TBM network elements, the summary of number of nodes categorized by routing functionality (i.e. ES, L1IS, and L2IS) A sample output of the rib tool is shown in Figure 9-2.
Appendix C: Data communications tools 9-3 Figure 9-2 Sample output of 'rib' command
OTP2987p
>rib <optional: sysid> NEID 1.1.1 NE Name Ottawa_NE4 Cost 10 Type L1IS
The NE number. An OPC is given the number '1'.
The NE's Name. If you use 'rib sysid' or there is no name then the system ID is provided instead.
The "cost" to get to that node.
The type of nodeL1IS: level 1 Intermediate system L2IS: level 2 Intermediate system ES: End system
NTP references for the routes/rib tool are listed in Table 9-2. Note that OPTera Metro 3000 products have the Transaction Language 1 (TL1) command RTRV-RTG-TBL to retrieve the routing information base.
Table 9-2 NTP references for routes/rib Network element type OPTera Metro 3000 NTP 323-1051-190T 323-1051-190 RTRV-RTG-TBL 323-1111-310 323-1201-222 323-1301-195 323-1801-195 323-1501-195
S/DMS TransportNode OC-12 TBM S/DMS TransportNode OC-48 S/DMS TransportNode OC-192 OPTera Long Haul 1600 OPTera Connect DX
Level 2 routers The S/DMS TransportNode OC-192, OPTera Connect DX and OPTera Long Haul 1600 may be provisioned to act as Level 2 routers. As a result, the rib tool will allow a parameter to specify that the Level 2 routing information is to be displayed. The information included in the 'rib 2' output will include a list of area addresses of the connected Level 1 areas. A sample output of the 'rib 2' tool is shown in Figure 9-3.
9-4 Appendix C: Data communications tools Figure 9-3 Sample output of 'rib 2' command
OTP2986p
> rib 2 <optional: sysid> Area Route Database NEID 1.1.2427 Area Address 39840+8011223300001122 NE Name NE 151 Cost 6 Route D1 - D3 Via (slot 17)
NE ID is the NE number.
The area address being advertised by that NE.
The NE name. If you use 'rib 2 sysid' or there is no name then the System ID is provided instead.
The "cost" to get to that node
What route is being used to get to that node. D1 - D3: SDCC D4 - D12: LDCC
Slot XX: h/w slot that DCC is using. Ethernet: over ethernet port
For S/DMS TransportNode OC-12 TBM and S/DMS TransportNode OC-48 the routes tool has not changed, as these products do not function as a Level 2 router. The co-existence of TransportNode OC-12 TBM, S/DMS TransportNode OC-48 with Level 2 routers will yield the following changes in the output of the routes CI: which network elements in the network are Level 2 routers (if any) the count of the number of Level 2 routers within this Level 1 area Similarly, since OPTera Metro 3000 network elements will not function as Level 2 routers, the response to the RTRV-RTG-TBL TL1 command will not be impacted.
nnsmon/nnsfmon
The nnsmon (network name service monitor) tool, and its menu driven version nnsfmon, are both invoked from the operations controller (OPC). The nnsmon tool is used to monitor all routing information maintained in the network. list network name service protocol's status and statistics information print out the data in routing database list all network-wide reachable node names and related addresses check the validity of routing database
Appendix C: Data communications tools 9-5
It is a useful tool to help the user to get a view of network-wide connectivity and troubleshoot the communication problem between network nodes. Note that new entries are added immediately and non-available entries are removed in 20 minutes. nnsmon
opc> nnsmon [-s | -r | -d | -D | -l | -L | -H <aec> | -c | -h] where: -s -r -d -D -l -L -H Print status and statistics. Reset the statistics Print the database. Print the database, showing internal information. Print the entry for the local node. Print the entry for the local node, showing internal information Print a hash table: a - addresses e - equipment names c - character names -c -h Calculate and print database checksums. Print this message
nnsfmon
opc> nnsfmon
The following menu appears: Network Name Service Monitor -- Main Menu
where: srdDHctuqDisplay Status and Statistics Reset Statistics Display Database Display Database with internal information Display Hash Table... Calculate and Display Database Checksums Enable Tracing... Set Update Interval Quit
tstatc
The tstatc tool displays OPC communications information and is invoked from the OPC.
opc> tstatc
The tstatc tool is a program that continuously displays statistics and configuration variables for OSI protocols implemented inside the HP-UX kernel. There are a number of displays that may be chosen from the main menu. These displays provide statistics on the socket layer, transport layer, network layer, Ethernet and CNET layer, as well as X.25. It be used for diagnosing lower layer data communications problems. A main menu screen is displayed when tstatc is invoked. From this screen, one can navigate through all the information screens.
Remote login (rlogin, selectNE)

The remote login tool is similar to the telnet tool in the TCP/IP world where a terminal session is provided to a remote node. Table 9-3 shows the NTP references for the rlogin tool.
Table 9-3 NTP reference for the rlogin tool Network element type OPTera Metro 3000 TransportNode OC-12 TBM S/DMS TransportNode OC-48 S/DMS TransportNode OC-192 OPTera Long Haul 1600 OPTera Connect DX NTP section 323-1051-302 323-1111-846 323-1201-846 323-1301-195 323-1801-195 323-1501-195
The parameter to this tool is one of the remote network elements network service access point (NSAP) address, its NE ID, or its network elements name. The NE ID and NE name parameters are much more user friendly and are the most widely used forms of input to this tool. The NSAP address parameter can be used in cases where the NE ID or NE name is not known and is used as follows:
> rlogin 'addr NSAPaddress'
where: NSAP address is the NSAP address of the network element you are rlogin to.
Example:
rlogin 'addr 39840+800000000000000000000000755004A600'
Rlogin across Level 2 boundaries using an NSAP address is supported. Enhancements to support rlogin across Level 2 boundaries using the network element ID/name parameter will also be provided. For more information about the software release baselines that provide this functionality, refer to Table 10-1 in Appendix D: Software release baseline. The selectNE (NTP: 323-1111-846, 323-1201-846) functionality of TransportNode OC-12 TBM and S/DMS TransportNode OC-48 MAPCI is not affected by Level 2 routing as selectNE functionality has been designed to reach network elements within the same span of control which is always contained within a single Level 1 area.
Preside Site Manager reach-through

Nortel Networks nodal user interface Site Manager provides a reach-through functionality that is similar to rlogin from the data communications viewpoint. Since the underlying mechanisms used by both Site Manager and remote login are the same, the limitations outlined previously apply. In short, when locally connected to an OC-12 TBM or OC-48 network element, it will be possible to reach-through remotely to an OPTera Metro 3000, S/DMS TransportNode OC-12 TBM, S/DMS TransportNode OC-48, or OPC in a different area as long as the target network element/OPC supports Site Manager.
PING
Connection-oriented or connectionless-oriented PING tools are used to discover if there is a communication path to a given node. The tools are available on network elements and OPCs. The PING tools use the same input parameters as rlogin for specifying the destination node. The same enhancements that apply to rlogin must apply to the PING tool for the products that support it i.e. one will be able to PING another node in a different area by specifying the target node by OSI address, network element ID, or network element name. Between the connectionless-oriented and connection-oriented PING tools, it is recommended to use the connection less first, as it will serve the purpose of testing network layer connectivity. The syntax of the connection less ping on S/DMS TransportNode OC-12 TBM and S/DMS TransportNode OC-48 is:
clping 'ne <NE ID>' <num_packets> clping '<NE/OPC name>' <num_packets>
Example:
clping 'ne 48914' 10 clping 'OPCM159P' 10
The syntax of the connection-oriented PING on S/DMS TransportNode OC-12 TBM and S/DMS TransportNode OC-48 is:
coping 'ne <NE ID>' n<num_packets> coping '<NE/OPC name>' n<num_packets>
Example:
coping 'ne 48914' n10 coping 'OPCM159P' n10
The connection/connectionless oriented PING on S/DMS TransportNode OC-192, OPTera Connect DX and OPTera Long Haul 1600 is known as TARP_PING. The syntax of TARP_PING on S/DMS TransportNode OC-192, OPTera Connect DX and OPTera Long Haul 1600 is:
TARP_PING <t|n> <address> [-i <msgs TypeV>] [-r <msec>] [-t <msec>]
where: -t -n -address -i -r - TID address type; - NSAP or SystemID address type; - character string representing remote NE (TID, NSAP, SystemID); - iterations, i.e. number of TARP Type V messages to be transmitted, default = 1; - rate, i.e. requests are sent at a rate: one every given number of milliseconds, range[0 to 180000], default = lock-step mode, i.e. wait for response before sending next request; - time-out(msec), i.e. max. time to wait for a response to each echo request, range[0 to 180000], default = 1500 msec.
-t
Example:
tarp_ping t 1616
In the above example, the target node is identified by its network element ID (1616) which is obtained from the 'listnodes' command.
The connection/connectionless oriented PING on OPC (known as OSIPING) may be invoked from a UNIX shell on OPC. The syntax of OSIPING on OPC is:
osiping [<network address>] [-stream] [-n num_packets]
Example:
osiping 39840+800000000000000000000000755004A600 -n 10
In the above example, the target node is identified by a network address which is obtained from the output of 'nnsmon -d'. The 'nnsmon' tool on OPC provides the equivalent of listnodes on the network element.
10-1
Appendix D: Software release baseline
10-
Table 10-1 demonstrates the product software release baseline for Level 2 routing. Full Level 1 functionality refers to a network element recognizing and utilizing a Level 2 router within its Level 1 area. Remote login is supported with network element name and network element ID.
Table 10-1 Product release baseline functionality Product Full Level 1 (Level 2 usage) Release 7 Release 1 Release 5 Release 16.1 Release 1 Release 14 Release 4 Release 19 Remote login using network element ID (see Note) Release 5 Release 1 Release 5 Release 16.1 TBD Release 14 Release 6 Release 19 Level 2 Routing
S/DMS TransportNode OC-192 OPTera Connect DX OPTera Long Haul 1600 S/DMS TransportNode OC-48 S/DMS TransportNode OC-48 Lite Multiplexer S/DMS TransportNode OC-12 TBM OPTera Metro 3000 Access Node
Release 7.0 Release 1 Release 5 TBD TBD TBD TBD Release 19
Note: This is for rlogin across different Level 1 areas. The rlogin functionality within a Level 1 area is supported via network element ID and network element name.
10-2 Appendix D: Software release baseline
Table 10-2 summarizes the software capabilities required to support the deployment of a Level 2 routing network.
Table 10-2 Software capabilities for Level 2 routing Plan of Record Product S/DMS TransportNode OC-192 OPTera Connect DX OPTera Long Haul S/DMS TransportNode OC-48 S/DMS TransportNode OC-48 Lite Multiplexer S/DMS TransportNode OC-12 TBM OPTera Metro 3000 Access Node Area Address Provisioning Support Release 3 Release 1 Release 5 Release 11 Release 1 Release 13 Release 3 Release 19 Operate in non 49+0000 area Release 7 Release 1 Release 5 Release 16.1 (see Note) Release 1 Release 14 Release 4 Release 19
Note: This release requires an S/DMS TransportNode OC-48 shelf processor other than NT7E20CC.
11-1
Index
A
access node 7-5 AFI. See authority and format identifier area address administration 8-1 assigning RD and AREA according to administrative groups or departments 8-3 assigning RD and AREA according to geographic code 8-3 assigning RD and AREA according to network routes or network name 8-4 assigning RD and AREA according to Preside regions 8-5 authority and format identifier 3-8
11line DCC 2-5 Optical Service Channel 2-5 section DCC 2-5 SONET 2-4 data communication paths 2-1 external 2-4 internal 2-2 path selection 2-14 data communication tools 9-1 Level 2 routers 9-3 Listnodes 9-1 nnsmon/nnsfmon 9-4 PING 9-7 Preside site manager reach-through 9-7 remote login 9-6 routes/rib tool 9-2 tstatc 9-6 data communication transmission 1-4 data communications network Common Management Information Service Element 1-2 data communication transmission 1-4 network element-to-network element communication 1-6 NP-to-network element communication 1-6 OPC-to-network element communication 1-6 Preside-to-MOA/NP communication 1-5 Preside-to-OPC communication 1-4 OAM&P 1-2 Operations Support System 1-2 span of control 1-1 data communications network applications 5-1
C
CAA. See computed area address sets CLNP. See connectionless-mode network service protocol CMISE. See Common Management Information Service Element CNet rules 2-12 CNet. See control network combining a Level 1 area 4-16 Common Management Information Service Element 1-2 computed area address sets 3-18 connectionless-mode network service protocol 3-22 control network 2-12 CRC. See cyclic redundancy check cyclic redundancy check 3-20
D
data communication channels
11-2 Index
establishing communication between DCC island 5-5 multi-vendor interoperability 5-33 OAM&P traffic on shared DCC paths 5-1 supporting push button equalization 5-19 Unified SOC and OPTera Connect DX 4-Fiber ADM network element 5-15 data communications network planning 4-1 combining a Level 1 area 4-16 Level 2 routing checklist 4-11 Nortel Networks area address 4-8 S/DMS TransportNode OC-48 Shelf Processor dependencies 4-10 span of control considerations 4-1 splitting a Level 1 area 4-12 DCC terminating transmitters 5-21 dense regenerators 5-9 domain specific part 3-8 DSP. See domain specific part
L
LAN link 2-8 LAN. See local area network LAPD. See link access procedure on the D-channel protocol LDCC. See line data communication channels Level 1 routing 3-5 Level 2 routing 3-5 Level 2 routing checklist 4-11 line data communication channels 2-5 line DCC 2-5 link access procedure on the D-channel protocol 3-19 link state packets 3-12 link state protocol data units 3-33 Listnodes 9-1 LLC. See logical link control protocol local area network 2-8 logical link control protocol 3-21 LSP. See link state packets LSPs. See network name service
E
establishing communication between DCC island 5-5 nested ring 5-12 network with amplifiers or dense regenerators 5-9 stacked ring 5-10 using a linear system to bridge two areas 5-5 external data communication paths 2-4 LAN link 2-4, 2-8 CNet rules 2-12 optical link 2-4 WAN link 2-4, 2-13 external data representation 1-2
M
MAA. See manual area address sets managed object agent 1-6 managed object agents 1-5 manual area address sets 3-17 MOA. See managed object agent MOA. See managed object agents multi-vendor interoperability 5-33
N
nested ring 5-12 network element-to-network element communication 1-6 network name service network service access point 3-6 network with amplifiers or dense regenerators 5-9 NNS. See network name service nnsmon/nnsfmon 9-4 Nortel Networks area address 4-8 NP-to-network element communication 1-6 NSAP structure 3-8 NSAP. See OSI network addressing
F
frame reject 3-21 FRMR. See Frame reject
I
IDI. See initial domain identifier initial domain identifier 3-8 internal data communication paths 2-2
Index 11-3
O
OAM&P 1-2 OAM&P traffic on shared DCC paths 5-1 OAM&P. See operations, administration, maintenance and provisioning OPC-to-network element communication 1-6 open system interconnection model 3-1 open systems interconnection data communications 3-1 computed area address sets 3-18 Level 1 routing 3-5 Level 2 routing 3-5 link access procedure on the D-channel protocol 3-19 manual area address sets 3-17 network name service 3-32 NSAP structure 3-8 OSI basic routing algorithm 3-12 OSI data layers protocols 3-19 OSI network addressing 3-6 OSI network layer protocol 3-22 OSI network organization 3-3 OSI reference model 3-1 routing roles 3-4 Operation Support System 1-2 Operations 7-1 operations, administration, maintenance and provisioning 1-2 OPTera Connect DX 7-5 OPTera Long Haul 1600 7-4 OPTera Metro 3000 network element 7-2 Optical Service Channel 2-5 OSC. See Optical Service Channel OSI basic routing algorithm 3-12 OSI data link layer protocol logical link control protocol 3-21 OSI data link layer protocols 3-19 OSI network addressing 3-6 OSI network layer protocol 3-22 OSI network organization 3-3 OSI. See open systems interconnection OSS. See operations support system
PBE. See push button equalization PDU. See protocol data unit physical interfaces 7-1 access node 7-5 OPTera Connect DX 7-5 OPTera Long Haul 1600 7-4 OPTera Metro 3000 network element 7-2 S/DMS TransportNode OC-12 TBM 7-2 S/DMS TransportNode OC-192 7-4 S/DMS TransportNode OC-48 7-3 S/DMS TransportNode OC-48 Lite Multiplexer 7-3 PING 9-7 Preside site manager reach-through 9-7 Preside-to-MOA/NP 1-5 Preside-to-OPC communication 1-4 protocol data unit 3-4 protocols 3-19 push button equalization 5-19
R
remote login 9-6 routes/rib tool 9-2 routing roles 3-4 protocol data unit 3-4
S
S/DMS TransportNode OC-12 TBM 7-2 S/DMS TransportNode OC-192 7-4 S/DMS TransportNode OC-48 7-3 S/DMS TransportNode OC-48 Lite Multiplexer 7-3 S/DMS TransportNode OC-48 Shelf Processor dependencies 4-10 SAPI. See service access point identifier SDCC. See section data communication channels section data communication channels 2-5 service access point identifier 3-19 software release baseline 10-1 SONET data communication channels 2-4 span of control 1-1 span of control considerations 4-1 splitting a Level 1 area 4-12 stacked ring 5-10
P
path selection 2-14 PBE communication process 5-31
11-4 Index
T
target identifier 3-22 target identifier address resolution protocol 3-29 TARP. See target identifier address resolution protocol TE. See terminal equipment terminal equipment 3-19 TID. See target identifier trouble clearing 6-1 trouble clearing across Level 1 area 6-7 trouble clearing within the Level 1 Area 6-2 tstatc 9-6
U
Unified SOC and OPTera Connect DX 4-Fiber ADM network element 5-15 using a linear system to bridge two areas 5-5
W
WAN link 2-13 WAN. See wide area network wide area network 2-13
X
XDR. See external data representation
Nortel Networks
Optical Networks
Data Communications Network Planning Guide
Copyright 20012002 Nortel Networks, All Rights Reserved The information contained herein is the property of Nortel Networks and is strictly confidential. Except as expressly authorized in writing by Nortel Networks, the holder shall keep all information contained herein confidential, shall disclose the information only to its employees with a need to know, and shall protect the information, in whole or in part, from disclosure and dissemination to third parties with the same degree of care it uses to protect its own confidential information, but with no less than reasonable care. Except as expressly authorized in writing by Nortel Networks, the holder is granted no rights to use the information contained herein. Nortel Networks, the Nortel Networks logo, the Globemark, TransportNode, OPTera and Preside are trademarks of Nortel Networks. UNIX is a trademark of X/Open Company Ltd. Telecordia is a trademark of Telecordia Technologies, Inc. NTR710AM Standard Issue 3 May 2002 Printed in Canada and in the United Kingdom

DCN

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

DCN

Diunggah oleh

Hak Cipta:

Format Tersedia

NTR710AM

Copyright 20012002 Nortel Networks, All Rights Reserved

Printed in Canada and in the United Kingdom

Data Communications Network Planning Guide NTR710AM

Issue 3 Standard May 2002

Issue 3 Standard May 2002

Data communications paths

OSI data communications

Data communications network planning

Data communications network applications

Optical Networks NTR710AM Issue 3 Standard May 2002

Appendix A: Physical interfaces

Appendix B: Area address administration

Appendix C: Data communications tools

Appendix D: Software release baseline Index

Optical Networks NTR710AM Issue 3 Standard May 2002

About this document

x About this document

Optical Networks NTR710AM Issue 3 Standard May 2002

Data communications network overview

Data communications network (DCN)

1-2 Data communications network overview

Optical Networks NTR710AM Issue 3 Standard May 2002

Data communications network overview 1-3 Figure 1-1 Management hierarchy

Network management layer

MOA Element management layer

OPTera Metro 3000

OC-192/ OPTera Connect DX/ OPTera Long Haul 1600

Network element layer

1-4 Data communications network overview

Data communication transmission

Optical Networks NTR710AM Issue 3 Standard May 2002

Printer External LAN

Note: Only the primary OPCs are shown.

1-6 Data communications network overview

centralized software management network element Backup and Restore GUI

Optical Networks NTR710AM Issue 3 Standard May 2002

Data communications paths

2-2 Data communications paths

Internal data communications paths

Optical Networks NTR710AM Issue 3 Standard May 2002

To Ethernet LAN, other NE, or OPC

To Ethernet LAN, other NE, or OPC

Serial bus (S. PEZ)

GraceLAN GraceLAN GraceLAN

2-4 Data communications paths

External data communications paths

Optical Networks NTR710AM Issue 3 Standard May 2002

Data communications paths 2-5

2-6 Data communications paths

RED BLUE 1510 OSC BLUE

Blue In/ Red Out MOR+ Pair (1510 OSC)

Red In/ Blue Out

RED 1510 OSC

1625 OSC Module

MOR+ Pair (1510 OSC)

1625 WDM coupler

Optical Networks NTR710AM Issue 3 Standard May 2002

Data communications paths 2-7

Unidirectional, 2-fiber solution OSC-1 1510 nm ADD Tx Rx OSC-2 1510 nm DROP

Legend - WDM coupler - Faceplate connector

2-8 Data communications paths