wiki:Ciena Core Director switch component manager interface

Version 1 (modified by Christopher Small, 10 years ago) (diff)

--

Authors

''Pragatheeswaran Angu'', University of Nebraska-Lincoln
''Dr. Byrav Ramamurthy'', University of Nebraska-Lincoln

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

CoreDirector CI System Description

Overview

The CoreDirector Multi-Service Switch and CoreDirector CI Multi-Service Switch delivers a wide range of optical capacities and a variety of protection options. 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. These switches support OC-3/12/STM-1/4, OC-48/STM-16, OC-192/STM-64 optical interfaces, STM-1e electrical interfaces and Gigabit Ethernet interfaces. The switch matrix architecture is designed to operate on a single wavelength or the composite signals of a single wavelength.

Switching Capacity

For smaller core or larger metropolitan central offices, the CoreDirector CI Switch delivers up to 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. The CoreDirector CI Switch can use a combination of these interface types to achieve the total capacity.

The CoreDirector CI Switch handle both Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) optical interfaces. The Transport Bandwidth Unit (TBU) is the minimum granularity of switched bandwidth in the CoreDirector Switch. Each TBU corresponds to a clear-channel bandwidth of approximately 52.56 megabits per second (Mb/s). For SONET interfaces, each 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.

Hardware Overview

No image "cdci.png" attached to Ciena Core Director switch component manager interface Figure 1: Hardware Overview

The CoreDirector CI Switch consists of a chassis containing:

  • 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.

The display panel is at the top of the chassis, and the blower modules are below the display panel. The fans provide filtered cooling airflow from the bottom of the system up through the chassis, then exhaust the warm air through top front and rear vents. The shelf is below the fans, and the PDU is at the lower back of the chassis.

A fully populated CoreDirector CI Switch contains eight Line Modules, two Control Modules, two Timing Modules, and four Switch Modules. These are located on the same shelf and share a common backplane.

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

Line Modules

CoreDirector Line Modules provide bidirectional ports, either through integrated optical ports, installed Optical Modules, or integrated electrical ports. The Line Modules also contain part of the switching fabric for the switch. 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.

Optical Modules and Ethernet Interfaces

The following 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

Control Modules

Two Control Modules are installed in the CoreDirector Switch to serve as the central system controllers. At any given time, only one Control Module is active; the other is in standby mode to be used if a failure occurs in the active (primary) one. A hard drive on each Control Module provides persistent (nonvolatile) storage for all configuration data. The Control Modules contain external user interface ports.

Timing Modules

The CoreDirector Switch is equipped with two Timing Modules that perform the network timing and switch fabric synchronization functions for the system. Each Timing Module contains a Stratum 3E clock whose output is used to time all 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.

Switch Modules

Switch Modules provide the central part of the system switching fabric. (The other part of the switching fabric is on the Line Modules.) 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.

Software Overview

CoreDirector embedded operating software contains all the features and functionality necessary for the CoreDirector Switch and CoreDirector CI Switch to be used in a variety of network applications. CoreDirector provides the flexibility to support a wide range of network applications by offering multiple protection and restoration schemes as well as intelligent, end-to-end service provisioning across multiple bandwidth sizes, ranging from STS-1/VC-3 to STS-192c/VC-4-64c.

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

Management Interfaces

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

Node Manager

The CoreDirector Node Manager application provides a GUI that allows users from any point in a network to manage or configure operation of the CoreDirector CI Switches, including connections, provisioning, protection, and statistical collection at the network element level. 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.

Figure 2: Node Manager Software

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

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

Toolbar

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

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.

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.

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.

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.

Transaction Language 1 (TL1)

TL1 is a text-based human and machine protocol developed in the 1980s by Bellcore (now known as Telcordia Technologies, Inc.). TL1 is a standardized set of American Standard Code for Information Interchange (ASCII) telecommunications network management commands and messages. TL1 was developed as a subset adaptation of the International Telecommunications Union Telecommunications (ITU-T) recommendation for machine-to-machine environments. TL1 is used by most manufacturers of network elements.

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.

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 semicolon

The 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.

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

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 following example:

  1. SID DATE TIME
  2. M MYCTAG COMPLD
  3. "A-1-1:NEND,S&J&O,15-MIN"
  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.

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:

<acknowledgmentcode>^<ctag><cr><lf>

TL1 acknowledgment codes are as follows:

  • IP - In progress
  • RL - Repeat later
  • NA - No acknowledgment
  • PF - Printout follows

Error Messages and Codes

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

Autonomous Messages

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

Configurations & Provisioning

CoreDirector configuring and provisioning commands are used to create, configure, modify, and delete physical ports, subnetwork connections, Open Systems Interconnection (OSI) protocols, Optical Signaling and Routing Protocol (OSRP) links, cross connects, facilities, and equipment. 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.

Configuration

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.

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.

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.

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.

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.

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.

Provisioning

OSRP

OSRP allows networked CoreDirector Switches to communicate, share topology information, and calculate routes for individual connections. OSRP is a key technology component behind FastMesh™ Add-On Software Package and automatic circuit provisioning capability.

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 primary purpose of OSRP is to facilitate rapid connection provisioning and mesh restoration. These connections can have a variety of protection requirements, such as requiring the connection to traverse only linear 1:N or ring-protected spans or the establishment of restoration priority levels. OSRP supports two types of provisioning: explicitly routed connections and automatically routed connections.

Explicitly Routed Connection

Explicitly routed connections contain user-defined routes that OSRP provisions. In this provisioning mode, the explicit route for the working path and an optional set of protection routes are defined as preferred or exclusive routes. (Routes provided by the user must still satisfy the routing constraints associated with the connection, such as required protection class and maximum end-to-end delay.)

Automatically Routed Connection

Automatically routed connections contain OSRP-defined routes that OSRP also provisions. Working and protection paths are automatically computed based on the existing network conditions, user-specified connection constraints, and class of service. OSRP provisions the end-to-end connection, creates dynamic cross connects across the network, and manages the connection as a single end-to-end entity. After the connections are provisioned, the working route becomes the connection's home route; protected traffic can revert to the home route if that option is enabled. The protection path can be shared by other end-to-end connections, and OSRP regularly recomputes the protection path (approximately every 30 seconds) to take changes in network conditions into account.

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.

No image "osrp.png" attached to Ciena Core Director switch component manager interface Figure 3: OSRP

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.

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.

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

End Points

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

DRAGON/DCN interface for CoreDirector

DRAGON software is part of the DCN Software Suite and is utilized as the Domain Controller (DC) for the Internet2 Dynamic Circuit Network (DCN). The DRAGON software enables the dynamic control of multiple dataplane technologies. This includes various Ethernet switches, Ciena Core Directors, or a topology which includes a mix of both. This 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.

The network of CoreDirector's(CD) are controlled under the Subnet Control Model. Unlike the Ethernet switch case that a VLSR only controls one switch, VLSR under this model can control multiple CDs. It uses TL1 to connect to source and/or destination CD to create a subnet- connection (SNC) and map Ethernet flows into time slots in the SNC. Depending on the location of source and destination CDs, it is possible to have one or two VLSRs involved in creation of the SNC. When the source and destination are on the same CD node, a VLSR will create cross-connect (CRS) instead of SNC.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.

Subnet Control Model

Figure 4: Subnet Control

This is a special type of networking model that allows a subnet to be embedded into a domain. The purpose of this subnet control model is to harness the native control capabilities of vendor-specific subnets. The advantage in so doing is that we can use the vendor’s native control for reliability and simplicity while still maintaining the integrity of the overall GMPLS control plane. For example, the Internet2 Dynamic Circuit Network (DCN) has a subnet of Ciena CoreDirector SONET switches, which provide flexible Ethernet-to-SONET mapping at every switch. The CoreDirector switches have robust Ethernet service provisioning capability between two edge ports via TL1 or GMPLS based OIF UNI interfaces. The idea is to make use of such native provisioning capability without going through the hassles to control the subnet from inside. By overlaying one or more Subnet Controlling VLSRs on top of the subnet, it is possible to control from edge to edge via standard interfaces such as OIF UNI or via vendor’s native control API.

The implications of this model for NARB/RCE design include the following. Firstly, RCE needs to have a detailed view of the Subnet topology so it can compute a deterministic path across the subnet. Secondly, RCE needs to incorporate the Subnet topology into the domain topology since the two topologies come from different sources and bridging links need to be identified or created in order to carry out crossing-layer path computation. Thirdly, NARB/RCE needs to map the data-flow path into a signaling-flow path because the actual signaling flow traverses the VLSR level instead of the Subnet level. The number of Subnet VLSRs can range from one to the number of Subnet switches, but usually less than the latter number so one VLSR may correspond to multiple subnet switches. This separation of signaling flow from data flow is not only the nature of GMPLS control-plane separation but also a separation of DRAGON VLSR level control from vendor-specific Subnet level control, which makes the Subnet Control Model unique.

In addition to the VLSR-level ERO, the NARB/RCE path computation also generates a subnet ERO for a domain with a subnet. The subnet ERO can be returned to a client upon request. The client can therefore learn subnet-level path details. Also, a subnet ERO can be used to guarantee a deterministic, explicit path across the subnet during signaling time. This is particularly important for book-ahead or scheduled services. Subnet ERO can be converted into any vendor-specific explicit route representation, such as the Designated Transit List (DTL) for Ciena CoreDirector subnets.

When combined with vendor-specific subnet signaling features, a subnet ERO or its converted form can help eliminate inconsistent routing paths between scheduling and signaling.

List of TL1 Commands

The 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:       |Creates the Virtual             |
|503062::,pst=IS,suppttp=1-A-5-1,|Concatenation Group in the      |
|crctype=CRC_32,,,               |interface 1-A-5-1 with name     |
|framingmode=GFP,                |vcg_503062. This command        |
|tunnelpeertype=NONE,,,gfpfcs,   |specifies that STS slots from 1 |
|enabled=YES,,,groupmem=1&&21,,; |to 21 forms this VCG group. It  |
|                                |means the capacity of the VCG   |
|                                |is nearly 1 Gig                 |
+--------------------------------+--------------------------------+
|ent-eflow::eflow_vcg_503062_in: |Creates a new Ethernet Eflow.   |
|503063:::ingressporttype=ettp,  |An Eflow classifies a group of  |
|ingressportname=1-A-5-1-1,      |packets entering a specific     |
|pkttype=single_vlan_tag,        |layer 2 port and controls the   |
|outervlanidrange=3060,,         |packets modification and        |
|priority=1&&8,                  |routing. This command uses VLAN |
|egressporttype=vcg,             |id 3060 for classification of   |
|egressportname=vcg_503062,      |packets. It means all the       |
|cosmapping=cos_port_default;    |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:|This command creates the Eflow  |
|503064:::ingressporttype=vcg,   |in the reverse direction of the |
|ingressportname=vcg_503062,     |previous command. Hence a 2 way |
|pkttype=single_vlan_tag,        |Eflow is created between the    |
|outervlanidrange=3060,,         |VCG group created and the port  |
|priority=1&&8,                  |1-A-5-1-1                       |
|egressporttype=ettp,            |                                |
|egressportname=1-A-5-1-1,       |                                |
|cosmapping=cos_port_default;    |                                |
+--------------------------------+--------------------------------+

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,           |Creates the Virtual Concatenation Group in the interface        |
|crctype=CRC_32,,,framingmode=GFP,tunnelpeertype=NONE,,,         |1-A-6-1 with name vcg_3062. This command specifies that STS     |
|gfpfcsenabled=YES,,,groupmem=1&&21,,;                           |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,       |Creates a new Ethernet Eflow. This also classifies the packets  |
|ingressportname=1-A-6-1-1,pkttype=single_vlan_tag,              |based on VLAN id 3060. It means to all the incoming packets     |
|outervlanidrange=3060,,priority=1&&8,                           |associated with the VCG group vcg_3062,is attached VLAN tag of  |
|egressporttype=vcg,egressportname=vcg_3062,                     |3060 and transmitted to the destination via port 1-A-6-1-1      |
|cosmapping=cos_port_default;                                    |                                                                |
+----------------------------------------------------------------+----------------------------------------------------------------+
|ent-gtp::gtp_3065:3065::lbl=gtp-vcg_3062,,ctp=vcg_3062-CTP-1&   |Creates a GTP with 21 STS1 ie of capacity 1 Gig                 |
|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&[[BR]]vcg_3062-CTP-19&vcg_3062-CTP-20&          |                                                                |
|vcg_3062-CTP-21;                                                |                                                                |
+----------------------------------------------------------------+----------------------------------------------------------------+
|ent-snc-stspc:CHIC:gtp_3065,1-A-5-1-1&&21:3066::name=snc_3066,  |Creates a Subnetwork Connection from source NE CHIC to remote   |
|type=dynamic,rmnode=NEWY,lep=gtp_nametype,conndir=bi_direction, |NE NEWY. This is the command that actually creates a circuit of |
|prtt=aps_vlsr_unprotected,pst=is;                               |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

Acknowledgements

Ciena - Ronald Jones
DRAGON/DCN - Xi Yang
MAX/MANFRED - Chris Tracy

References

  1. CoreDirector CI MultiService Switch TL1 Interface Manual (R5.2.6)
  2. CI MultiService Switch Node Manager User Guide (R5.2.6)
  3. 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[[BR]]

Attachments (4)

Download all attachments as: .zip