Although ONS 15454 DCN communication is based on IP, ONS 15454 nodes can be networked to equipment that is based on the Open System Interconnection (OSI) protocol suites. This chapter also describes the ONS 15454 OSI implementation and provides scenarios that show how the ONS 15454 can be networked within a mixed IP and OSI environment.

Note This chapter does not provide a comprehensive explanation of IP networking concepts and procedures, nor does it provide IP addressing examples to meet all networked scenarios. For ONS 15454 networking setup instructions, refer to the “Turn Up a Node” chapter of the Cisco ONS 15454 Procedure Guide.

Note To connect ONS 15454s to an IP network, you must work with a LAN administrator or other individual at your site who has IP networking training and experience.

13.1 IP Networking Overview

ONS 15454s can be connected in many different ways within an IP environment:

They can be connected to LANs through direct connections or a router.

IP subnetting can create multiple logical ONS 15454 networks within a single Class A, B, or C IP network. If you do not subnet, you will only be able to use one network from your Class A, B, or C network.

Different IP functions and protocols can be used to achieve specific network goals. For example, Proxy Address Resolution Protocol (ARP) enables one LAN-connected ONS 15454 to serve as a gateway for ONS 15454s that are not connected to the LAN.

Static routes can be created to enable connections among multiple CTC sessions with ONS 15454s that reside on the same subnet.

ONS 15454s can be connected to Open Shortest Path First (OSPF) networks so that ONS 15454 network information is automatically communicated across multiple LANs and WANs.

The ONS 15454 SOCKS (network proxy protocol) proxy server can control the visibility and accessibility between CTC computers and ONS 15454 element nodes.

13.2 IP Addressing Scenarios

ONS 15454 IP addressing generally has eight common scenarios or configurations. Use the scenarios as building blocks for more complex network configurations.
Table 13-1 provides a general list of items to check when setting up ONS 15454 nodes in IP networks.

13.2.2
IP Scenario 2: CTC and ONS 15454 Nodes Connected to a Router

In IP Scenario 2 the CTC computer resides on a subnet (192.168.1.0) and attaches to LAN A (Figure 13-2). The ONS 15454s reside on a different subnet (192.168.2.0) and attach to LAN B. A router connects LAN A to LAN B. The IP address of router interface A is set to LAN A (192.168.1.1), and the IP address of router interface B is set to LAN B (192.168.2.1).

On the CTC computer, the default gateway is set to router interface A. If the LAN uses Dynamic Host Configuration Protocol (DHCP), the default gateway and IP address are assigned automatically. In the Figure 13-2 example, a DHCP server is not available.

13.2.3
IP Scenario 3: Using Proxy ARP to Enable an ONS 15454 Gateway

ARP matches higher-level IP addresses to the physical addresses of the destination host. It uses a lookup table (called ARP cache) to perform the translation. When the address is not found in the ARP cache, a broadcast is sent out on the network with a special format called the ARP request. If one of the machines on the network recognizes its own IP address in the request, it sends an ARP reply back to the requesting host. The reply contains the physical hardware address of the receiving host. The requesting host stores this address in its ARP cache so that all subsequent datagrams (packets) to this destination IP address can be translated to a physical address.

Proxy ARP enables one LAN-connected ONS 15454 to respond to the ARP request for ONS 15454s not connected to the LAN. (ONS 15454 proxy ARP requires no user configuration.) For this to occur, the DCC-connected ONS 15454s must reside on the same subnet. When a LAN device sends an ARP request to an ONS 15454 that is not connected to the LAN, the gateway ONS 15454 returns its MAC address to the LAN device. The LAN device then sends the datagram for the remote ONS 15454 to the MAC address of the proxy ONS 15454. The proxy ONS 15454 uses its routing table to forward the datagram to the non-LAN ONS 15454.

IP Scenario 3 is similar to IP Scenario 1, but only one ONS 15454 (1) connects to the LAN (Figure 13-3). Two ONS 15454s (2 and 3) connect to ONS 15454 1 through the SONET DCC. Because all three ONS 15454s are on the same subnet, proxy ARP enables ONS 15454 1 to serve as a gateway for ONS 15454 2 and 3.

You can also use proxy ARP to communicate with hosts attached to the craft Ethernet ports of DCC-connected nodes (Figure 13-4). The node with an attached host must have a static route to the host. Static routes are propagated to all DCC peers using OSPF. The existing proxy ARP node is the gateway for additional hosts. Each node examines its routing table for routes to hosts that are not connected to the DCC network but are within the subnet. The existing proxy server replies to ARP requests for these additional hosts with the node MAC address. The existence of the host route in the routing table ensures that the IP packets addressed to the additional hosts are routed properly. Other than establishing a static route between a node and an additional host, no provisioning is necessary. The following restrictions apply:

Only one node acts as the proxy ARP server for any given additional host.

A node cannot be the proxy ARP server for a host connected to its Ethernet port.

In Figure 13-4, Node 1 announces to Node 2 and 3 that it can reach the CTC host. Similarly, Node 3 announces that it can reach the ONS 152xx. The ONS 152xx is shown as an example; any network element (NE) can be set up as an additional host.

Figure 13-4 IP Scenario 3: Using Proxy ARP with Static Routing

13.2.4 IP Scenario 4: Default Gateway on a CTC Computer

IP Scenario 4 is similar to IP Scenario 3, but Nodes 2 and 3 reside on different subnets, 192.168.2.0 and 192.168.3.0, respectively (Figure 13-5). Node 1 and the CTC computer are on subnet 192.168.1.0. Proxy ARP is not used because the network includes different subnets. For the CTC computer to communicate with Nodes 2 and 3, Node 1 is entered as the default gateway on the CTC computer.

Figure 13-5 IP Scenario 4: Default Gateway on a CTC Computer

13.2.5
IP Scenario 5: Using Static Routes to Connect to LANs

Static routes are used for two purposes:

To connect ONS 15454s to CTC sessions on one subnet connected by a router to ONS 15454s residing on another subnet. (These static routes are not needed if OSPF is enabled. “IP Scenario 6: Using OSPF” section shows an OSPF example.)

To enable multiple CTC sessions among ONS 15454s residing on the same subnet.

InFigure 13-6, one CTC residing on subnet 192.168.1.0 connects to a router through interface A. (The router is not set up with OSPF.) ONS 15454s residing on different subnets are connected through Node 1 to the router through interface B. Because Nodes 2 and 3 are on different subnets, proxy ARP does not enable Node 1 as a gateway. To connect to the CTC computer on LAN A (subnet 192.168.1.0), you must create a static route on Node 1. You must also manually add static routes between the CTC computer on LAN A and Nodes 2 and 3 because these nodes are on different subnets.

Figure 13-6 IP Scenario 5: Static Route With One CTC Computer Used as a Destination

The destination and subnet mask entries control access to the ONS 15454s:

If a single CTC computer is connected to a router, enter the complete CTC “host route” IP address as the destination with a subnet mask of 255.255.255.255.

If CTC computers on a subnet are connected to a router, enter the destination subnet (in this example, 192.168.1.0) and a subnet mask of 255.255.255.0.

If all CTC computers are connected to a router, enter a destination of 0.0.0.0 and a subnet mask of 0.0.0.0. Figure 13-7 shows an example.

The IP address of router interface B is entered as the next hop, and the cost (number of hops from source to destination) is 2. You must manually add static routes between the CTC computers on LAN A, B, and C and Nodes 2 and 3 because these nodes are on different subnets.

13.2.6
IP Scenario 6: Using OSPF

Open Shortest Path First (OSPF) is a link state Internet routing protocol. Link state protocols use a “hello protocol” to monitor their links with adjacent routers and to test the status of their links to their neighbors. Link state protocols advertise their directly connected networks and their active links. Each link state router captures the link state “advertisements” and puts them together to create a topology of the entire network or area. From this database, the router calculates a routing table by constructing a shortest path tree. Routes are recalculated when topology changes occur.

ONS 15454s use the OSPF protocol in internal ONS 15454 networks for node discovery, circuit routing, and node management. You can enable OSPF on the ONS 15454s so that the ONS 15454 topology is sent to OSPF routers on a LAN. Advertising the ONS 15454 network topology to LAN routers eliminates the need to manually enter static routes for ONS 15454 subnetworks. Figure 13-8 shows a network enabled for OSPF. Figure 13-9 shows the same network without OSPF. Static routes must be manually added to the router for CTC computers on LAN A to communicate with Nodes 2 and 3 because these nodes reside on different subnets.

OSPF divides networks into smaller regions, called areas. An area is a collection of networked end systems, routers, and transmission facilities organized by traffic patterns. Each OSPF area has a unique ID number, known as the area ID. Every OSPF network has one backbone area called “area 0.” All other OSPF areas must connect to area 0.

When you enable an ONS 15454 OSPF topology for advertising to an OSPF network, you must assign an OSPF area ID in decimal format to the ONS 15454 network. Coordinate the area ID number assignment with your LAN administrator. All DCC-connected ONS 15454s should be assigned the same OSPF area ID.

Figure 13-8 IP Scenario 6: OSPF Enabled

Figure 13-9 IP Scenario 6: OSPF Not Enabled

13.2.7 IP Scenario 7: Provisioning the ONS 15454 SOCKS Proxy Server

The ONS 15454 SOCKS proxy is an application that allows an ONS 15454 node to serve as an internal gateway between a private enterprise network and the ONS 15454 network. (SOCKS is a standard proxy protocol for IP-based applications developed by the Internet Engineering Task Force.) Access is allowed from the private network to the ONS 15454 network, but access is denied from the ONS 15454 network to the private network. For example, you can set up a network so that field technicians and network operations center (NOC) personnel can both access the same ONS 15454s while preventing the field technicians from accessing the NOC LAN. To do this, one ONS 15454 is provisioned as a gateway network element (GNE) and the other ONS 15454s are provisioned as end network elements (ENEs). The GNE ONS 15454 tunnels connections between CTC computers and ENE ONS 15454s, providing management capability while preventing access for non-ONS 15454 management purposes.

If checked, the ONS 15454 serves as a proxy for connections between CTC clients and ONS 15454s that are DCC-connected to the proxy ONS 15454. The CTC client establishes connections to DCC-connected nodes through the proxy node. The CTC client can connect to nodes that it cannot directly reach from the host on which it runs. If not selected, the node does not proxy for any CTC clients, although any established proxy connections continue until the CTC client exits. In addition, you can set the SOCKS proxy server as an ENE or a GNE:

External Network Element (ENE)—If set as an ENE, the ONS 15454 neither installs nor advertises default or static routes. CTC computers can communicate with the ONS 15454 using the TCC2/TCC2P craft port, but they cannot communicate directly with any other DCC-connected ONS 15454.

In addition, firewall is enabled, which means that the node prevents IP traffic from being routed between the DCC and the LAN port. The ONS 15454 can communicate with machines connected to the LAN port or connected through the DCC. However, the DCC-connected machines cannot communicate with the LAN-connected machines, and the LAN-connected machines cannot communicate with the DCC-connected machines. A CTC client using the LAN to connect to the firewall-enabled node can use the proxy capability to manage the DCC-connected nodes that would otherwise be unreachable. A CTC client connected to a DCC-connected node can only manage other DCC-connected nodes and the firewall itself.

Gateway Network Element (GNE)—If set as a GNE, the CTC computer is visible to other DCC-connected nodes and firewall is enabled.

Proxy-only—If Proxy-only is selected, firewall is not enabled. CTC can communicate with any other DCC-connected ONS 15454s.

Note If you launch CTC against a node through a Network Address Translation (NAT) or Port Address Translation (PAT) router and that node does not have proxy enabled, your CTC session starts and initially appears to be fine. However, CTC never receives alarm updates and disconnects and reconnects every two minutes. If the proxy is accidentally disabled, it is still possible to enable the proxy during a reconnect cycle and recover your ability to manage the node, even through a NAT/PAT firewall.

Note ENEs that belong to different private subnetworks do not need to have unique IP addresses. Two ENEs that are connected to different GNEs can have the same IP address. However, ENEs that connect to the same GNE must always have unique IP addresses.

shows an ONS 15454 SOCKS proxy server implementation. A GNE ONS 15454 is connected to a central office LAN and to ENE ONS 15454s. The central office LAN is connected to a NOC LAN, which has CTC computers. Both the NOC CTC computer and the craft technicians must be able to access the ONS 15454 ENEs. However, the craft technicians must be prevented from accessing or seeing the NOC or central office LANs.

In the example, the ONS 15454 GNE is assigned an IP address within the central office LAN and is physically connected to the LAN through its LAN port. ONS 15454 ENEs are assigned IP addresses that are outside the central office LAN and are given private network IP addresses. If the ONS 15454 ENEs are collocated, the craft LAN ports could be connected to a hub. However, the hub should have no other network connections.

Figure 13-12 shows the same SOCKS proxy server implementation with ONS 15454 ENEs on different subnets. Figure 13-13 shows the implementation with ONS 15454 ENEs in multiple rings. In each example, ONS 15454 GNEs and ENEs are provisioned with the settings shown in
Table 13-2.

If you implement the SOCKS proxy server, note that all DCC-connected ONS 15454s on the same Ethernet segment must have the same gateway setting. Mixed values produce unpredictable results, and might leave some nodes unreachable through the shared Ethernet segment.

If nodes become unreachable, correct the setting with one of the following actions:

Disconnect the craft computer from the unreachable ONS 15454. Connect to the ONS 15454 through another network ONS 15454 that has a DCC connection to the unreachable ONS 15454.

Disconnect all DCCs to the node by disabling them on neighboring nodes. Connect a CTC computer directly to the ONS 15454 and change its provisioning.

13.2.8 IP Scenario 8: Dual GNEs on a Subnet

The ONS 15454 provides GNE load balancing, which allows CTC to reach ENEs over multiple GNEs without the ENEs being advertised over OSPF. This feature allows a network to quickly recover from the loss of a GNE, even if the GNE is on a different subnet. If a GNE fails, all connections through that GNE fail. CTC disconnects from the failed GNE and from all ENEs for which the GNE was a proxy, and then reconnects through the remaining GNEs. GNE load balancing reduces the dependency on the launch GNE and DCC bandwidth, both of which enhance CTC performance. Figure 13-14 shows a network with dual GNEs on the same subnet.

13.2.9
IP Scenario 9: IP Addressing with Secure Mode Enabled

The TCC2 card and TCC2P card both default to nonsecure mode. In this mode, the front and back Ethernet (LAN) ports share a single MAC address and IP address. TCC2P cards allow you to place a node in secure mode, which prevents a front-access craft port user from accessing the LAN through the backplane port. Secure mode can be locked, which prevents the mode from being altered. To place a node in secure mode or to lock secure node, refer to the “Change Node Settings” chapter in the
Cisco ONS 15454 Procedure Guide
.

13.2.9.1 Secure Mode Behavior

Changing a TCC2P node from repeater mode to secure mode allows you to provision two IP addresses for the ONS 15454 and causes the node to assign the ports different MAC addresses. In secure mode, one IP address is provisioned for the ONS 15454 backplane LAN port, and the other IP address is provisioned for the TCC2P Ethernet port. Both addresses reside on different subnets, providing an additional layer of separation between the craft access port and the ONS 15454 LAN. If secure mode is enabled, the IP addresses provisioned for both TCC2P TCP/IP LAN ports must follow general IP addressing guidelines and must reside on different subnets from each other and the default router IP address.

In secure mode, the IP address assigned to the front LAN (Ethernet) port becomes a private address, while the backplane connects the node to an Operations Support System (OSS) through a central office LAN or private enterprise network. A superuser can configure the node to hide or reveal the backplane's LAN IP address in CTC, the routing table, or autonomous message reports.

In nonsecure mode, a node can be a GNE or ENE. Placing the node into secure mode automatically turns on SOCKS proxy and defaults the node to GNE status. However, the node can be changed back to an ENE. In nonsecure mode, an ENE’s SOCKS proxy can be disabled—effectively isolating the node beyond the LAN firewall—but it cannot be disabled in secure mode.To change a node’s GNE or ENE status and disable the SOCKS proxy, refer to the “Turn Up a Node” chapter in the
Cisco ONS 15454 Procedure Guide
.

Note The secure mode option does not appear in CTC if TCC2 cards are installed. If one TCC2 and one TCC2P card are installed in a node, secure mode will appear in CTC but it cannot be modified.

Note If both front and backplane access ports are disabled in an ENE and the node is isolated from DCC communication (due to user provisioning or network faults), the front and backplane ports are automatically reenabled.

Figure 13-16 shows an example of secure-mode ONS 15454 nodes with front-access Ethernet port addresses that reside on the same subnet.

Figure 13-17 shows an example of ONS 15454 nodes connected to a router with secure mode enabled. In each example, the node’s TCC2P port address (node address) resides on a different subnet from the node backplane addresses.

13.2.9.2 Secure Node Locked and Unlocked Behavior

Secure mode can operate on a node in either locked or unlocked mode. By default, secure mode’s status is unlocked; only a superuser can convert it to locked mode. Doing so permanently changes the hardware configuration on the active and standby TCC2P cards as well as the chassis.

Locked mode must be used carefully because the cards and shelf retain their locked status even if separated from each other. For example, if a node is in secure, locked mode and you perform a card pull on its standby TCC2P, then insert that as the active card into another node, the secure, locked mode is written to the new node’s chassis and standby TCC2P. If you perform a card pull on a secure, locked node’s active and standby TCC2Ps and insert both of them into a chassis that previously was in unlocked mode, the node becomes locked.

When it is secure and locked, a node’s configuration, Ethernet port status, its secure mode, and the locked status cannot be changed by any network user— including a superuser. To have a secure node’s lock removed, contact Cisco Technical Support to arrange a Return Material Authorization (RMA) for the chassis and for the TCC2Ps. Refer to the “$paratext>” section as needed.

The following ACL example shows a firewall configuration when the SOCKS proxy server gateway setting is not enabled. In the example, the CTC workstation's address is 192.168.10.10. and the ONS 15454 address is 10.10.10.100. The firewall is attached to the GNE, so inbound is CTC to the GNE and outbound is from the GNE to CTC. The CTC CORBA Standard constant is 683 and the TCC CORBA Default is TCC Fixed (57790).

The following ACL example shows a firewall configuration when the SOCKS proxy server gateway setting is enabled. As with the first example, the CTC workstation address is 192.168.10.10 and the ONS 15454 address is 10.10.10.100. The firewall is attached to the GNE, so inbound is CTC to the GNE and outbound is from the GNE to CTC. CTC CORBA Standard constant is 683 and the TCC CORBA Default is TCC Fixed (57790).

13.5 Open GNE

The ONS 15454 can communicate with non-ONS nodes that do not support Point-to-Point Protocol (PPP) vendor extensions or OSPF type 10 opaque link-state advertisements (LSA), both of which are necessary for automatic node and link discovery. An open GNE configuration allows the DCC-based network to function as an IP network for non-ONS nodes.

To configure an open GNE network, you can provision SDCC, LDCC, and GCC terminations to include a far-end, non-ONS node using either the default IP address of 0.0.0.0 or a specified IP address. You provision a far-end, non-ONS node by checking the Far End is Foreign check box during SDCC, LDCC, and GCC creation. The default 0.0.0.0 IP address allows the far-end, non-ONS node to provide the IP address; if you set an IP address other than 0.0.0.0, a link is established only if the far-end node identifies itself with that IP address, providing an extra level of security.

By default, the SOCKS proxy server only allows connections to discovered ONS peers and the firewall blocks all IP traffic between the DCC network and LAN. You can, however, provision proxy tunnels to allow up to 12 additional destinations for SOCKS version 5 connections to non-ONS nodes. You can also provision firewall tunnels to allow up to 12 additional destinations for direct IP connectivity between the DCC network and the LAN. Proxy and firewall tunnels include both a source and destination subnet. The connection must originate within the source subnet and terminate within the destination subnet before either the SOCKS connection or IP packet flow is allowed.

To set up proxy and firewall subnets in CTC, use the Provisioning > Network > Proxy and Firewalls subtabs. The availability of proxy and/or firewall tunnels depends on the network access settings of the node:

If the node is configured with the SOCKS proxy server enabled in GNE or ENE mode, you must set up a proxy tunnel and/or a firewall tunnel.

If the node is configured with the SOCKS proxy server enabled in proxy-only mode, you can set up proxy tunnels. Firewall tunnels are not allowed.

If the node is configured with the SOCKS proxy server disabled, neither proxy tunnels nor firewall tunnels are allowed.

Figure 13-18 shows an example of a foreign node connected to the DCC network. Proxy and firewall tunnels are useful in this example because the GNE would otherwise block IP access between the PC and the foreign node.

Figure 13-18 Proxy and Firewall Tunnels for Foreign Terminations

Figure 13-19shows a remote node connected to an ENE Ethernet port. Proxy and firewall tunnels are useful in this example because the GNE would otherwise block IP access between the PC and foreign node. This configuration also requires a firewall tunnel on the ENE.

Figure 13-19 Foreign Node Connection to an ENE Ethernet Port

13.6 TCP/IP and OSI Networking

ONS 15454 DCN communication is based on the TCP/IP protocol suite. However, ONS 15454s can also be networked with equipment that uses the OSI protocol suite. While TCP/IP and OSI protocols are not directly compatible, they do have the same objectives and occupy similar layers of the OSI reference model.
Table 13-7 shows the protocols and mediation processes that are involved when TCP/IP-based NEs are networked with OSI-based NEs.

13.6.1 Point-to-Point Protocol

PPP is a data link (Layer 2) encapsulation protocol that transports datagrams over point-to-point links. Although PPP was developed to transport IP traffic, it can carry other protocols including the OSI CLNP. PPP components used in the transport of OSI include:

High-level data link control (HDLC)—Performs the datagram encapsulation for transport across point-to-point links.

Link control protocol (LCP)—Establishes, configures, and tests the point-to-point connections.

CTC automatically enables IP over PPP whenever you create an SDCC or LDCC. The SDCC or LDCC can be provisioned to support OSI over PPP.

13.6.2 Link Access Protocol on the D Channel

LAP-D is a data link protocol used in the OSI protocol stack. LAP-D is assigned when you provision an ONS 15454 SDCC as OSI-only. Provisionable LAP-D parameters include:

Transfer Service—One of the following transfer services must be assigned:

– Acknowledged Information Transfer Service (AITS)—(Default) Does not exchange data until a logical connection between two LAP-D users is established. This service provides reliable data transfer, flow control, and error control mechanisms.

– Unacknowledged Information Transfer Service (UITS)—Transfers frames containing user data with no acknowledgement. The service does not guarantee that the data presented by one user will be delivered to another user, nor does it inform the user if the delivery attempt fails. It does not provide any flow control or error control mechanisms.

Mode—LAP-D is set to either Network or User mode. This parameter sets the LAP-D frame command/response (C/R) value, which indicates whether the frame is a command or a response.

Maximum transmission unit (MTU)—The LAP-D N201 parameter sets the maximum number of octets in a LAP-D information frame. The range is 512 to 1500 octets.

Note The MTU must be the same size for all NEs on the network.

Transmission Timers—The following LAP-D timers can be provisioned:

– The T200 timer sets the timeout period for initiating retries or declaring failures.

– The T203 timer provisions the maximum time between frame exchanges, that is, the trigger for transmission of the LAP-D “keep-alive” Receive Ready (RR) frames.

Fixed values are assigned to the following LAP-D parameters:

Terminal Endpoint Identifier (TEI)—A fixed value of 0 is assigned.

Service Access Point Identifier (SAPI)—A fixed value of 62 is assigned.

13.6.3 OSI Connectionless Network Service

OSI connectionless network service is implemented by using the Connectionless Network Protocol (CLNP) and Connectionless Network Service (CLNS). CLNP and CLNS are described in the ISO 8473 standard. CLNS provides network layer services to the transport layer through CLNP. CLNS does not perform connection setup or termination because paths are determined independently for each packet that is transmitted through a network. CLNS relies on transport layer protocols to perform error detection and correction.

CLNP is an OSI network layer protocol that carries upper-layer data and error indications over connectionless links. CLNP provides the interface between the CLNS and upper layers. CLNP performs many of the same services for the transport layer as IP. The CLNP datagram is very similar to the IP datagram. It provides mechanisms for fragmentation (data unit identification, fragment/total length, and offset). Like IP, a checksum computed on the CLNP header verifies that the information used to process the CLNP datagram is transmitted correctly, and a lifetime control mechanism (Time to Live) limits the amount of time a datagram is allowed to remain in the system.

CLNP uses network service access points (NSAPs) to identify network devices. The CLNP source and destination addresses are NSAPs. In addition, CLNP uses a network element title (NET) to identify a network-entity in an end system (ES) or intermediate system (IS). NETs are allocated from the same name space as NSAP addresses. Whether an address is an NSAP address or a NET depends on the network selector value in the NSAP.

The ONS 15454 supports the ISO Data Country Code (ISO-DCC) NSAP address format as specified in ISO 8348. The NSAP address is divided into an initial domain part (IDP) and a domain-specific part (DSP). NSAP fields are shown in
Table 13-8. NSAP field values are in hexadecimal format. All NSAPs are editable. Shorter NSAPs can be used. However NSAPs for all NEs residing within the same OSI network area usually have the same NSAP format.

Table 13-8 NSAP Fields

Field

Definition

Description

IDP

AFI

Authority and format identifier

Specifies the NSAP address format. The initial value is 39 for the ISO-DCC address format.

IDI

Initial domain identifier

Specifies the country code. The initial value is 840F, the United States country code padded with an F.

DSP

DFI

DSP format identifier

Specifies the DSP format. The initial value is 80, indicating the DSP format follows American National Standards Institute (ANSI) standards.

ORG

Organization

Organization identifier. The initial value is 000000.

Reserved

Reserved

Reserved NSAP field. The Reserved field is normally all zeros (0000).

RD

Routing domain

Defines the routing domain. The initial value is 0000.

AREA

Area

Identifies the OSI routing area to which the node belongs. The initial value is 0000.

System

System identifier

The ONS 15454 system identifier is set to its IEEE 802.3 MAC address. Each ONS 15454 supports three OSI virtual routers. Each router NSAP system identifier is the ONS 15454 IEEE 802.3 MAC address +
n
, where
n
= 0 to 2. For the primary virtual router,
n
= 0.

SEL

Selector

The selector field directs the protocol data units (PDUs) to the correct destination using the CLNP network layer service. Selector values supported by the ONS 15454 include:

This address is also the Router 1 primary manual area address, which is viewed and edited on the Provisioning > OSI > Routers subtab. See the “OSI Virtual Routers” section for information about the OSI router and manual area addresses in CTC.

13.6.4 OSI Routing

A set of routing protocols that allow ESs and ISs to collect and distribute the information necessary to determine routes. Protocols include the ES-IS and IS-IS protocols. ES-IS routing establishes connectivity and reach ability among ESs and ISs attached to the same (single) subnetwork.

A routing information base (RIB) (see containing this information, from which routes between ESs can be computed. The RIB consists of a table of entries that identify a destination (for example, an NSAP), the subnetwork over which packets should be forwarded to reach that destination, and a routing metric. The routing metric communicates characteristics of the route (such as delay properties or expected error rate) that are used to evaluate the suitability of a route compared to another route with different properties, for transporting a particular packet or class of packets.

A routing algorithm, Shortest Path First (SPF), that uses information contained in the RIB to derive routes between ESs.

In OSI networking, discovery is based on announcements. An ES uses the ES-IS protocol end system hello (ESH) message to announce its presence to ISs and ESs connected to the same network. Any ES or IS that is listening for ESHs gets a copy. ISs store the NSAP address and the corresponding subnetwork address pair in routing tables. ESs might store the address, or they might wait to be informed by ISs when they need such information.

An IS composes intermediate system hello (ISH) messages to announce its configuration information to ISs and ESs that are connected to the same broadcast subnetwork. Like the ESHs, the ISH contains the addressing information for the IS (the NET and the subnetwork point-of-attachment address [SNPA]) and a holding time. ISHs might also communicate a suggested ES configuration time recommending a configuration timer to ESs.

The exchange of ISHs is called neighbor greeting or initialization. Each router learns about the other routers with which they share direct connectivity. After the initialization, each router constructs a link-state packet (LSP). The LSP contains a list of the names of the IS’s neighbors and the cost to reach each of the neighbors. Routers then distribute the LSPs to all of the other routers. When all LSPs are propagated to all routers, each router has a complete map of the network topology (in the form of LSPs). Routers use the LSPs and the SPF algorithm to compute routes to every destination in the network.

OSI networks are divided into areas and domains. An area is a group of contiguous networks and attached hosts that is designated as an area by a network administrator. A domain is a collection of connected areas. Routing domains provide full connectivity to all ESs within them. Routing within the same area is known as Level 1 routing. Routing between two areas is known as Level 2 routing. LSPs that are exchanged within a Level 1 area are called L1 LSPs. LSPs that are exchanged across Level 2 areas are called L2 LSPs. Figure 13-22 shows an example of Level 1 and Level 2 routing.

Figure 13-22 Level 1 and Level 2 OSI Routing

When you provision an ONS 15454 for a network with NEs that use both the TCP/IP and OSI protocol stacks, you will provision it as one of the following:

End System—The ONS 15454 performs OSI ES functions and relies upon an IS for communication with nodes that reside within its OSI area.

Intermediate System Level 1—The ONS 15454 performs OSI IS functions. It communicates with IS and ES nodes that reside within its OSI area. It depends upon an IS L1/L2 node to communicate with IS and ES nodes that reside outside its OSI area.

Intermediate System Level 1/Level 2—The ONS 15454 performs IS functions. It communicates with IS and ES nodes that reside within its OSI area. It also communicates with IS L1/L2 nodes that reside in other OSI areas. This option should not be provisioned unless the node is connected to another IS L1/L2 node that resides in a different OSI area. The node must also be connected to all nodes within its area that are provisioned as IS L1/L2.

13.6.4.1 End System-to-Intermediate System Protocol

ES-IS is an OSI protocol that defines how ESs (hosts) and ISs (routers) learn about each other. ES-IS configuration information is transmitted at regular intervals through the ES and IS hello messages. The hello messages contain the subnetwork and network layer addresses of the systems that generate them.

The ES-IS configuration protocol communicates both OSI network layer addresses and OSI subnetwork addresses. OSI network layer addresses identify either the NSAP, which is the interface between OSI Layer 3 and Layer 4, or the NET, which is the network layer entity in an OSI IS. OSI SNPAs are the points at which an ES or IS is physically attached to a subnetwork. The SNPA address uniquely identifies each system attached to the subnetwork. In an Ethernet network, for example, the SNPA is the 48-bit MAC address. Part of the configuration information transmitted by ES-IS is the NSAP-to-SNPA or NET-to-SNPA mapping.

13.6.4.2 Intermediate System-to-Intermediate System Protocol

IS-IS is an OSI link-state hierarchical routing protocol that floods the network with link-state information to build a complete, consistent picture of a network topology. IS-IS distinguishes between Level 1 and Level 2 ISs. Level 1 ISs communicate with other Level 1 ISs in the same area. Level 2 ISs route between Level 1 areas and form an intradomain routing backbone. Level 1 ISs need to know only how to get to the nearest Level 2 IS. The backbone routing protocol can change without impacting the intra-area routing protocol.

OSI routing begins when the ESs discover the nearest IS by listening to ISH packets. When an ES wants to send a packet to another ES, it sends the packet to one of the ISs on its directly attached network. The router then looks up the destination address and forwards the packet along the best route. If the destination ES is on the same subnetwork, the local IS knows this from listening to ESHs and forwards the packet appropriately. The IS also might provide a redirect (RD) message back to the source to tell it that a more direct route is available. If the destination address is an ES on another subnetwork in the same area, the IS knows the correct route and forwards the packet appropriately. If the destination address is an ES in another area, the Level 1 IS sends the packet to the nearest Level 2 IS. Forwarding through Level 2 ISs continues until the packet reaches a Level 2 IS in the destination area. Within the destination area, the ISs forward the packet along the best path until the destination ES is reached.

Link-state update messages help ISs learn about the network topology. Each IS generates an update specifying the ESs and ISs to which it is connected, as well as the associated metrics. The update is then sent to all neighboring ISs, which forward (flood) it to their neighbors, and so on. (Sequence numbers terminate the flood and distinguish old updates from new ones.) Using these updates, each IS can build a complete topology of the network. When the topology changes, new updates are sent.

IS-IS uses a single required default metric with a maximum path value of 1024. The metric is arbitrary and typically is assigned by a network administrator. Any single link can have a maximum value of 64, and path links are calculated by summing link values. Maximum metric values were set at these levels to provide the granularity to support various link types while at the same time ensuring that the shortest-path algorithm used for route computation is reasonably efficient. Three optional IS-IS metrics (costs)—delay, expense, and error—are not supported by the ONS 15454. IS-IS maintains a mapping of the metrics to the quality of service (QoS) option in the CLNP packet header. IS-IS uses the mappings to compute routes through the internetwork.

13.6.5 TARP

TARP is used when TL1 target identifiers (TIDs) must be translated to NSAP addresses. The TID-to-NSAP translation occurs by mapping TIDs to the NETs, then deriving NSAPs from the NETs by using the NSAP selector values (Table 13-8).

TARP uses a selective PDU propagation methodology in conjunction with a distributed database (that resides within the NEs) of TID-to-NET mappings. TARP allows NEs to translate between TID and NET by automatically exchanging mapping information with other NEs. The TARP PDU is carried by the standard CLNP Data PDU. TARP PDU fields are shown in
Table 13-9.

Table 13-9 TARP PDU Fields

Field

Abbreviation

Size (bytes)

Description

TARP Lifetime

tar-lif

2

The TARP time-to-live in hops.

TARP Sequence Number

tar-seq

2

The TARP sequence number used for loop detection.

Protocol Address Type

tar-pro

1

Used to identify the type of protocol address that the TID must be mapped to. The value FE is used to identify the CLNP address type.

TARP Type Code

tar-tcd

1

The TARP Type Code identifies the TARP type of PDU. Five TARP types, shown in
Table 13-10, are defined.

TID Target Length

tar-tln

1

The number of octets that are in the tar-ttg field.

TID Originator Length

tar-oln

1

The number of octets that are in the tar-tor field.

Protocol Address Length

tar-pln

1

The number of octets that are in the tar-por field.

TID of Target

tar-ttg

n
= 0, 1, 2...

TID value for the target NE.

TID of Originator

tar-tor

n
= 0, 1, 2...

TID value of the TARP PDU originator.

Protocol Address of Originator

tar-por

n
= 0, 1, 2...

Protocol address (for the protocol type identified in the tar-pro field) of the TARP PDU originator. When the tar-pro field is set to FE (hex), tar-por will contain a CLNP address (that is, the NET).

After an NE originates a TARP Type 1 PDU, the PDU is sent to all adjacent NEs within the NE routing area.

2

Sent when a device has a TID for which it has no matching NSAP and no response was received from the Type 1 PDU.

After an NE originates a TARP Type 2 PDU, the PDU is sent to all Level 1 and Level 2 neighbors.

3

Sent as a response to Type 1, Type 2, or Type 5 PDUs.

After a TARP Request (Type 1 or 2) PDU is received, a TARP Type 3 PDU is sent to the request originator. Type 3 PDUs do not use the TARP propagation procedures.

4

Sent as a notification when a change occurs locally, for example, a TID or NSAP change. It might also be sent when an NE initializes.

A Type 4 PDU is a notification of a TID or Protocol Address change at the NE that originates the notification. The PDU is sent to all adjacencies inside and outside the NE’s routing area.

5

Sent when a device needs a TID that corresponds to a specific NSAP.

When a Type 5 PDU is sent, the CLNP destination address is known, so the PDU is sent to only that address. Type 5 PDUs do not use the TARP propagation procedures.

13.6.5.1 TARP Processing

A TARP data cache (TDC) is created at each NE to facilitate TARP processing. In CTC, the TDC is displayed and managed on the node view Maintenance > OSI > TDC subtab. The TDC subtab contains the following TARP PDU fields:

TID—TID of the originating NE (tar-tor).

NSAP—NSAP of the originating NE.

Type— Indicates whether the TARP PDU was created through the TARP propagation process (dynamic) or manually created (static).

Table 13-12 shows the main TARP processes and the general sequence of events that occurs in each process.

Table 13-12 TARP Processing Flow

Process

General TARP Flow

Find a NET that matches a TID

1. TARP checks its TDC for a match. If a match is found, TARP returns the result to the requesting application.

2. If no match is found, a TARP Type 1 PDU is generated and Timer T1 is started.

3. If Timer T1 expires before a match if found, a Type 2 PDU is generated and Timer T2 is started.

4. If Timer T2 expires before a match is found, Timer T4 is started.

5. If Timer T4 expires before a match is found, a Type 2 PDU is generated and Timer T2 is started.

Find a TID that matches a NET

A Type 5 PDU is generated. Timer T3 is used. However, if the timer expires, no error recovery procedure occurs, and a status message is provided to indicate that the TID cannot be found.

Send a notification of TID or protocol address change

TARP generates a Type 4 PDU in which the tar-ttg field contains the NE TID value that existed prior to the change of TID or protocol address. Confirmation that other NEs successfully received the address change is not sent.

13.6.5.2 TARP Loop Detection Buffer

The TARP loop detection buffer (LDB) can be enabled to prevent duplicate TARP PDUs from entering the TDC. When a TARP Type 1, 2, or 4 PDU arrives, TARP checks its LDB for a NET address (tar-por) of the PDU originator match. If no match is found, TARP processes the PDU and assigns a tar-por, tar-seq (sequence) entry for the PDU to the LDB. If the tar-seq is zero, a timer associated with the LDB entry is started using the provisionable LDB entry timer on the node view OSI > TARP > Config tab. If a match exists, the tar-seq is compared to the LDB entry. If the tar-seq is not zero and is less than or equal to the LDB entry, the PDU is discarded. If the tar-seq is greater than the LDB entry, the PDU is processed and the tar-seq field in the LDB entry is updated with the new value. The Cisco ONS 15454 LDB holds approximately 500 entries. The LDB is flushed periodically based on the time set in the LDB Flush timer on the node view OSI > TARP > Config tab.

13.6.5.3 Manual TARP Adjacencies

TARP adjacencies can be manually provisioned in networks where ONS 15454s must communicate across routers or non-SONET NEs that lack TARP capability. In CTC, manual TARP adjacencies are provisioned on the node view Provisioning > OSI > TARP > MAT (Manual Area Table) subtab. The manual adjacency causes a TARP request to hop through the general router or non-SONET NE, as shown in Figure 13-23.

Figure 13-23 Manual TARP Adjacencies

13.6.5.4 Manual TID to NSAP Provisioning

TIDs can be manually linked to NSAPs and added to the TDC. Static TDC entries are similar to static routes. For a specific TID, you force a specific NSAP. Resolution requests for that TID always return that NSAP. No TARP network propagation or instantaneous replies are involved. Static entries allow you to forward TL1 commands to NEs that do not support TARP. However, static TDC entries are not dynamically updated, so outdated entries are not removed after the TID or the NSAP changes on the target node.

FT–TD—Performs an FTP conversion between FTAM and FTP. The FT–TD gateway entity includes an FTAM responder (server) and an FTP client, allowing FTAM initiators (clients) to store, retrieve, or delete files from an FTP server. The FT–TD gateway is unidirectional and is driven by the FTAM initiator. The FT–TD FTAM responder exchanges messages with the FTAM initiator over the full OSI stack. Figure 13-25 shows the FT–TD protocol flow.

Figure 13-25 FT–TD Protocol Flow

The ONS 15454 uses FT–TD for the following file transfer processes:

Software downloads

Database backups and restores

Cisco IOS configuration backups and restores for ML and ML2 Series cards.

13.6.7 OSI Virtual Routers

Each router has an editable manual area address and a unique NSAP System ID that is set to the node MAC address +
n
. For Router 1,
n
= 0. For Router 2,
n
= 1. For Router 3,
n
= 2. Each router can be enabled and connected to different OSI routing areas. However, Router 1 is the primary router, and it must be enabled before Router 2 and Router 3 can be enabled. The Router 1 manual area address and System ID create the NSAP address assigned to the node’s TID. In addition, Router 1 supports OSI TARP, mediation, and tunneling functions that are not supported by Router 2 and Router 3. These include:

TID-to-NSAP resolution

TARP data cache

IP-over-CLNS tunnels

FTAM

FT-TD

T-TD

LAN subnet

OSI virtual router constraints depend on the routing mode provisioned for the node.
Table 13-13 shows the number of IS L1s, IS L1/L2s, and DCCs that are supported by each router. An IS Level1 and IS Level1/Level2 support one ES per DCC subnet and up to 100 ESs per LAN subnet.

Table 13-13 OSI Virtual Router Constraints

Routing Mode

Router 1

Router 2

Router 3

IS L1

per area

IS L1/L2

per area

DCC

per IS

End System

Yes

No

No

—

—

—

IS L1

Yes

Yes

Yes

250

—

40

IS L1/L2

Yes

Yes

Yes

250

50

40

Each OSI virtual router has a primary manual area address. You can also create two additional manual area addresses. These manual area addresses can be used to:

Split up an area—Nodes within a given area can accumulate to a point that they are difficult to manage, cause excessive traffic, or threaten to exceed the usable address space for an area. Additional manual area addresses can be assigned so that you can smoothly partition a network into separate areas without disrupting service.

Merge areas—Use transitional area addresses to merge as many as three separate areas into a single area that shares a common area address.

Change to a different address—You might need to change an area address for a particular group of nodes. Use multiple manual area addresses to allow incoming traffic intended for an old area address to continue being routed to associated nodes.

13.6.8 IP-over-CLNS Tunnels

IP-over-CLNS tunnels are used to encapsulate IP for transport across OSI NEs. The ONS 15454 supports two tunnel types:

GRE—Generic Routing Encapsulation is a tunneling protocol that encapsulates one network layer for transport across another. GRE tunnels add both a CLNS header and a GRE header to the tunnel frames. GRE tunnels are supported by Cisco routers and some other vendor NEs.

Figure 13-24shows the protocol flow when an IP-over-CLNS tunnel is created through four NEs (A, B, C, and D). The tunnel ends are configured on NEs A and D, which support both IP and OSI. NEs B and C only support OSI, so they only route the OSI packets.

Figure 13-27 IP-over-CLNS Tunnel Flow

13.6.8.1 Provisioning IP-over-CLNS Tunnels

IP-over-CLNS tunnels must be carefully planned to prevent nodes from losing visibility or connectivity. Before you begin a tunnel, verify that the tunnel type, either Cisco IP or GRE, is supported by the equipment at the other end. Always verify IP and NSAP addresses. Provisioning of IP-over-CLNS tunnels in CTC is performed on the node view Provisioning > OSI > IP over CLNS Tunnels tab. For procedures, refer to the “Turn Up a Node” chapter in the
Cisco ONS 15454 Procedure Guide
.

Provisioning IP-over-CLNS tunnels on Cisco routers requires the following prerequisite tasks, as well as other OSI provisioning:

(Required) Enable IS-IS

(Optional) Enable routing for an area on an interface

(Optional) Assign multiple area addresses

(Optional) Configure IS-IS interface parameters

(Optional) Configure miscellaneous IS-IS parameters

The Cisco IOS commands used to create IP-over-CLNS tunnels (CTunnels) are shown in
Table 13-14.

Table 13-14 IP-over-CLNS Tunnel IOS Commands

Step

Step

Purpose

1

Router (config) #
interface ctunnel
interface-number

Creates a virtual interface to transport IP over a CLNS tunnel and enters interface configuration mode. The interface number must be unique for each CTunnel interface.

2

Router (config-if #
ctunnel destination
remote-nsap-address

Configures the destination parameter for the CTunnel. Specifies the destination NSAP1 address of the CTunnel, where the IP packets are extracted.

3

Router (config-if) #
ip address
ip-address mask

Sets the primary or secondary IP address for an interface.

If you are provisioning an IP-over-CLNS tunnel on a Cisco router, always follow procedures provided in the Cisco IOS documentation for the router you are provisioning. For information about ISO CLNS provisioning including IP-over-CLNS tunnels, see the “Configuring ISO CLNS” chapter in the
Cisco IOS Apollo Domain, Banyon VINES, DECnet, ISO CLNS, and XNS Configuration Guide
.

13.6.8.2 IP-over-CLNS Tunnel Scenario 1: ONS Node to Other Vendor GNE

Figure 13-28 shows an IP-over-CLNS tunnel created from an ONS node to another vendor GNE. The other vendor NE has an IP connection to an IP DCN to which a CTC computer is attached. An OSI-only (LAP-D) SDCC and a GRE tunnel are created between the ONS NE 1 to the other vender GNE.

13.6.8.3 IP-over-CLNS Tunnel Scenario 2: ONS Node to Router

Figure 13-29 shows an IP-over-CLNS tunnel from an ONS node to a router. The other vendor NE has an OSI connection to a router on an IP DCN, to which a CTC computer is attached. An OSI-only (LAP-D) SDCC is created between the ONS NE 1 and the other vender GNE. The OSI over IP tunnel can be either the Cisco IP tunnel or a GRE tunnel, depending on the tunnel types supported by the router.

ONS NE 1 IP-over-CLNS tunnel provisioning:

Destination: 10.10.30.10 (Router 1, Interface 0/1)

Mask: 255.255.255.255 for host route (Router 1 only), or 255.255.255.0 for subnet route (all routers on the same subnet)

Figure 13-30 shows an IP-over-CLNS tunnel from an ONS node to a router across an OSI DCN. The other vendor NE has an OSI connection to an IP DCN to which a CTC computer is attached. An OSI-only (LAP-D) SDCC is created between the ONS NE 1 and the other vender GNE. The OSI over IP tunnel can be either the Cisco IP tunnel or a GRE tunnel, depending on the tunnel types supported by the router.

ONS NE 1 IP-over-CLNS tunnel provisioning:

Destination: Router 2 IP address

Mask: 255.255.255.255 for host route (CTC 1 only), or 255.255.255.0 for subnet route (all CTC computers on the same subnet)

13.6.9 OSI/IP Networking Scenarios

The following eight scenarios show examples of ONS 15454s in networks with OSI-based NEs. The scenarios show ONS 15454 nodes in a variety of roles. The scenarios assume the following:

ONS 15454 NEs are configured as dual OSI and IP nodes with both IP and NSAP addresses. They run both OSPF and OSI (IS-IS or ES-IS) routing protocols as “Ships-In-The-Night,” with no route redistribution.

ONS 15454 NEs run TARP, which allows them to resolve a TL1 TID to a NSAP address. A TID might resolve to both an IP and an NSAP address when the destination TID is an ONS 15454 NE that has both IP and NSAP address.

DCC links between ONS 15454 NEs and OSI-only NEs run the full OSI stack over LAP-D, which includes IS-IS, ES-IS, and TARP.

DCC links between ONS 15454 NEs run the full OSI stack and IP (OSPF) over PPP.

All ONS 15454 NEs participating in an OSI network run OSI over PPP between themselves. This is needed so that other vendor GNEs can route TL1 commands to all ONS 15454 NEs participating in the OSI network.

OSI/IP Scenario 2 (Figure 13-32) shows an ONS 15454 GNE in a multivendor OSI network. Both the ONS 15454 GNE and the other vendor NEs are managed by an IP OSS using TL1 and FTP. The ONS 15454 is also managed by CTC and Cisco Transport Manager (CTM). Because the other vendor NE only supports TL1 and FTAM over the full OSI stack, the ONS 15454 GNE provides T–TD and FT–TD mediation to convert TL1/IP to TL1/OSI and FTAM/OSI to FTP/IP.

DCCs between the ONS 15454 GNE and ONS 15454 NEs are provisioned for IP and OSI over PPP.

4

DCCs between the ONS 15454 GNE and other vendor NEs are provisioned for OSI over LAP-D.

5

The ONS 15454 and the other vendor NE network include IP over OSPF and OSI over the IS-IS protocol.

The ONS 15454 GNE routes TL1 traffic to the correct NE by resolving the TL1 TID to either an IP or NSAP address. For TL1 traffic to other vendor NEs (OSI-only nodes), the TID is resolved to an NSAP address. The ONS 15454 GNE passes the TL1 to the mediation function, which encapsulates it over the full OSI stack and routes it to the destination using the IS-IS protocol.

For TL1 traffic to ONS 15454 NEs, the TID is resolved to both an IP and an NSAP address. The ONS 15454 GNE follows the current TL1 processing model and forwards the request to the destination NE using the TCP/IP stack and OSPF routing.

OSS-initiated software downloads consist of two parts: the OSS to destination NE TL1 download request and the file transfer. The TL1 request is handled the same as described in the previous paragraph. The ONS 15454 NEs use FTP for file transfers. OSI-only NEs use FTAM to perform file transfers. The FTAM protocol is carried over OSI between the OSI NE and the ONS 15454 GNE. The GNE mediation translates between FTAM to FTP.

In OSI/IP Scenario 3 (Figure 13-33), all TL1 traffic between the OSS and GNE is exchanged over the IP DCN. TL1 traffic targeted for the GNE is processed locally. All other TL1 traffic is forwarded to the OSI stack, which performs IP-to-OSI TL1 translation. The TL1 is encapsulated in the full OSI stack and sent to the target NE over the DCC. The GNE can route to any node within the IS-IS domain because all NEs, ONS 15454 and non-ONS 15454, have NSAP addresses and support IS-IS routing.

TL1 traffic received by an ONS 15454 NE and not addressed to its NSAP address is forwarded by IS-IS routing to the correct destination. TL1 traffic received by an ONS 15454 NE and addressed to its NSAP is sent up the OSI stack to the mediation function, which extracts the TL1 and passes it to the ONS 15454 TL1 processor.

An OSS initiated software download includes the OSS-to-destination node TL1 download request and the file transfer. The TL1 request is handled as described in the previous paragraph. The target node uses FTAM for file transfers because the GNE does not support IP on the DCC and cannot forward FTP. The ONS 15454 NEs therefore must support an FTAM client and initiate file transfer using FTAM when subtended to an OSI GNE.

In this scenario, the GNE has both IP and OSI DCN connections. The GNE only supports TL1 and FTP over IP. Both are translated and then carried over OSI to the destination ENE (ONS 15454 or OSI-only NE). All other IP traffic is discarded by the GNE. The CTC/CTM IP traffic is carried over an IP-over-OSI tunnel to an ONS 15454 NE. The tunnel is created between an external router and an ONS 15454 NE. The traffic is sent to the ONS 15454 terminating the tunnel. That ONS 15454 then forwards the traffic over the tunnel to CTC/CTM by way of the external router.

The other vendor GNE performs mediation for TL1 and FTP, so the DCCs to ONS 15454 and other vendor NEs are OSI-only.

4

CTC/CTM communicates with ONS 15454 NEs over an IP-over-CLNS tunnel between the ONS 15454 and the GNE.

5

ONS 15454 NEs exchange TL1 over the full OSI stack. FTAM is used for file transfer.

13.6.9.4 OSI/IP Scenario 4: Multiple ONS DCC Areas

OSI/IP Scenario 4 (Figure 13-35) is similar to OSI/IP Scenario 3 except that the OSI GNE is subtended by multiple isolated ONS 15454 areas. A separate IP-over-CLNS tunnel is required to each isolated ONS 15454 OSPF area. An alternate approach is to create a single IP-over-CLNS tunnel from CTC/CTM to an ONS 15454 NE, and then to configure a tunnel from that NE to an NE in each isolated OSPF area. This approach requires additional static routes.

Figure 13-35 OSI/IP Scenario 4: Multiple ONS DCC Areas

1

The IP OSS manages ONS 15454 and other vendor NEs using TL1 and FTP.

2

A separate tunnel is created for each isolated ONS 15454 DCC area.

13.6.9.5 OSI/IP Scenario 5: GNE Without an OSI DCC Connection

OSI/IP Scenario 5 (Figure 13-36) is similar to OSI/IP Scenario 3 except that the OSI GNE only has an IP connection to the DCN. It does not have an OSI DCN connection to carry CTC/CTM IP traffic through an IP-over-OSI tunnel. A separate DCN to ONS 15454 NE connection is created to provide CTC/CTM access.

Figure 13-36 OSI/IP Scenario 5: GNE Without an OSI DCC Connection

1

The IP OSS manages ONS 15454 and other vendor NEs using TL1 and FTP.

2

The other vendor GNE performs mediation on TL1 and FTP, so DCCs are OSI-only.

CTC/CTM communicates with the ONS 15454 over a IP-over-CLNS tunnel between the ONS 15454 NE and external router.

In European networks:

CTC and CTM are used for management only.

IP-over-CLNS tunnels are widely accepted and deployed.

TL1 management is not required.

FTP file transfer is not required.

TL1 and FTAM to FTP mediation is not required.

Management traffic between CTC/CTM and ONS 15454 NEs is carried over an IP-over-CLNS tunnel. A static route is configured on the ONS 15454 that terminates the tunnel (ONS 15454 NE 1) so that downstream ONS 15454 NEs (ONS 15454 NE 2 and 3) know how to reach CTC/CTM.

OSI/IP Scenario 8 (Figure 13-39) is another example of a European network. Similar to OSI/IP Scenario 7, the ONS 15454 NEs are solely managed by CTC/CTM. The CTC/CTM IP traffic is carried over a IP-over-OSI tunnel between an external router and the ONS 15454 GNE. The GNE extracts the IP from the tunnel and forwards it to the destination ONS 15454. Management traffic between the OSS and other vendor NEs is routed by the ONS 15454 GNE and NEs. This is possible because all ONS 15454 NEs run dual stacks (OSI and IP).

CTC/CTM communicates with the ONS 15454 over an IP-over-CLNS tunnel between the ONS 15454 NE and the external router. A static route is needed on the GNE.

4

The ONS 15454 GNE routes OSI traffic to other vendor NEs. No IP-over-CLNS tunnel is needed.

13.6.10 Provisioning OSI in CTC

Table 13-15 shows the OSI actions that are performed from the node view Provisioning tab. Refer to the
Cisco ONS 15454 Procedure Guide
for OSI procedures and tasks.

Table 13-15 OSI Actions from the CTC Provisioning Tab

Tab

Actions

OSI > Main Setup

View and edit Primary Area Address.

Change OSI routing mode.

Change LSP buffers.

OSI > TARP > Config

Configure the TARP parameters:

PDU L1/L2 propagation and origination.

TARP data cache and loop detection buffer.

LAN storm suppression.

Type 4 PDU on startup.

TARP timers: LDB, T1, T2, T3, T4.

OSI > TARP > Static TDC

Add and delete static TARP data cache entries.

OSI > TARP > MAT

Add and delete static manual area table entries.

OSI > Routers > Setup

Enable and disable routers.

Add, delete, and edit manual area addresses.

OSI > Routers > Subnets

Edit SDCC, LDCC, and LAN subnets that are provisioned for OSI.

OSI > Tunnels

Add, delete, and edit Cisco and IP-over-CLNS tunnels.

Comm Channels > SDCC

Add OSI configuration to an SDCC.

Choose the data link layer protocol, PPP or LAP-D.

Comm Channels > LDCC

Add OSI configuration to an SDCC.

Table 13-16 shows the OSI actions that are performed from the node view Maintenance tab.

Table 13-16 OSI Actions from the CTC Maintenance Tab

Tab

Actions

OSI > ISIS RIB

View the IS-IS routing table.

OSI > ESIS RIB

View ESs that are attached to ISs.

OSI > TDC

View the TARP data cache and identify static and dynamic entries.

Perform TID to NSAP resolutions.

Flush the TDC.

13.7 IPv6 Network Compatibility

IPv6 simplifies IP configuration and administration and has a larger address space than IPv4 to support the future growth of the Internet and Internet related technologies. It uses 128-bit addresses as against the 32-bit used in IPv4 addresses. Also, IPv6 gives more flexibility in designing newer addressing architectures.

Cisco ONS 15454 can function in an IPv6 network when an Internet router that supports Network Address Translation-Protocol Translation (NAT-PT) is positioned between the GNE, such as an ONS 15454, and the client workstation. NAT-PT is a migration tool that helps users transition from IPv4 networks to IPv6 networks. NAT-PT is defined in RFC-2766. IPv4 and IPv6 nodes communicate with each other using NAT-PT by allowing both IPv6 and IPv4 stacks to interface between the IPv6 DCN and the IPv4 DCC networks.

Note IPv6 is supported on Cisco ONS 15454 Software R8.0 and later with an external NAT-PT router.

13.8 IPv6 Native Support

Cisco ONS 15454 Software R9.0 and later supports native IPv6. ONS 15454 can be managed over IPv6 DCN networks by enabling the IPv6 feature. After you enable IPv6 in addition to IPv4, you can use CTC, TL1, and SNMP over an IPv6 DCN to manage ONS 15454. Each NE can be assigned an IPv6 address in addition to the IPv4 address. You can access the NE by entering the IPv4 address, an IPv6 address or the DNS name of the device. The IPv6 address is assigned only on the LAN interface of the NE. DCC/GCC interfaces use the IPv4 address.

By default, when IPv6 is enabled, the node processes both IPv4 and IPv6 packets on the LAN interface. If you want to process only IPv6 packets, you need to disable IPv4 on the node. Before you disable IPv4, ensure that IPv6 is enabled and the node is not in multishelf mode.

You can manage MSTP multishelf nodes over IPv6 DCN. RADIUS, FTP, SNTP, and other network applications support IPv6 DCN. To enable IPv6 addresses, you need to make the necessary configuration changes from the CTC or TL1 management interface. After you enable IPv6, you can start a CTC or TL1 session using the provisioned IPv6 address. The ports used for all IPv6 connections to the node are the same as the ports used for IPv4.

An NE can either be in IPv6 mode or IPv4 mode. In IPv4 mode, the LAN interface does not have an IPv6 address assigned to it. An NE, whether it is IPv4 or IPv6, has an IPv4 address and subnet mask. TCC2/TCC2P cards do not reboot automatically when you provision an IPv6 address, but a change in IPv4 address initiates a TCC2/TCC2P card reset.
Table 13-17 describes the differences between an IPv4 node and an IPv6 node.

Table 13-17 Differences Between an IPv6 Node and an IPv4 Node

IPv6 Node

IPv4 Node

Has both IPv6 address and IPv4 address assigned to its craft Ethernet interface.

Does not have an IPv6 address assigned to its craft Ethernet interface.

The default router has an IPv6 address for IPv6 connectivity, and an IPv4 address for IPv4 connectivity.

The default router has an IPv4 address.

Cannot enable OSPF on LAN. Cannot change IPv4 NE to IPv6 NE if OSPF is enabled on the LAN.

Can enable OSPF on the LAN.

Cannot enable RIP on the LAN. Cannot change IPv4 NE to IPv6 NE if RIP is enabled on the LAN.

Can enable static routes/RIP on the LAN.

Not supported on static routes, proxy tunnels, and firewall tunnels.

Supported on static routes, proxy tunnels, and firewall tunnels.

Routing decisions are based on the default IPv6 router provisioned.

13.8.1 IPv6 Enabled Mode

The default IP address configured on the node is IPv4. You can use either CTC or the TL1 management interface to enable IPv6. For more information about enabling IPv6 from the CTC interface, see the
Cisco ONS 15454 Procedure Guide
. For more information about enabling IPv6 using TL1 commands, see the
Cisco ONS SONET TL1 Command Guide
.

13.8.2 IPv6 Disabled Mode

You can disable IPv6 either from the CTC or from the TL1 management interface. For more information about disabling IPv6 from the CTC interface, see the
Cisco ONS 15454 Procedure Guide
. For more information about disabling IPv6 using TL1 commands, see the
Cisco ONS SONET TL1 Command Guide
.

13.8.3 IPv6 in Non-secure Mode

In non-secure mode, IPv6 is supported on the front and the rear Ethernet interfaces. You can start a CTC or TL1 session using the IPv6 address provisioned on the on the front and rear ports of the NE.

13.8.4 IPv6 in Secure Mode

In secure mode, IPv6 is only supported on the rear Ethernet interface. The front port only supports IPv4 even if it is disabled on the rear Ethernet interface. For more information about provisioning IPv6 addresses in secure mode, see the
Cisco ONS 15454 Procedure Guide
. For more information on secure mode behavior, see the “IP Scenario 9: IP Addressing with Secure Mode Enabled” section.

13.8.5 IPv6 Limitations

IPv6 has the following configuration restrictions:

You can provision an NE as IPv6 enabled only if the node is a SOCKS-enabled or firewall-enabled GNE/ENE.

IPSec is not supported.

OSPF/RIP cannot be enabled on the LAN interface if the NE is provisioned as an IPv6 node.

Static route/firewall/proxy tunnel provisioning is applicable only to IPv4 addresses even if the IPv6 is enabled.

In secure mode, IPv6 is supported only on the rear Ethernet interface. IPv6 is not supported on the front port.

ONS platforms use NAT-PT internally for providing IPv6 native support. NAT-PT uses the IPv4 address range 128.x.x.x for packet translation. Do not use the 128.x.x.x address range when you enable IPv6 feature.

13.9 FTP Support for ENE Database Backup

The Cisco ONS 15454 provides FTP database backup and restore download to ENEs when proxy/firewall is enabled. This feature allows you to provision a list of legal FTP hosts in CTC, that can be used with TL1 commands to perform database backup/restore or software download. The FTP hosts can be provisioned to elapse after a specified time interval with the enable FTP relay function.

Once FTP host are provisioned, and FTP Relay is enabled, TL1 users can then use the COPY-RFILE command to perform database backup/restore or software download to and from this list of legal FTP hosts that are provisioned to ENEs. Also, TL1 supports TID to IP address translation for the GNE TID that is specified in the FTP URL of COPY-RFILE and COPY-IOSCFG commands.

Using the FTP Host provisioning feature in CTC and TL1 you can configure up to 12 valid FTP hosts.

ENEs are allowed access through the firewall according to the time configured in the FTP Relay Timer in CTC or TL1. The time interval is 1 to 60 minutes, and once the timer elapses, all FTP access to the FTP host is blocked again. A time of 0 disallows ENE access to FTP commands through the firewall.

When the firewall is not enabled (Proxy only), all FTP operations to the ENE will be allowed – software download, database backup/restore and IOS config file backup/restore. All FTP operations to the ENEs will be blocked when firewall is enabled.