Changes between Initial Version and Version 1 of Ciena Core Director switch component manager interface

Timestamp:

10/19/09 13:48:06 (15 years ago)

Author:

Christopher Small

Comment:

--

Ciena Core Director switch component manager interface

@@ +1 @@
+= Authors =
+[https://wiki.ittc.ku.edu/gpeni_wiki/index.php/User:Pangu '''Pragatheeswaran Angu'''], University of Nebraska-Lincoln[[BR]]
+[https://wiki.ittc.ku.edu/gpeni_wiki/index.php/User:Byrav '''Dr. Byrav Ramamurthy'''], University of Nebraska-Lincoln[[BR]]
+
+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 ==
+
+[[Image(cdci.png, 600px)]]
+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.
+
+[[Image(nodemanager.png, 800px)]]
+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
+
+=== 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
+
+=== 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.[[BR]]
+
+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.
+
+[[Image(osrp.png, 600px)]]
+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 ==
+
+[[Image(subnetcontrol.png, 800px)]]
+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:'''
+
+{{{
+#!rst
++--------------------------------+--------------------------------+
+|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:'''
+  
+{{{
+#!rst
++----------------------------------------------------------------+----------------------------------------------------------------+
+|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 [[BR]]
+DRAGON/DCN - Xi Yang [[BR]]
+MAX/MANFRED - Chris Tracy [[BR]]
+
+= References =
+
+ 1. [https://wiki.ittc.ku.edu/gpeni_wiki/images/7/78/CoreDirector_TL1_Document.pdf CoreDirector CI MultiService Switch TL1 Interface Manual (R5.2.6)]
+ 2. [https://wiki.ittc.ku.edu/gpeni_wiki/images/1/12/NodeManagerUserGuide.pdf CI MultiService Switch Node Manager User Guide (R5.2.6)]
+ 3. [https://wiki.ittc.ku.edu/gpeni_wiki/images/0/0e/CoreDirector_System_Description.pdf CI MultiService Switch System Description (R5.2.6)]
+ 4. [https://wiki.internet2.edu/confluence/download/attachments/19074/narb-rce-architecture-v2.1b.pdf?version=1 NetworkAware Resource Broker (NARB) and Resource Computation Element (RCE) Architecture] [[BR]]
+ 5. https://wiki.internet2.edu/confluence/display/DCNSS/Home [[BR]]
+ 6. http://dragon.maxgigapop.net/twiki/bin/view/DRAGON/WebHome [[BR]]
+ 7. http://en.wikipedia.org/wiki/Transaction_Language_1[[BR]]