Table Of Contents
Configuration for AAL2 Trunking Applications
Quick Start Procedure
PXM-45 Card Configuration
AXSM Card Configuration
VXSM Card Configuration
Create VXSM Resource Partition
Configuring the TDM Interface
Identifying Voice Circuits
Voice Interfaces (VIF)
Configuring the TDM Lines
Creating VXSM Trunks
Creating a Trunk Connection
Configuring AAL2 Trunks
CIDs
Subcell Multuplexing
Upspeed
Configuring HDLC Signaling AAL5 Trunks for Nx64 Format
Configuration for AAL2 Trunking Applications
A Cisco MGX 8880 and a Cisco MGX 8850 equipped with VXSMs and functioning as a media gateway can be configured to meet the requirements of an AAL2 trunking applications.
In AAL2 Trunking applications, the voice TDM interface and the packet network interface need to be configured. The trunking application involves VXSM cards, the PXM-45 card, and the AXSM cards. These cards all function together and must be configured accordingly.
VoATM trunking configuration consists of the following tasks.
•
PXM-45 card configuration
•
AXSM card configuration
•
VXSM card configuration
•
Provisioning Trunk PVCs
Quick Start Procedure
The following table shows a brief overview of the sequence of tasks and commands required to setup the media gateway for a VoATM Trunking application. The same procedure, but in greater detail, is presented later in this chapter.
Table 4-1 Configuration for Trunking
Major Task
|
Subtask/Commands
|
Basic node setup.
|
Basic PXM-45 setup commands
cnfname cnfdate cnftmzn cnftmznmgt cnftime addcontroller ipifconfig addsct
|
Setup the AXSM card(s)
|
AXSM Setup Commands
upln cnfln addport addpart
|
Setup VXSM card
|
Create VXSM resource partition
addrscptn
Config Voice Interfaces
addvif cnfpath -sts -payload (OC3 only) cnfvif
Bring up VXSM Lines
upln uppath -sts-1 -ds1 (OC3 only)
|
Create slave end of AAL2 bearer trunk connections on the local VXSM.
|
VXSM connection command
addcon
|
Create slave end of AAL5 HDLC signaling trunk connections on the local VXSM (if applicable)
|
VXSM connection command
addcon
|
Create master end of each AAL2 bearer trunk connection at remote VXSM.
|
Remote VXSM command
addcon
|
Create master end of each AAL5 HDLC signaling trunk connection at remote VXSM (if applicable)
|
Remote VXSM command
addcon
|
Configure AAL2 trunks to set up CIDs. If the application transports SS7 signaling across the network, use AAL2 profile CUSTOM 200 (clear channel)
|
VXSM addcid command
|
If using Nx64, configure AAL5 signaling trunks
|
addnx64prof addnx64aal5
|
Configure PNNI on PXM card
|
PXM commands
dnpnport cnfpnportsig uppnport
|
PXM-45 Card Configuration
Log on to the PXM-45 card and perform the following steps to configure the PXM-45 card for VoATM using the VXSM. The PXM-45 has a large number of commands. These steps deal only with the minimum commands required to setup the MGX 8850 as media gateway.
Step 1
Use the cnfname to give the MGX 8850 a node name.
unknown.7.PXM.a > cnfname <node name>
Enter up to 32 characters for the new node name, (node name is case-sensitive).
For example:
unknown.7.PXM.a > cnfname gateway1
After the user responds Yes to a confirmation request, the name is changed to gateway1
Step 2
Use the cnfdate command to set the date.
gateway1.7.PXM.a > cnfdate <mm/dd/yyyy>
Step 3
Use the cnftmzn command to set the time zone.
geteway1.7.PXM.a > cnftmzn <timezone>
Step 4
Use the cnftmzngmt command to set an offset if an offset from GMT is to be used.
geteway1.7.PXM.a > cnftmznmgt <timeoffsetGMT> Offset can be from -12 to +12.
Step 5
Use the cnftime command to enter the time.
geteway1.7.PXM.a > cnftime <hh:mm:ss>
Step 6
Use the addcontroller command to add a PNNI controller to the PXM-45 card
geteway1.7.PXM.a > addcontroller <cntrlrId> i <cntrlrType> <slot> [cntrlrName
cntrlrId is the controller ID, enter 2 to specify a PNNI controller.
cntrlrType is the controller type, enter 2 to specify a PNNI controller type.
slot is the PXM slot in the MGX 8850, enter 7 or 8 as appropriate.
cntrlrName is an optional controller name, enter a text name is desired.
Step 7
Use the ipifconfig command to specify a LAN IP address for the node.
geteway1.7.PXM.a > ipifconfig lnPci0 <IP_Addr><netmask <Mask>
Specify the values for the IP address and its associated netmask.
AXSM Card Configuration
Log on to the AXSM card and perform the following steps to configure the AXSM card for VoATM using the VXSM. The AXSM has a large number of commands. These steps deal only with the minimum commands required to setup the MGX 8850 as media gateway.
Step 1
Setup a Service Class Template (SCT) for the AXSM card. The SCT file name has the following format:
AXSM_SCT.CARD.2.V1
The SCT file must have been ftp'd to the node's PXM-45 disk in the C:SCT/TEMP directory
Use the dspctchksum command to display the checksum value of the file. Note the value of checksum
Note
A Service Class Template (SCT) is a collection of ATM configuration parameter settings that are stored in a single file and can be applied to multiple lines or ports. SCT files include the following types of configuration data:
General link parameters
COSB (Class of Service Buffers) parameters
Virtual circuit threshold parameters
COSB threshold parameters
Step 2
Use the cc command to switch to the active PXM-45 card.
Step 3
On the PXM-45 card, use the addsct to move the file to the F:SCT/AXSM directory on the PXM-45 disk. This has the effect of installing the SCT.
geteway1.10.AXSM.a > addsct <card type> <sct type> <sct ID> <Maj ver> <chksum>
cardtype is the card whose SCT you want to make available to the card by installing the SCT in the appropriate directory. Enter 1 for AXSM
scttype identifies either a port-level or a card-level SCT. Enter 2 for card level.
SCT ID refers to a specific service class template. The SCT is either provided by Cisco or created through CWM. Possible IDs are, Cisco-provided: 1-100 and User-created: 101-255. The default SCT ID is 0.
Maj ver is the major version number of the file. This number is assigned by Cisco.
checksum is the checksum for the file. Use the value obtained from the dspsctchksum command. The value is also published in the relevant release notes.
Step 4
While still logged into the PXM-45 card, repeat Steps 1 and 2 for the port SCT to be used by the PXM-45. In the addsct command specify 1 (port level) for the scttype parameter.
Step 5
Use the cc command to switch back to the AXSM card.
Step 6
Use the upln command to bring up the AXSM lines to be used by the gateway. This command establishes minimal connectivity over the line.
geteway1.10.AXSM.a > upln <bay.line>
For bay, enter 1 if the line on the back card is in the upper bay and enter 2 if it is in the lower bay. For line, enter the back card port number to which the line is connected.
Step 7
Use the cnfln command to configure a SONET lines.
geteway1.10.AXSM.a > cnfln -sonet <bay.line> -slt <LineType> -clk <clock source>
Enter the bay and line of the line being configured (see upln above). For LineType, enter 1 for SONET or 2 for SDH. For clockSource, enter 1 to use a clock received over the line from a remote node or 2 (the default) to use the local timing defined for the local node.
Step 8
Use the addport command to enable each ATM port to be used as a trunk for voice payload.
geteway1.10.AXSM.a > addport <ifNum> <bay.line> <guaranteedRate> <maxRate> <sctID>
<ifType>
For ifNum, enter a number from 1 to 60 to identify this interface. The interface number must be unique on the card to which it is assigned. For UNI and NNI ports, you can assign one logical interface per line.
For guaranteedRate and maxRate, enter an OC3 value in the range of 50 to 353207 cells per second.
For ifType, 1 specifies UNI, 2 specifies NNI. For trunking mode, each trunk port should be configured as NNI.
Step 9
Use the addpart command to create resource partition on the AXSM card. This command automatically creates a controller partition on the AXSM card. This command should be executed for each port that uses the controller.
geteway1.10.AXSM.a > addpart <ifNum> <partId> <ctrlrId> <egrminbw> <egrmaxbw> <ingminbw>
<ingmaxbw> <minVpi> <maxVpi> <minVci> <maxVci> <minConns> <maxConns>
For ifNum, enter the port number. For partId, enter 1 for PNNI. For cntrlid, enter 2 for PNNI.
The remaining parameters are used to specify maximum and minimum values for vpi/vci, bandwidth, connections, etc., see the Cisco MGX 8850 (PXM45 and PXM1E) Command Reference, Release 5 for details.
VXSM Card Configuration
Log on to the VXSM card and perform the following steps to configure the VXSM card for VoIP. The VXSM has a large number of commands. These steps deal only with the minimum commands required to setup the MGX 8850 as a media gateway
Create VXSM Resource Partition
Step 1
Use the addrscprtn command to create a resource partition for the VXSM card.
geteway1.5.VXSM.a > addrscprtn <ifNum> <partId> <ctrlrId> <egrminbw> <egrmaxbw> <ingminbw>
<ingmaxbw> <minVpi> <maxVpi> <minVci> <maxVci> <minConns> <maxConns>
For ifNum, enter 1 for port number. For partId, enter 1 for PNNI. For cntrlid, enter 2 for PNNI.
The remaining parameters are used to specify maximum and minimum values for vpi/vci, bandwidth, connections, etc., see the Cisco MGX 8850 (PXM45 and PXM1E) Command Reference, Release 5 for details.
Configuring the TDM Interface
Identifying Voice Circuits
Through the OC-3 and 48 T1/E1 versions of the VXSM, a variety of multiplexing schemes for interfacing to voice circuits are supported. These schemes fall into three major categories:
•
Multiplexing under the OC-3 standards.
•
Multiplexing under the SDH (Synchronous Digital Hierarchy) standards.
•
Multiplexing under the T1 and E1 standards.
VXSM provides the Configure Path (cnfpath) command to specify the multiplexing scheme to be used for each interface.
OC-3 Systems
Extracting a DS0 stream from the highly multiplexed bit stream of OC3 is performed using the relationships (paths) shown in Figure 4-1.
Figure 4-1 OC-3 Hierarchical Relationship
The bit stream interfaces with VXSM via one of the four physical lines in the OC3 back card. This interface is usually in the upper bay (but, when a redundant back card is used and is active, it is in the lower bay).
For a particular line, the OC3 stream consists of three paths and, depending upon the format, a path consists of either 7 virtual tributary groups (vtg) or 28 ds1s. A vtg can be further divided into either four virtual tributaries (version 1.5) or three virtual tributaries (version 2.0). The ds1 and the virtual tributaries (vt) consist of 24 T1 DS0s for T1 or 31 DS0s for E1.
As shown in the diagram, the relationship between DS0s and physical ports can take one of three paths. The paths are common between the physical line and STS-1 level. From the STS-1 level to the DS0, one of three paths can be taken.
The path that a particular ds1/DS0 will use can be configured by the user with the -payload parameter in the cnfpath -sts command. This parameter can be set to:
•
3 = ds3 (not applicable to SDH interface)—The path is carrying a DS3 payload.
•
4 = vt15vc11—The path is carrying a SONET-VT1.5/SDH-VC11 payload.
•
5 = vt20vc12—The path is carrying a SONET-VT2/SDH-VC12 payload.
Note
The vt1.5 path and the vt2.0 path also support SDH-VC11 and SDH-VC12 interfaces respectively.
Using the system described above, ds1 paths in VXSM commands are formatted as follows:
•
SONET path payload type VT1.5 or VT2.0
The ds1 is specified as: bay.line.path.vtg.vt
bay = upper of lower bay of the VXSM backcard.
line = the line number on the associated OC-3 card in the range 1 to 4.
path = the path of the virtual tributary in the range 1 to 3.
vtg = the virtual tributary groups applicable to the connection in the range 1 to 7.
vt = virtual tributaries in the range 1 to 4 for vt1.5 or 1 to 3 for vt2.0.
Caution
The combination of seven vtgs and four vts allows the specification of one of up to 28 DS1s. Be aware that VXSM supports two schemes for mapping a DS1 to a vtg/vt combination. These schemes are known as `standard' and `Titan' and are described in VTG/VT to DS1 Mapping Scheme.
vtg = the virtual tributary group.
vt = virtual tributary
•
SONET path payload type is ds3.
The ds1 is specified as: bay.line.path.ds3.ds1
bay = upper of lower bay of the VXSM backcard.
line = the line number on the associated OC-3 card in the range 1 to 4.
ds3 = the SONET (STS-1) path payload type as ds3 in the range 1 to 3.
ds1 = the ds1 channel within the ds3 interface in the range 1 to 28.
SDH Systems
The VXSM- 155 card supports voice circuits that are multiplexed according to the Synchronous Digital Hierarchy (SDH) standard. Each OC- 3 line presents the data stream as a 155.52 Mbps Synchronous Transport Module (STM-1).
Figure 4-2 shows the multiplexing paths between STM-1 at the physical line and the T1 or E1 voice circuits.
When using the SDH interface, the user must configure the path using the cnfpath -sts command. The format of this command is:
cnfpath -sts <bay.line.path> [-payload <Path Payload>] [-tm <Tributary Mapping Type>]
[-tg <Tributary Grouping>] [-txtrace <Transmit Trace>] [-extrace <Expect Trace>]
<bay.line.path>, specifies the bay (upper of lower back card), the physical line number on the back card, the path number between the STM and the AU (1, 2, or 3 for AU-3, 1 for AU-4)
-payload <Path Payload>, specifies the TU/VC combination (TU-11/VC-11 for T1 or TU-12/VC-12 for E1).
-tm<Tributary Mapping Type>, specifies the mapping mode, 1 = asynchronous mode or 2 = byteSynchronous mode.
-tg <Tributary Grouping>, specifies the tributary grouping This is a choice between AU-3 (the default) or AU-4.
2 = au3Grouping—Applicable to SDH interfaces: STM1, -AU-3, -TUG-2, -TU-12, -VC12 or STM1, -AU-3, -TUG-2, -TU-11, -VC11.
3 = au4Grouping—Applicable to SDH interfaces: STM1, -AU-4, -TUG-3, -TUG-2, -TU-12, -VC12 or STM1, -AU-4, -TUG-3, -TUG-2, -TU-11, -VC11.
Figure 4-2 SDH Hierarchical Relationships
24 T1/E1 Systems
In 24 T1/E1 systems, the ds1 is specified simply as: bay:line
bay = 1 or 2—1 for the upper bay, 2 for the lower bay.
line = 1 - 24—The T1 line on the backcard in the range 1 to 24.
Voice Interfaces (VIF)
A voice interface (vif) is a user configurable set of parameters that is applied to a group of ds0s within a ds1. The configuration settings of the vif are used by the digital signal processors (DSPs) to determine how a voice payload is to be processed by VXSM.
A voice interface is created using the addvif command. With this command the user specifies a vif number and its associated ds1, in addition, the type of signaling, the type of service (H.248 switching, trunking, etc.). Other bearer channel parameters such as echo cancellation and voice activity detection, are also specified. These parameters are contained within a vif which, when the vif is added, are assigned default values.
Once a vif is created, its parameters can be discovered using the dspvif command. There are also display and configure commands for the user to see and configure the various parameters.
An example of the addvif and dspvif commands is as follows:
The following command sequence adds a voice interface in a DS1 path for the VXSM card in slot 3 of the media gateway and then displays the results:
M8850_NY.3.VXSM.a > addvif 1.1.1.1.1 0 24 9 250
M8850_NY.3.VXSM.a > dspvif 1.1.1.1.1 0
======================================================
Configuration of DS0 Group in DS1
======================================================
To configure a vif perform the following steps.
Step 1
Use the dspvifs command to check that the vif exists. If it doesn't, use the addvif command to create the vif.
Step 2
For a particular ds1, use one of the display vif commands to display its associated vif parameter values. Determine which parameter (if any) need to be modified.
dspvif [<bay.line.path.vtg.vt >] | [<bay.line.path.ds3.ds1>] <ds0GroupId> for OC-3
dspvif <bay.line> <ds0GroupId> for 48 T1/E1
dspvifterms
dspvifterm [< bay.line.path.vtg.vt >] | [<bay.line.path.ds3.ds1>] <ds0GroupId> for OC-3
dspvifterm <bay.line> <ds0GroupId> for 48 T1/E1
dspvifparam <bay.line> <ds0GroupId> for 48 T1/E1
dspvifparams
Step 3
Use the following configure vif commands to modify vif parameters.
cnfvifparam <specified ds!> <ds0GroupId> <NoiseRegEnable> <NonLinearProcEnable> <MusicOnHoldThreshold> <ModemPassThru> <UpspeedCodec> <Repetition>
cnfvifterm <specified ds!> <ds0GroupId> <gatewayLinkId> <packageIds> <profileId>(Only applicable when service is H.248)
See the chapters entitled VXSM Commands for a description of the commands listed in steps 2 and 3.
Configuring the TDM Lines
Use the following steps to configure the TDM lines on the VXSM.
Step 1
For OC3 cards, use the -payload parameter in the cnfpath -sts command to specify the ds1 path with the OC3. The choices are ds3, vt1.5, and vt2.0.
cnfpath -sts<bay.line.path>[-payload <PathPayload>][-tm <TributaryMappingType>][-tg <TributaryGroupingType>][-txtrace <PathTraceToTransmit>][-exptrace <PathTraceToExpect]
<bay.line.path>
bay: 1
line: 1 - 4
path: 1 - 3 or 1 (AU4 only)
[-payload <PathPayload>]
3 - ds3
4 - vt15vc11
5 - vt20vc12
[-tm <TributaryMappingType>]
1 - asynchronous
2 - byteSynchronous (NA for ds3)
[-tg <TributaryGroupingType>]
1 - notApplicable (Sonet)
2 - au3Grouping (SDH)
3 - au4Grouping (SDH)
[-txtrace <PathTraceToTransmit>]
trace-string: size 16(SDH) or 64(Sonet)
[-exptrace <PathTraceToExpect]
trace-string: size 16(SDH) or 64(Sonet)
Step 2
Use the upln command to bring up a VXSM line.
geteway1.5.VXSM.a > upln <bay.line>
For bay, enter 1 for upper bay or 2 for uper bay.
For line, enter a value in the range 1 - 4 for OC3 or 1 - 24 for 48T1/E1.
Step 3
For OC3 cards, use the uppath command to specify the STS-1 path within the OC3
geteway1.5.VXSM.a > uppath -sts<bay.line.path>
For bay, enter 1 for upper bay or 2 for lower bay.
For line, enter a value between 1 and 4 to indicate the physical OC3 interface on the back card.
For path, enter a value between 1 and 3 to indicate the DS3 path within the OC3 interface.
Step 4
For OC3 cards, use the uppath command to specify the DS1 path within the DS3
geteway1.5.VXSM.a > uppath -ds1<bay.line.path.vtg/ds3.vt/ds1>
For bay, enter 1 for upper bay or 2 for upper bay.
For line, enter a value between 1 and 4 to indicate the physical OC3 interface on the back card.
For path, enter a value between 1 and 3 to indicate the DS3 path within the OC3 interface.
Note
vtg = the virtual tributary groups applicable to the connection.
vt = virtual tributaries
Step 5
Use the addvif command to add a voice interface for a DS0 group within a DS1.
For OC3 cards, the syntax of this command is:
addvif <LineNum> <Ds0GrpIndex> <Ds0BitMap> <ServiceType><BulkProvisionNumber>
Where:
LineNum -- (bay.line.path.vtg.vt or bay.line.path.ds1)
bay {1 - upper}
line (range=1..4)
path (range=1..3)
vtg (range=1..7)
vt (range=1..4)(ds1) (range=1..3)(e1)
ds1 (range=1..28)
Ds0GrpIndex -- DS0 group index
T1: (range=0..23)
E1: (range=0..30)
Ds0BitMap -- DS0 channel number
For trunkingService or DS0Xconn: single bit input
For H248: multiple bits input (e.g. 1-24 or 1,5,10-20)
T1: 1,2,3,...,24
E1: 1,2,3,...,31
ServiceType -- service type
8 - Trunking
9 - H248
10 - DS0Xconn
BulkProvisionNumber -- bulk provisioning number
Single DS0 configuration (range=1..8064(OC3)/1152(T1)/1488(E1))(default=1)
Multiple DS0 configuration (range=1..336(OC3)/48(T1E1))(default=1)
For 48T1/E1 cards the syntax of this command is the same as for OC3 except that the LineNumparameter is expressed as:
LineNum -- (bay.line)
bay {1 - upper}
line (range=1..24)
Creating VXSM Trunks
In trunking non-switching applications, an AAL2 PVC connection needs to be created for each bearer trunk to be supported. In addition, provision must be made for transporting signaling information across the network. HDLC signaling is transported using separate AAL5 PVCs; SS7 signaling is carried in the AAL2 PVC using the AAL2 custom profile of 200. All these connections extend between the VXSM cards at the local and remote endpoints of the trunk.
Creating a Trunk Connection
To make connections between a local VXSM and a remote VXSM card, perform the following procedure. This procedure should be performed for each trunk to be supported by the media gateway Each trunk requires a PVC for a bearer circuit and, if used, a separate PVC for signaling.
Two connections types can to be created.
•
The first type is AAL2 and is used for bearer circuits over the ATM network, up eight such PVCs can be configured.
•
The second type is HDLC/AAL5 and is used for CCS signaling (when used).
For each connection, select one end of the trunk as the slave and the other end as the master.
Step 1
On the VXSM card at the slave end, use the addcon command to configure the slave end of the connection.
geteway1.5.VXSM.a > addcon <ifNum> <vpi> <vci> <serviceType> <pvcType> <application>
<mastership>
[-slave <NSAP.vpi.vci>] [-lpcr <local PCR>] [-rpcr <remote PCR>] [-lscr <local SCR>]
[-rscr <remote PCR>] [-lmbs <local MBS>]......
For ifNum specify 1 as the interface number. For vpi and vci specify values in the ranges 0 to 255 and 0 to 65535 respectively. For service type, specify 1 (constant bit rate) or 2 (vbr-rt).
For pvc type, specify 1 (AAL5) if the connection is for CCS signaling or specify 2 (AAL2) if the connection is for bearer.
For application specify 3 for a CCS signaling connection or 2 for a bearer connection.
For mastership specify 2 for slave.
Omit the - slave parameter. The gateway will assign a value and display it as NSAP.VPI.VCI. The user should note the value and use it when adding the master end of the connection on the AXSM.
Of the remaining optional parameters, enter values or accept the defaults. These parameters are best set from the master end. See the CLI chapter for details.
Step 2
On the VXSM card at the master end, use the addcon command to configure the master end of the connection.
geteway1.5.VXSM.a > addcon <ifNum> <vpi> <vci> <serviceType> <pvcType> <application>
<mastership>
[-slave <NSAP.vpi.vci>] [-lpcr <local PCR>] [-rpcr <remote PCR>] [-lscr <local SCR>]
[-rscr <remote PCR>] [-lmbs <local MBS>]......
For ifNum, specify 1 as the interface number. For vpi and vci specify values in the ranges 0 to 255 and 0 to 65535 respectively. For service type, specify 1 (constant bit rate) or 2 (vbr-rt).
For mastership, specify 1 for master.
For the -slave parameter, enter the NSAP.VPI.VCI that was noted when configuring the slave end of the connection.
Of the remaining optional parameters, enter values or accept the defaults. See the CLI chapter for details.
Step 3
The path between the two VXSM cards, including the ports on the gateway AXSM cards and the intervening nodes is determined by PNNI. Use the dsppnport command to check that the ports on the gateway AXSM cards are enabled and configured for NNI.
Step 4
For each AXSM port that may be used as a trunk, use the cnfpnportsig command to setup the PNNI signaling on that port.
The port must be down to use this command. When a port is first created, its administrative state is down, in which there is no need to down it. If the port is up, do the following:
1.
De-activate the port by using the dnpnport command.
2.
Modify parameters as needed by using the cnfpnportsig command.
3.
Activate the port by using the uppnport command.
Use the cnfpnportsig command to configure the port as signaling NNI.
The syntax of this command is:
cnfpnportsig <portid> [-univer {uni30 | uni31 | uni40 | q2931 | none | self}] [-nniver {iisp30 | iisp31 | pnni10 | enni | aini}] [-unitype {public | private}] [-addrplan {both | aesa | e164}] [-side {user | network}] [-vpi <vpi>] [-sigvci signalling-vci] [-rccvci routing-vci] [-cntlvc {ip}] [-passalongcap {enable | disable}] [-hopcntgen {enable | disable}] [-vpivcialloc {enable | disable}] [-svcroutingpri <priority> ]
Table 4-2 cnfpnportsig parameters
portid
|
The format of the PNNI physical port identifier is as follows:
• On a PXM45: slot:subslot.port:subport
|
-univer
|
UNI is the default for a new PNNI port, but no default version exists for UNI. The UNI version can be uni30, uni31, uni40, q2931, none, or self. Note that to change a UNI version, the port must be down. After configuration, up the port by using the uppnport command.
Default: no default
|
-nniver
|
The NNI version: iisp30, iisp31, pnni10, aini, or enni. Note that univer and nniver are mutually exclusive—so the interface at each end of the connection must have the same interface type. Also, the port type on the PNNI controller must be the same as on the slave (through addport ifType on the AXSM, for example).
The default for this parameter is PNNI 1.0. If this version is sufficient, you can forego this parameter. However, to change an NNI version, the port must be down. Remember to up the port by using the uppnport command after completing the cnfpnportsig command.
|
-unitype
|
The type of UNI is either private or public. This parameter is relevant only if you specified a UNI interface through the -univer parameter.
Default: no default
|
-addrplan
|
The address plan of the calling party that the interface accepts. The choices are both, e164, and aesa. The default is both.
Only a public UNI can use this parameter.
|
-side
|
For the side of the port, type user or network. When you set up PNNI signalling for IISP, one end must be network and one end must be user. If both sides are the same, a configuration error has occurred. This parameter applies to IISP only and public UNI. The network side is the side that assigns the VPI and VCI. (An NNI automatically is the network side.)
Default: network
|
-vpi
|
The VPI of the signaling and routing control channel (RCC) on the port.
Range: 0-4095 Default: 0
|
-sigvci
|
The signaling VCI for the port. If you do not use the default of 5, this VCI must be in the range 32-65535.
Range: 5 or 32-65535 Default: 5
|
-rccvci
|
The routing control channel-vci: the VCI for PNNI RCC. If you do not use the default of 18, this VCI must be in the range 32-65535.
Range: 18 or 32-65535
Default: 18
|
-cntlvc
|
Enable for an IP-based signaling channel. This option applies only to a feeder connected to the switch. An IP-based control channel is mutually exclusive of either UNI or NNI. The only choice for -cntlvc is "ip."
Default: "ip" (for Internet Protocol)
|
-passalongcap
|
Pass-along capability: type "enable" or "disable." With this capability, the port has the ability to pass along unrecognized information elements (IEs) or messages. Enabling or disabling the pass-along capability applies to AINI, IISP, and public UNI. For all other types, the port behaves as if pass-along is enabled—you cannot disable pass-along on the other port types.
Default: enable
|
-hopcntgen
|
This parameter applies to AINI only. Type the entire word, "enable" or "disable." If you enable hop counting for AINI, the controller generates the hop counter information IE for all setup messages that pass through the interface if this IE does not already exist in the setup message. You must also enable AINI hop count IE for the switch by using the cnfainihopcount command.
Default: enable
|
-vpivcialloc
|
This parameter applies to AINI: type "enable" or "disable." If you enable it, the interface becomes responsible for assigning the VPI and VCI for all connections.
Note that if you enable VPI/VCI allocation on one side of the AINI link, allocation must be disabled on the other side of the link,
Default: enable
|
-svcroutingpri
|
The -svcroutingpri option lets you specify a default routing priority for a port. This parameter becomes relevant when a setup message for an SVC or SPVC arrives with no PSIE at a node that supports priority routing. For example, the PSIE may have been dropped at a via node that does not support priority routing. In such a situation, the value for svcroutingpri becomes the routing priority for the connection. See the cnfpri-routing description for details on priority routing.
The routing priority is used during de-routing. SVCs and SPVCs are released according to the routing priority. This release prioritization promotes faster re-routing of higher priority connections.
Range: 1-15
Default: 8
|
The configuration of the port can be checked by using the dsppnportsig command.
M8850_NY.7.PXM.a > dsppnport 1:2.1:1
Port: 1:2.1:1 Logical ID: 16848897
IF status: up Admin Status: up
Auto-config: enable Addrs-reg: enable
IF-side: network IF-type: nni
UniType: private Version: pnni10
Input filter: 0 Output filter: 0
minSvccVpi: 0 maxSvccVpi: 200
minSvccVci: 35 maxSvccVci: 255
minSvpcVpi: 1 maxSvpcVpi: 200
#SpvcCfg: #SpvcActive: #SpvpCfg: #SpvpActive:
Configuring AAL2 Trunks
When an AAL2 bearer trunk has been established, it can be configured further using the following commands.
CIDs
Each voice channel must be assigned a channel identifier (CID) for transport across the AAL2 trunk.
Note
Configure subcell multiplexing before adding a CID. See next section.
Use the addcid command to create a CID and associate it with a ds1/ds0 voice stream. For OC3 cards, the format of this command is:
addcid <ifIndex> <VPI> <VCI> <CID> <bay.line> <Ds1PathIndex> <Ds0 Group Index> <Profile
Type><Profile Number> <Voice Codec> <VBD Codec><Repetition>
For T1/E1 systems the format of this command is:
addcid <ifIndex> <VPI> <VCI> <CID> <bay.line.> <Ds0_Group_Index> <Profile_Type>
<Profile_Number> <Voice_Codec> <VBD_Codec><Repertition>
The vpi and vci parameters must be the vpi and vci of the AAL2 PVC. The CID must be a value between 8 and 255. The vci.vpi,CID combination, uniquely defines a channel in a specified PVC and associates it with a specified ds1/ds0 voice channel.
Profile Type
This parameter specifies the ATM AAL2 profile type for the AAL2 CID.
The valid values are as follows:
1 = ITU
2 = Custom
Profile Number
This parameter specifies the ATM AAL2 profile number for the AAL2 CID.
The valid value are as follows:
For the ITU profile type—1, 2, 3, 7, and 8.
For custom profile type—100. 101, 110, and 200.
When the AAL2 connection is used to transport SS7 signaling, select profile type 200.
Voice Codec
This parameter specifies the voice codec used for an AAL2 voice trunking connection.
The valid values are:
2 = G.729a
3 = G.726-16
4 = G.726-24
5 = G.726-32
6 = G.711u
7 = G.711a
13 = G.729ab
18 = Clear channel
19 = G.726-40
When the AAL2 connection is used to transport SS7 signaling, select 2 = Clear channel.
VBD Codec
This parameter specifies the voice band data codec used in an AAL2 voice trunking connection.
The valid values are:
1 = None (default)
2 = G726r32k
3 = G726r40k
4 = G711u
5 = G711a
Repetition
Once a CID has been created, it can be reconfigured using the cnfcid command.
For the VXSM OC3 card:
cnfcid <ifIndex> <VPI> <VCI> <CID> <Profile Type> <Profile Number> <Voice Codec>
<VBD Codec>
For the VXSM T1/E1 card:
cnfcid <ifIndex> <VPI> <VCI> <CID> <Profile Type> <Profile Number> <Voice Codec> <VBD Codec>
Subcell Multuplexing
With subcell multiplexing, a partially filled cell can be filled with data from another CID. This makes a more efficient use of the bandwidth of the PVC. The partially filled cell is delayed for this purpose but only for a specified period. When the period is up and the cell is still partially filled, it is sent unfilled.
Use the -ctimer parameter in the addcon or cnfcon command to specify the period that an unfilled cell will wait before being transmitted. The wait period is in the range 0 to 50. Configuring the subcell multiplexing feature must be performed before adding CIDs to the connection.
Upspeed
VXSM supports detection of FAX and Modem devices attached to the TDM (trunk) side. The following tones are supported:
•
V.21 Preamble Fax Tone
•
V.25 (CED) Modem/Fax Tone 2100 Hz (with or without phase reversal)
VXSM uses the standard "User state control packets" indicating the change to voiceband data (VBD). The User state control packets are sent as type 3 packets with triple redundancy.
Upon detection of a modem or FAX tone, the master end of the connection performs a CAC check. If successful, it upspeeds to a less complex codec (for example, G.711) to accommodate the voiceband data.
Note that the CAC is performed by the master end of the connection (the CAC-Master). The CAC-Master is specified by the user in the addcon command using the -cmaster parameter.
The upspeed codec is specified in addcid command using the VBD_codec parameter.
Configuring HDLC Signaling AAL5 Trunks for Nx64 Format
In trunking mode the HDLC signaling is transferred across the network as AAL5 connections. If the HDLC data stream conforms to an Nx64 format, the required configuration involves the following steps.
Step 1
Establish an Nx64 profile that can be used by Nx64 AAL5 connections.
addnx64prof <profile_index>[<Nx64TransportMode>][<Nx64FrameFillPattern>][<InterFrameGapFlagCount>]
[<Nx64BitInversion>]
<profile_index>
Specify an index number that uniquely identifies a Nx64 profile entry.
The first entry (i.e., the value of this object is one) is used for default profile, it can not be modified or deleted.
The value for this parameter is a number in the range 2 - 65535.
[<Nx64TransportMode>]
Specify the Nx64 packet stream transport mode as HDLC.
1 = hdlc (the Nx64 data the gateway receives are HDLC frames);
2 = transparent (the Nx64 data the gateway receives are unstructured bit stream and they will be transmitted to the network transparently).
[<Nx64FrameFillPattern>]
Specify the Nx64 HDLC frame start/end fill pattern.
1 = hdlcPattern (specifies 0x7E HDLC frame start/end bit pattern)
2 = iDlePattern (specifies 0xFF IDLE bit pattern)
This parameter is applicable only when the transport mode is set to 'hdlc'.
[<InterFrameGapFlagCount>]
Specify the HDLC inter-frame gap flag count.
A value of '0' means that only one flag is transmitted between a pair of frames and it is shared by them. In this case, the inter-frame flag is the start flag for frame (m) and the end flag for frame (m+1).
This object is only applicable when the transport mode is configured as 'hdlc', otherwise, the value of this object is ignored.
The valid value for this parameter is a number in the range from 0 - 15.
[<Nx64BitInversion>]
Specify whether or not bit inversion is turned on to support inverted HDLC functionality.
When this parameter is set to 'true', all the data stream on the Nx64 link is bit inverted
1 = true
2 = false.
Step 2
Establish an Nx64 AAL5 entry. Use the asnx64aal5 command to create an Nx64 entity. This command associates a particular AAL5 connection with a physical interface and a Nx64 profile.
addnx64aal5 <port><vpi><vci><bay.line.path.vtg/ds3.vt/ds1><ds0_group_number><nx64_profile>
<port><vpi><vci><bay.line.path.vtg/ds3.vt/ds1>
These parameters identify the individual AAL 5 connection to be configured.
<port.>
This parameter is used to specify the port number of the Nx64 AAL5 entry.
The valid value for this parameter is the number 1.
<vpi><vci>
Specify the AAL5 connection to be configured. The vpi is a number in the range 1 - 255. The vci is a number in the range 1 - 65535.
<bay.line.path.vtg/ds3.vt/ds1>
Specify the DS0 path identifier to be used in adding a Nx64 AAL5 entry for the VXSM OC-3 card.
The valid values of this construct and their meaning are as follows:
bay = 1—Designates the VXSM OC-3 card in the upper bay.
line = 1 - 4—Line number. Specifies one of four possible working lines for the OC-3 interface.
path = 1 - 3—Path identification number. Specifies the path identifier for the following path payload type:
vt1.5 payload—For T1 interface.
vt2.0 payload—For E1 interface.
Note
T1 and E1 interfaces cannot be used simultaneously in conjunction with a VXSM card.
vtg/ds3 = 1 - 7—Virtual tributary group or 1 for ds3 path identification number.
vt/ds1 = 1 - 4—Virtual tributary or ds1 path identification number, as follows:
vt = 1 - 4—For T1 interface.
vt = 1 - 3—For E1 interface.
ds1 = 1—28.
ds0= 1 - 24 (T1)/1 - 31(E1)Specifies the DS0 path identifier to be used in adding a Nx64 AAL5 entry for the VXSM OC-3 card.
The valid values of this construct and their meaning are as follows:
bay = 1—Designates the VXSM OC-3 card in the upper bay.
line = 1 - 4—Line number. Specifies one of four possible working lines for the OC-3 interface.
path = 1 - 3—Path identification number. Specifies the path identifier for the following path payload type:
vt1.5 payload—For T1 interface.
vt2.0 payload—For E1 interface.
Note
T1 and E1 interfaces cannot be used simultaneously in conjunction with a VXSM card.
vtg = 1 - 7—Virtual tributary group path identification number.
vt = 1 - 4—Virtual tributary path identification number, as follows:
vt = 1 - 4—For T1 interface.
vt = 1 - 3—For E1 interface.
ds0= 1 - 24 (T1)/1 - 31(E1)
<ds0_group_number>
Specify a number that uniquely identifies a DS0 group containing one or more DS0 that connect to an AAL5 trunking connection.
This object is mandatory when adding an AAL5 entry. Once an AAL5 entry is added, this object can not be modified.
The valid value for this parameter is a number in the range 1 - 31
<nx64_profile>
Specify the Nx64 data profile for an AAL5 trunking connection
The value for this parameter is a number in the range 1 - 65535.
Step 3
Steps 1 and 2 above can be repeated for Nx64 profile and entry needed to support the application.