CoreDirector Component Manager InterfacePragatheeswaran Angu and Byrav Ramamurthy

Department of Computer Science and Engineering

University of Nebraska – Lincoln.

{pangu,byrav}@cse.unl.edu

(with acknowledgements to Ciena, DRAGON/DCN (USC/ISI) and MAX/MANFRED)

Acknowledgement:

The description of the features of CoreDirector have been obtained from the CoreDirector manual documents [1], [2] and [3]

1. CoreDirector CI System Description

1.1 OverviewA wide range of optical capacities and protection mechanisms are being offered by both the CoreDirector Multi-Service Switch and CoreDirector CI Multi-Service Switch. CoreDirector Switches

are intelligent switches that provide unmatched, managed capacity and bandwidth density. They

provide nonblocking, bidirectional switching capacity that can be configured to switch and groom traffic from any input port to any output port down to the STS-1/VC-3 level. OC-3/12/STM-1/4, OC-

48/STM-16, OC-192/STM-64 optical interfaces, STM-1e electrical interfaces and Gigabit Ethernet interfaces are supported by these switches.

1.2 Switching CapacityCoreDirector optical switch offers upto 160 Gbps of switching capacity using a maximum of 16 OC-

192/STM-64 optical interfaces, 64 OC-48/STM-16 optical interfaces, or 128 OC-3/12/STM-1/4 optical

interfaces. A combination of these interfaces can also be used to achieve this capacity.

It handles both Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH). Minimum granularity of bandwidth used in the switch is called transport bandwidth unit (TBU). Each

TBU is of 52.56 Mbps and for SONET interfaces TBU supports one STS-1 signal. In a fully configured CoreDirector CI Switch with SONET/SDH interfaces, a total of 3072 STS-1/VC-3 circuits can be

established between ports.

1.3 Hardware OverviewThe following are the elements of chassis:

• A single shelf housing all Line, Control, Switch, and Timing Modules• Modular display panel

• Two blower modules• Power distribution unit

• I/O module, either SONET-DS1 (T1) or SDH-E1

The CoreDirector CI Switch is designed to be installed in a standard Electronic Industries Alliance

(EIA) 23-inch equipment rack. At the top is the display panel and blower modules are below the display panel. The shelf is below the fans, and the PDU is at the lower back of the chassis.

There are eight line modules, two control modules, two timing modules and four switch modules

located on the same shelf and share a common backplane.

(source: System Description Document [3])

Figure 1: Hardware Overview

1.3.1 Modules in the CoreDirector Switches

The CoreDirector Switches contain the following types of modules:

• Line Modules

• Optical Modules and Ethernet Interfaces• Control Modules

• Timing Modules• Switch Modules

1.3.1.1 Line Modules

Integrated optical ports or integrated electrical ports act as bidirectional ports. A part of the switching fabric is also contained in the line modules. Some Line Modules have integrated

(nonremovable) ports. The LM-16 Line Module has 16 integrated optical ports; the LM-16e Line Module has 16 ports to support STM-1e electrical interface; the LM-20-GE Gigabit Ethernet service

Line Module accepts 20 replaceable transceivers, Ethernet Services Line Module (ESLM) provides a single 10G port group supporting 10 Gigabit Ethernet ports or a single 10GbE port. The LM-8 Line

Module can have up to eight installed Optical Modules; the LM-2 Line Module accommodates two Optical Modules. The optical connections are accessed from the front of the rack.

1.3.1.2 Optical Modules and Ethernet Interfaces

The following are the types of Optical Modules are available:

• Short Reach (SR), Intermediate/Medium Reach/ (IR/MR), and Long Reach (LR1 and LR2)

OC-48/STM-16 Optical Modules• MR OC-3/12 STM-1/4 Optical Modules

• SR1, SR2, IR/MR, and LR2 OC-192/STM-64 Optical Modules• OC-192/STM-64 Optical Modules with Dense Wavelength Division Multiplexing

(DWDM)capability• OM1GE-850-SXL-A

• OM1GE-1310-LXL-A• GbE SX and LX Transceivers

• 10GbE SR, LR and ER Transceivers

1.3.1.3 Control Modules

There are two control modules in the CoreDirector optical switch to act as the central system controllers. One one control module is active at any given point of time and the other one acts a stanby one. The standby controller can be used as a backup for the primary one in case of failures. Each controller also has a hard drive for storage and ports to interface with user.

1.3.1.4 Timing Modules

There are two timing modules for performing network timing and switch fabric synchronization

functions for the system. There is a Stratum 3E clock in each timing module and its output is used to time all the outgoing optical signals. For SONET networks, the reference for the Timing Module clock

can be any optical input or a Building Integrated Timing Source (BITS) input. For SDH networks, the reference for the Timing Module clock can be any optical input or Synchronization Supply Unit (SSU)

input.

In the absence of a qualified input, the clock can operate in the holdover mode. One Timing Module

is primary, and the other is used in the event of a failure of the primary Timing Module.

1.3.1.5 Switch Modules

Switch Modules provide the central part of the system switching fabric. Each Switch Module has

paths to all Line Modules. In the CoreDirector Switch, the Switch Modules are installed in a chassis-wide shelf between the Line Module shelves. In the CoreDirector CI system, the Switch Modules

occupy part of the middle of the single system shelf. The exact number of Switch Modules in a CoreDirector system depends on the system configuration. The CoreDirector Switch accommodates

up to 15 installed Switch Modules; the CoreDirector CI Switch accommodates up to four Switch Modules.

1.4 Software OverviewThe embedded operating software is flexible enough to support a variety of network applications which includes multiple protection and restoration schemes. It also includes the end to end service

provisioning of various bandwidth sizes ranging from STS-1/VC-3 to STS-192c/VC-4-64c.

1.4.1 Features of the CoreDirector Software Packages

CoreDirector Cross Connect software enables basic optical cross connect capabilities for simple

wavelength switching and automated patch panel applications. This infrastructure package provides the following basic capabilities:

• Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Operations Administration, Maintenance, and Provisioning (OAM&P)

• 1+1; 1:N Automatic Protection Switching/Multiplex Section Protection (APS/MSP) protectionswitching, Ethernet Port Protection, Equipment Protection Switching

• Timing and synchronization• Node Manager Graphical User Interface (GUI)

• Transaction Language One (TL1) Management• Data Plane Fault Isolation (DPFI)

• Timing Plane Fault Isolation (TPFI)• Data Communications Network (DCN) access management

• Audit logs• Circuit test capabilities

CoreDirector - Ring software adds the following ring protection capabilities to those of the

CoreDirector Cross Connect software package:

• Two-Fiber Bi-directional Line Switched Ring/Two-Fiber Multiplex Section Shared Protection

Ring (2F-BLSR/MS-SPRing)• Four-Fiber Bi-directional Line Switched Ring/Four-Fiber Multiplex Section Shared

Protection Ring (4F-BLSR/MS-SPRing)• Virtual Line Switched Ring (VLSR)

• Asymmetric Virtual Line Switched Ring (A-VLSR)• Transoceanic Line Switched Ring (TLSR) (G.841 protection)

• Unidirectional Path Switched Ring/Subnetwork Connection Protection (UPSR/SNCP)

CoreDirector - Mesh software adds the following optical switching and mesh protection capabilities to the CoreDirector Cross Connect software package:

• Optical Signal and Routing Protocol (OSRP) functionality

• Point-and click auto-provisioning• Automatic route computation

• Network (topology) autodiscovery• Link aggregation for large network scalability

• Mesh protection (FastMesh™)• Protection service classes

• Multiple protection bundle IDs

2 Management Interfaces

(source: Node Manager User Guide [2])

Figure 2: NodeManger GUI interface

The CoreDirector CI can be managed using two interfaces: Node Manager and TL1.

2.1 Node ManagerThe GUI is used to configure the operation of CoreDirector CI switches remotely. This includes cross connection, protection and the port configurations. It also permits craft personnel to monitor and

verify all aspects of the connected node element operation and hardware configuration and to access historical data about alarms, links, routing, system alarms, and network activity.

The Node Manager screen is divided into the following six sections:

• Menu Bar

• Toolbar• Status Bar

• Equipment Tree• List Frame

• Details Frame• Database Synchronization Status Bar

2.1.1 Menu Bar

The menu bar is located at the top of the main window beneath the title bar. The menu bar consists of six functions File, View, Go, Action, Tools and Help

2.1.2 Toolbar

The toolbar provides icons for navigating quickly to the Node Manager screens.

2.1.3 Status Bar

The status bar is located below the menu bar. The status bar consists of Alarm Light Emitting Diodes

(LEDs), Alarm Data bar, the Screen Name box, and Active and Standby LEDs.

2.1.4 Equipment Tree

The equipment tree is located on the left side panel of the Node Manager window beneath the status

bar. The equipment tree identifies the CoreDirector Switch hardware, such as the bay, shelf, and line modules. When an object is selected on the equipment tree, its corresponding information is

displayed in the List frame.

2.1.5 List Frame

The List frame provides summary information about the item selected in the equipment tree. All List

frame elements are read-only. To view detailed information about an object in the List frame, the user selects the object; information about that object is displayed in the Details frame (to deselect an

item, the user presses CTRL and left-clicks the mouse). To sort objects in the List frame, the user clicks the column heading. This sorts the column in ascending order (indicated by a black up arrow in

the column heading). To sort the column in descending order (indicated by a black down arrow in the column heading), the user clicks the column heading again. To unsort objects, the user right-clicks on

the column heading.

2.1.6 Database Synchronization Status Bar

The Database Synchronization status bar is located at the bottom of the screen. The left side of the

status bar lists the last database synchronization operation. The right side of the status bar displays the DB status icon when database synchronization is in progress.

2.2 Transaction Language 1 (TL1)TL1 is protocol developed by Bellcore in 1980. TL1 is a standardized set of American Standard Code for Information Interchange (ASCII) telecommunications network management commands and

messages. TL1 is a subset adaptation of International Telecommunications Union Telecommunications (ITU-T) recommendation for machine to machine environment.

2.2.1 Accessing TL1 on the CoreDirector Switch

Telnet is used to access CoreDirector TL1 software from a remote location, or after connecting a laptop to the Ethernet port on the CoreDirector Switch.

STEP 1: Obtain the Internet Protocol (IP) address of the intended CoreDirector Switch and verify

connectivity to the intended CoreDirector system.

STEP 2: Telnet to the CoreDirector Switch from the DOS prompt of the PC. From the prompt of a DOS terminal window, type the Telnet command, a blank space, the CoreDirector IP address, a blank

space, and the TL1 port number 10201.

2.2.2 TL1 Input Conventions

TL1 input commands are composed of the command type (a verb) followed by command modifiers

and blocks. Input commands can contain up to 512 alphanumeric characters.

All commands consist of the following:

• TL1 command name

• CoreDirector Target Identifier TID• Correlation Tag (CTAG)

• A semicolonThe TID is the unique name, limited to 20 alphabetical characters, that is assigned to the

CoreDirector Switch during CoreDirector system setup and configuration.

As an example of a TL1 command input and response, a user with account name “BOBSMITH” and password “bobs2E” can start a TL1 session on a Network Element (NE) or TID named

“CoreDirector777” by entering the following command (using the CTAG “Myctag”):

ACT-USER:COREDIRECTOR777:BOBSMITH:Myctag::bobs2E;

The semicolon at the end of the command line indicates the end of the command input. The

CoreDirector system sends a command acknowledgement indicating that the command is in progress (IP):

IP Myctag<

If the command is entered correctly and no errors are encountered, the CoreDirector Switch

processes the command and issues a completed (COMPLD) response;

otherwise, the CoreDirector Switch provides an error code and an explanation.

2.2.3 TL1 Output Conventions

CoreDirector Switch outputs messages and command responses in plain text (ASCII). TL1 returns any

of the following four types of responses and messages to commands:

• Normal Responses

• Acknowledgement Messages• Error Messages and Codes

• Autonomous Messages

2.2.3.1 Normal Responses

Normal responses to commands are distinguished by an uppercase letter M as the first character of

the second line of the response.

A response message may contain anywhere from three to hundreds of lines of text. If non-zero data

is available for requested parameters, a normal response report is displayed as indicated in the followingexample:

line 1 SID DATE TIME

line 2 M MYCTAG COMPLD line 3 "A-1-1:NEND,S&J&O,15-MIN"

line 4;

Line 1 indicates the source, date, and time of the response.Line 2 indicates the status of the response with the correlation tag and the completion code as

follows: COMPLD - Completed (or normal)

DENY - Denied (or error) PRTL - Partial response

Line 3 displays the specified report data or error codes (for example, ENEQ, IPNV, and so forth). The TL1 Interface Manual provides additional detailed information on error codes.

Line 4 displays a semicolon (;) to indicate the end of the response.

2.2.3.2 Acknowledgement Messages

The CoreDirector Switch returns an acknowledgment message if the system is unable to issue a

NORMAL or DENY response within 2 seconds of receiving the input command. An acknowledgment response is repeated every 20 seconds until concluded with a NORMAL or DENY message.

The acknowledgment response message structure is as follows:

<acknowledgment code>^<ctag><cr><lf>

TL1 acknowledgment codes are as follows:

IP - In progress

RL - Repeat later NA - No acknowledgment

PF - Printout follows

2.2.3.3 Error Messages and Codes

TL1 input command error codes are four-character codes generated in response to the user’s input

commands.

2.2.3.4 Autonomous Messages

Autonomous messages are generated by the CoreDirector Switch to report alarms or events automatically.

3 Configurations & ProvisioningThe configuration and provisioning commands can be used to create, configure, modify and delete physical ports, Open Systems Interconnection (OSI) protocols, Optical Signaling and Routing Protocol

(OSRP) links, cross connects, facilities, equipment and subnetwork connections. It is possible to do the configuration and provisioning using either Node Manager interface or TL1 commands. In this

section we give a brief description of the basic configurations and provisioning needed to operate the CoreDirector CI in the GpENI network from the view of Node Manager.

3.1 Configuration

3.1.1 Physical Termination Points (PTPs)

The Physical TP screen consists of up to seven tabs (Basic, DCC, Fault, Performance, Section Trace, LW Peer Comms, and Physical) that provide PTP information. The number of tabs available is

determined by the type of Optical Module (OM) or port and is driven by the OM or port capabilities. If the tree selection is not valid (for example when a LM is selected in the equipment tree), Node

Manager displays a blank screen with a message "Not a valid screen for current selection".

Port Groups (Basic—Port Group) has one tab (Basic) which is unique to Ethernet Port Groups. All remaining OMs and ports have at least five tabs (Basic, DCC, Fault, Performance, and Section Trace).

OC-192 OMs have up to two additional tabs (LW Peer Comms and Physical).

All OC-192 OMs have the Physical tab OM10G-WDM1 modules also have LW Peer. Basic is the default tab.

3.1.2 Group Termination Points (GTPs)

A GTP is a defined set of STS-1/AU-3 CTPs or STS3c/AU-4 CTPs that are configured and treated as a single entity. For example, if multiple STS-1/AU-3 CTPs are cross-connected in the same manner,

creating a GTP facilitates provisioning by requiring only a single cross connect for all CTPs in the group. From the Group TPs screen, GTPs are created from individual CTPs, and existing CTPs can be

added or removed from a GTP.

3.1.3 Connection Termination Points (CTPs)

CTPs are logical connection points used for manual cross-connecting and automated provisioning of end-to-end circuits. CTPs are composed of one or more STS-1or VC-3 time slots.

3.1.4 Ethernet Trail Termination Point (ETTP)

An ETTP is automatically created for each port when an LM-20-GE or ESLM is inserted. ETTPs contain the provisioning and monitoring related to the ethernet protocol and have states, provisioning

attributes, alarms and performance monitoring thresholds and counts which are retrievable and editable by the user by way of the ETTP screen.

3.1.5 Ethernet Flow (Eflow)

An Eflow represents the unidirectional stream of packets that originate and terminate on given Ethernet Ports or VCGs and is used for routing and priority assignment for mapping ETTPs within a

port group. An Eflow classifies a group of packets entering a specific layer 2 port and controls the packets modification and routing.

3.1.6 Ethernet Virtual Concatenation Group (VCG)

An Ethernet VCG consists of one or more CTPs/GTPs/SNCs. The default vlan id parameter specifies the vlan id assigned to packets arriving on this interface. This also maps to the default VLAN tag to

be applied to the packet if a tag is to be added to the packet and an explicit tag value is not provided.

3.2 Provisioning

3.2.1 OSRP

OSRP is used to share topology information, communicate and calculate routes for any individual connection request.

OSRP key features include:

• Constraint-based routing• Automatic network topology discovery (network topology auto-discovery)

• Automatic connection configuration and setup (end-to-end provisioning)• OSRP link aggregation

• Multiple protection bundle ID• Interface to Modeling and Planning Suite (MPS) for network optimization, traffic

engineering, and capacity planning

The major use of OSRP is to facilitate fast connection provisioning and mesh restoration. These connections have a large range of protection requirements such as 1:N or ring protected spans.

OSRP supports two types of provisioning: explicitly routed connections and automatically routed connections.

3.2.1.1 Explicitly Routed Connection

Explicitly routed connections has routes which are user defined and hence the user gives the full set of working and protection routes to the system.

3.2.1.2 Automatically Routed Connection

(source: System Description [3])

Figure 3: OSRP

In this the OSRP defines the working and protection routes based on path constraint. The routes are

computed based on the existing network conditions, user specified connection constraints and class of service. These connections automatically create the cross connects across every equipment in the

path, thus providing end to end connection. It finds both the working path and a set of protection paths. The working path becomes the home route for the connection whereas the protection path

can be shared by the other end to end OSRP connections.

Automatic connections begin at the originating node.The above figure illustrates how a connection is configured and provisioned. This example shows a request to connect Endpoint X and Endpoint Y. The

connection is configured at CoreDirector Switch #1. OSRP computes the route and automatically creates cross connects on CoreDirector Switches #1, #2, #5, and #4 as it sends traffic to the

destination port.

Automatically routed connections can be manually regroomed at any time. The regrooming operation

attempts to locate a new optimal path through the network according to user-specified constraints, such as least cost. If a more optimal route is found, the regrooming operation establishes the

connection across the new home route and takes the existing connection out of service.

3.2.2 Subnetwork Connections (SNCs)

There are three types of SNCs: dynamic, permanent, and SNCP Auto CrossConnect.

A dynamic SNC is an end-to-end circuit whose path can traverse any number of nodes and can

change over time. The route for dynamic SNCs can be automatically computed by OSRP, or it can be a user-provisioned explicit route. Dynamic SNCs can also be provisioned with revertive and mesh-

restorable attributes.

A Permanent SNC (or PSNC) is a fixed end-to-end circuit. A PSNC connection can use an explicit, exclusive user-defined routing profile. When a line failure occurs, the P-SNC remains connected and a

SNC-Unavailable alarm is generated. An explicit change in the physical path where one end point of a physical link belonging to the PSNC’s path changes (such as link misconnection, node removal, or

node insertion) is perceived as a conscious action on the part of the user and results in the immediate release of the PSNC. PSNCs are not mesh-restorable, cannot have a routing profile

consisting of protected line routes, and cannot be manually regroomed. PSNCs can participate in APS/MSP, BLSR, SmartRing™ VLSR, or MS- SPRing protection.

A Subnetwork Connection Protection (SNCP) is a type of SNC that is 1+1 protected across the

network using the SNCP protocol. A head-end bridge function transmits two copies of the path signal across the network while a tail-end select function selects the better of two received path signals.

3.2.3 Cross Connect Provisioning and Connection Management

A cross connect is a port-to-port connection contained within the CoreDirector Switch. The two types of cross connects are static and dynamic.

Static, or manual, cross connects are user-provisioned, fixed connections between an originating and

a terminating end point on a single node.

Dynamic cross connects are established and cleared within each CoreDirector Switch in support of an SNC. This type of cross connect cannot be manually provisioned or deleted. A dynamic cross connect

is automatically created along the path that the SNC takes through the network and can be mesh-restored.

CoreDirector Cross Connect supports the following cross connect manual provisioning features:

• Standards-based static cross connect control

• Path-level cross connects from any SONET STS-1/STS-3c/STS-12c/STS-48c to any STS-1/STS-3c/STS-12c/STS-48c or from any SDH VC3/VC4/VC4-4c/VC4-16c/VC4-64c to any VC3/VC4/VC4-

4c/VC4-16c/VC4-64c (in other words, any time slot of any port to any time slot of an port)• Port-to-port cross connects from any SONET OC-3/OC-12/OC-48 to any OC-3/OC-12/OC-48 or

from any SDH STM1/STM4/STM16/STM64 to any STM1/STM4/STM16/STM64 (transparent to path level tributaries)

• Linear APS or Multiplex Section Protection (MSP) for all cross connectsManual cross connect capability of STS-192c/VC4-64c signals

• Support for arbitrary concatenation (STS-21c/VC4-7c for GigE transport)• SONET/SDH manual cross connects for international gateway applications (applicable with

theSONET/SDH Gateway Utility)The cross connect (path level) end points must be at compatible rates. For example, a VC-4 on an STM-1 can be cross connected to an STS-3c on

an OC-48.• Automatic S-bit translation between SONET and SDH interfaces

3.2.3.1 End Points

The end point of a cross connect can be either a Connection Termination Point (CTP) or a Group Termination Point (GTP).

4 DRAGON/DCN interface for CoreDirectorDRAGON is a control plane software developed by MAX and is part of the ION software suite. The DRAGON acts as the domain controller in the ION software suite. DRAGON enables creation of

dynamic circuits across various domains. The DRGON supports variety of Ethernet and Optical switches and hence can support a topology which is a mix of both. his section explains the

mechanism of how DRAGON/DCN software controls the CoreDirector CI in Internet2/ESnet network and also the the list of TL1 commands used for provisioning the CoreDirector switches. This

document assumes basic familiarity with DRAGON/DCN software.

A network of CoreDirector's(CD) are managed under the term Subnet Control Model. In this model a single VLSR can control multiple CD's in contrast to the traditional model in which one VLSR is used

to control one switch. The DRAGON software uses the TL1 interface to connect to the source and destination node to initiate the subnet-connection (SNC). A cross connection will be created if the

source and destination are on the same CoreDirector. Currently Ciena TDM layer subnet topology information is loaded into NARB/RCE via a static configuration file (/usr/local/etc/ciena_subnet.conf).

The Core Director Ethernet edge ports information is configured in /usr/local/etc/ospfd.conf on the controlling VLSRs. NARB/RCE will associate the Ethernet ports with TDM layer topology for cross-layer

path computation. Topology states will be updated based on path computation and provisioning results. The following is the detailed explanation of subnet control model.

4.1 Subnet Control Model

(Source: NARB document [4])

Figure 4: Subnet Control

This model takes advantage of the control capabilities of the vendor-specific subnets to embed a subnet into a domain. The native capacities of vendor provides reliability and simplicity in addition to the integrity provided by the standard GMPLC control plane. The subnet of CoreDirector in Internet2 is a

good example of such a subnet in which the CD provides the mapping of Ethernet-to-SONET at every switch. CoreDirector has the capability to create subnet between two Ethernet edge ports using TL1 or GMPLS based OIF UNI interfaces. Hence the VLSR control plane acts as a overlay and can manage the end to end subnet between edge ports using native subnet creation facility of CD.

There are three implications of this model for NARB/RCE design. They are

1) RCE must know the complete information of the subnet topology so that it can compute a deterministic path between source and destination across the subnet.

2) The subnet topology needs to be integrated into the domain topology by RCE since the source of both the topologies are different and hence bringing links need to be created to perform cross-layer path computation.

3) The data-flow path is mapped into the signal-flow path since the actual signal traverses through the VLSR instead of subnet.

A subnet ERO is generated in addition to the VLSR-level ERO by NARB/RCE path computation and only the subnet ERO is communicated to the client. Hence, a client is aware of the details of the subnet path and the subnet ERO also guarantees a deterministic and explicit path across the subnet. Conversion of subnet ERO to any vendor specific route is also possible in this model.

4.2 List of TL1 CommandsThe DRAGON software uses TL1 commands to provision CoreDirector switches to create DCN circuit across Internet2 network. The following is the list of TL1 commands used by the DRAGON to provision

circuit from source node CHIN to destination node NEWY in the Internet2 DCN network. The circuit provisioned uses VLAN tag 3060.

Visit destination node first via TL1 (NEWY) by telnet'ing to port 10201:

act-user::dragon:123::**PASSWORD**;inh-msg-all:::123;

Login via TL1 and inhibit all messages:

rtrv-vcg::all:503061;Retrieves the configuration settings for all the Virtual Concatenation Groups existing in the NE

rtrv-ocn::1-A-5-1:503062;Retrieves the configuration for the interface 1-A-5-1. The rate of the interface can be OC3,OC12,OC48 or OC192

ent-vcg::name=vcg_503062:503062::,pst=IS,suppttp=1-A-5-1 ,crctype=CRC_32,,,framingmode=GFP,tunnelpeertype=NONE,,,gfpfcs,enabled=YES,,,groupmem=1&&21,,;

Creates the Virtual Concatenation Group in the interface 1-A-5-1 with name vcg_503062. This command specifies that STS slots from 1 to 21 forms this VCG group. It means the capacity of the VCG is nearly 1 Gig

ent-eflow::eflow_vcg_503062_in:503063:::ingressporttype=ettp,ingressportname=1-A-5-1-

Creates a new Ethernet Eflow. An Eflow classifies a group of packets entering a specific layer 2 port and controls the packets modification and routing. This

1,pkttype=single_vlan_tag,outervlanidrange=3060,,priority=1&&8,egressporttype=vcg,egressportname=vcg_503062,cosmapping=cos_port_default;

command uses VLAN id 3060 for classification of packets. It means all the packets that is coming from the VCG group vcg_503062 is attached a VLAN tag of 3060 and is sent to source via port 1-A-5-1-1

ent-eflow::eflow_vcg_503062_out:503064:::ingressporttype=vcg,ingressportname=vcg_503062,pkttype=single_vlan_tag,outervlanidrange=3060,,priority=1&&8,egressporttype=ettp,egressportname=1-A-5-1-1,cosmapping=cos_port_default;

This command creates the Eflow in the reverse direction of the previous command. Hence a 2 way Eflow is created between the VCG group created and the port 1-A-5-1-1

Visit source node via TL1 (CHIN) again by telnet'ing to port 10201:

rtrv-vcg::all:3061;Retrieves the configuration settings for all the Virtual Concatenation Groups existing in the NE

rtrv-ocn::1-A-6-1:3062;Retrieves the configuration for the interface 1-A-6-1. The rate of the interface can be OC3,OC12,OC48 or OC192

ent-vcg::name=vcg_3062:3062::,pst=IS,suppttp=1-A-6-1,crctype=CRC_32,,,framingmode=GFP,tunnelpeertype=NONE,,,gfpfcsenabled=YES,,,groupmem=1&&21,,;5C

Creates the Virtual Concatenation Group in the interface 1-A-6-1 with name vcg_3062. This command specifies that STS slots from 1 to 21 forms this VCG group. It means the capacity of the VCG is nearly 1 Gig

ent-eflow::eflow_vcg_3062_in:3063:::ingressporttype=ettp,ingressportname=1-A-6-1-1,pkttype=single_vlan_tag,outervlanidrange=3060,,priority=1&&8,egressporttype=vcg,egressportname=vcg_3062,cosmapping=cos_port_default;

Creates a new Ethernet Eflow. This also classifies the packets based on VLAN id 3060. It means to all the incoming packets associated with the VCG group vcg_3062,is attached VLAN tag of 3060 and transmitted to the destination via port 1-A-6-1-1

ent-gtp::gtp_3065:3065::lbl=gtp-vcg_3062,,ctp=vcg_3062-CTP-1&vcg_3062-CTP-2&vcg_3062-CTP-3&vcg_3062-CTP-4&vcg_3062-CTP-5&vcg_3062-CTP-6&vcg_3062-CTP-7&vcg_3062-CTP-8&vcg_3062-CTP-9&vcg_3062-CTP-10&vcg_3062-CTP-11&vcg_3062-CTP-12&vcg_3062-CTP-13&vcg_3062-CTP-14&vcg_3062-CTP-15&vcg_3062-CTP-16&vcg_3062-CTP-17&vcg_3062-CTP-18&vcg_3062-CTP-19&vcg_3062-CTP-20&vcg_3062-CTP-21;

Creates a GTP with 21 STS1 ie of capacity 1 Gig

ent-snc-stspc:CHIC:gtp_3065,1-A-5-1- Creates a Subnetwork Connection from

1&&21:3066::name=snc_3066,type=dynamic,rmnode=NEWY,lep=gtp_nametype,conndir=bi_direction,prtt=aps_vlsr_unprotected,pst=is;

source NE CHIC to remote NE NEWY. This is the command that actually creates a circuit of capacity 1 Gig across the network between NE's CHIC and NEWY. This uses the OSRP protocol as described above

The following are the TL1 commands used to teardown the circuit provisioned above.

Teardown (on CHIN):

rtrv-snc-stspc::snc_3066:3067;Retrieves the Subnet connection with SNC id snc_3066

ed-snc-stspc::snc_3066:3068::,pst=oos;This command puts the SNC snc_3066 to state out of service

dlt-snc-stspc::snc_3066:3069; Deletes the SNC snc_3066

rtrv-gtp::gtp_3065:3070; Retrieves the GTP with gtp name gtp_3065

dlt-gtp::gtp_3065:3071; Deletes the GTP with gtp name gtp_3065

rtrv-vcg::vcg_3062:3072;Retrieves the parameters of VCG group vcg_3062

rtrv-eflow::eflow_vcg_3062_in:3073;Retrieves the parameters of Ethernet Eflow eflow_vcg_3062_in

dlt-eflow::eflow_vcg_3062_in:3074;Deletes the Eflow with name eflow_vcg_3062_in

dlt-eflow::eflow_vcg_3062_out:3075;Deletes the Eflow with name eflow_vcg_3062_out

ed-vcg::name=vcg_3062:3076::,pst=OOS;This command put the VCG group vcg_3062 to out of service

dlt-vcg::name=vcg_3062:3077; Deletes the VCG group vcg_3062

Teardown (on NEWY):

rtrv-vcg::vcg_503062:503065;Retrieves the parameters of VCG group vcg_503062

rtrv-snc-stspc::all:503065; Deletes all the SNC connection in the NE

rtrv-eflow::eflow_vcg_503062_in:503066;Retrieves the parameters of Ethernet Eflow eflow_vcg_503062_in

dlt-eflow::eflow_vcg_503062_in:503067;Deletes the Eflow with name eflow_vcg_503062_in

dlt-eflow::eflow_vcg_503062_out:503068;Deletes the Eflow with name eflow_vcg_503062_out

ed-vcg::name=vcg_503062:503069::,pst=OOS;This command put the VCG group vcg_503062 to out of service

dlt-vcg::name=vcg_503062:503070; Deletes the VCG group vcg_503062

5 AcknowledgementsCiena-Ronald JonesDRAGON/DCN - Xi Yang

MAX/MANFRED - Chris Tracy

6 References[1] CoreDirector CI MultiService Switch TL1 Interface Manual (R5.2.6)[2] CoreDirector CI MultiService Switch Node Manager User Guide (R5.2.6)

[3] CoreDirector CI MultiService Switch System Description (R5.2.6)[4] NetworkAware Resource Broker (NARB) and Resource Computation Element (RCE) Architecture

[5] https://wiki.internet2.edu/confluence/display/DCNSS/Home[6] http://dragon.maxgigapop.net/twiki/bin/view/DRAGON/WebHome

[7] http://en.wikipedia.org/wiki/Transaction_Language_1