- LG Software Innovations Coffeemaker User Manual
Table Of Contents
- Title Page
- Revision history
- Contents
- About this guide
- Description
- System requirements
- List of ITG ISDN components
- Ordering rules and guidelines
- ITG ISL Trunk card description
- ITG ISL Trunk card physical description
- ISDN Signaling Link
- Dialing plans
- Quality of Service
- Fallback to alternate facilities
- Type of Service
- Fax support
- Remote Access
- Per-call statistics support using RADIUS Client
- SNMP MIB
- Codec profiles
- Security passwords
- ITG Engineering Guidelines
- Introduction
- Network engineering guidelines overview
- ITG traffic engineering
- Configuration of Meridian 1 routes and network translation
- Assess WAN link resources
- QoS Evaluation Process Overview
- Set QoS
- Measure intranet QoS
- Implement QoS in IP networks
- ITG Trunk DSP profile settings
- Post-installation network measurements
- Estimate QoS level
- ITG MAT PC management configuration
- Install and configure ITG ISL Trunk node
- Before you begin
- Installation Procedure Summary
- Create the ITG Trunk Installation Summary Sheet
- Install and cable ITG trunk cards
- Install NTCW84JA Large System I/O Panel 50-Pin filter adapter
- Install NTMF94EA and NTCW84KA cables
- D-channel cabling for the NT0961AA 24-Port ITG Trunk card
- Set NT6D80 MSDL switches
- Install filter and NTND26 cable (for MSDL and DCHIP cards in same Large System equipment row)
- Install filter and NTND26 cable (for MSDL and DCHIP cards in different Large System equipment rows)
- Configure ITG Trunk data on the Meridian 1
- Configure dialing plans within the corporate network
- Configure ITG Trunk data on MAT
- Transmit ITG trunk card configuration data from MAT to the ITG trunk cards
- Set date and time for the ITG ISL Trunk node
- Change the default ITG shell password to maintain access security
- Change default ESN5 prefix for non-ESN5 IP telephony gateways
- Check card software
- Configure MAT Alarm Management to receive SNMP traps from ITG ISL Trunk cards
- Make test calls to the remote ITG nodes
- Upgrade an ITG Trunk 1.0 node to support ISDN signaling trunks
- Upgrade procedure summary
- Before you begin
- Install the DCHIP hardware upgrade kit
- Upgrade the 8-port ITG basic trunk software to ITG ISL trunk software
- Remove ITG 1.0 configuration data from Meridian 1
- Configure the Meridian 1 ITG ISL Trunk data: upgrade considerations
- Verify ROM-BIOS version
- Upgrade Troubleshooting
- OA&M using MAT applications
- OA&M using the ITG shell CLI and overlays
- Maintenance
- Appendix A: Calbe description and NT8D81BA cable replacement
- NTMF94EA E - LAN, T - LAN and Serial Port cable
- NTCW84KA E-LAN, T-LAN, DCH & Serial cable
- NTAG81CA Faceplate Maintenance cable
- NTAG81BA Maintenance Extender cable
- NTCW84EA DCH PC Card Pigtail cable
- NTMF04BA MSDL extension cable
- NTCW84LA and NTCW84MA upgrade cables
- Prevent ground loops on connection to external customer LAN equipment
- Replace cable NT8D81BA with NT8D81AA
- Tools list
- NT8D81BA cable removal procedures
- Appendix B: Environmental and electrical regulatory data
- Appendix C: Subnet mask conversion from CIDR to dotted decimal format
- Appendix D: Configure a Netgear RM356 modem router for remote access
- Index
- Back

Page 126 of
378
ITG Engineering Guidelines
553-3001-202 Standard 1.00 April 2000
Implement QoS in IP networks
Today’s corporate intranets developed because of the need to support data
services, services which for the most part a “best effort” IP delivery
mechanism suffices. Standard intranets are designed to support a set of
Quality of Service (QoS) objectives dictated by these data services.
When an intranet takes on a real-time service, the users of that service will
impose additional QoS objectives in the intranet; some of these targets may
be less stringent compared with those imposed by current services, while
other targets would be more stringent. For intranets not exposed to real-time
services in the past but now need to deliver ITG traffic, it is likely that the
QoS objectives pertaining to delay will impose an additional design
constraint on the intranet.
One approach is to simply subject all intranet traffic to additional QoS
constraints, and design the network to the strictest QoS objectives, essentially
a “best-of-breed” solution. This for example would improve the quality of
data services, even though most applications may not perceive a reduction of
say 50ms in delay. Improving the network results in one that would be
adequately engineered for voice, but over-engineered for data services.
Another approach is to consider using QoS mechanisms in the intranet, the
goal of which is to provide a more cost-effective solution to engineering the
intranet for non-homogenous traffic types. Unfortunately IP QoS
mechanisms are still relatively recent technology, hardly implemented on
intranets, and difficult to predict the consequences.
This section outlines what QoS mechanisms can work in conjunction with the
ITG node, and with what new intranet-wide consequences if implemented.
Traffic mix
Before implementing QoS mechanisms in the network, the technician needs
to assess the traffic mix of the network. QoS mechanisms depend on the
process and ability to distinguish traffic (by class) so as to provide
differentiated services.
If an intranet is designed solely to deliver ITG traffic, and all traffic flows are
equal priority, then there is no need to consider QoS mechanisms. This
network would only have one class of traffic.