• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
03 -Preparation for ..
 

03 -Preparation for ..

on

  • 621 views

 

Statistics

Views

Total Views
621
Views on SlideShare
620
Embed Views
1

Actions

Likes
0
Downloads
15
Comments
0

1 Embed 1

http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • eMTA - Embedded Multimedia Terminal Adapter
  • 1. Example: Motorola’s and Arris’s MTAs will require different files when they get registered and provisioned in the field DSAM will need its own configuration file to get its MTA registered and provisioned. 2. Services:
  • GC - Gate Controller CMS - Call Management System UGS - Unsolicited Grant Service Flow - which will be used to pass the voice traffic TOS - Type of Service
  • Endpoints are Caller or Callee

03 -Preparation for .. 03 -Preparation for .. Presentation Transcript

  • Preparation for DSAM VoIP Al Ruth, Eugen Takacs, Alex Goloschokin
  • JDSU VoIP Solutions
    • DSAM offers two tiers of VoIP test capabilities
      • VoIPCheck option
        • DOCSIS® call quality verification
      • PacketCable™ and euroPacketCable™ VoIP test option
        • PacketCable™ currently works with Time Warner only
        • euroPacketCable™ works with Casema in a Beta form
        • Needs to evaluate each operator’s network
          • With a VoIP offering questionnaire – Both VoIPCheck and VoIP
        • Actively addressing the concerns from the field
    • Both have specific purposes and targeted tests
  • VoIPCheck
    • Uses the DOCSIS ® channel to assess the capability of current test point to carry voice traffic
    • Perform VoIP measurements without requiring user to go through the extensive process of MTA provisioning
    • Ideal for two types of customers
      • Those who do not use PacketCable™ to deliver VoIP
        • SIP
        • Vonage (Broadband VoIP)
      • Customers that have not yet partnered with JDSU to validate the operability of DSAM eMTA within their VoIP architecture
  • What does VoIPCheck Test?
    • Tests two segments of the network
      • Traffic to the CMTS
      • Traffic to the Advanced IP (AIP) server (reflector server)
    • Makes VoIP measurement to the first router in the pipe
      • Typically the CMTS
      • Test the HFC portion of the network
        • From the CM to the CMTS and back
      • Referred to within the DSAM as the CMTS Loop test
      • Practical to determine whether the HFC drop can support a VoIP install
      • Packets exchanged are actual VoIP packets (RTP packets)
  • What does VoIPCheck Test? – continued
    • CMTS can de-prioritize packets deemed unimportant (Ping, ICMP)
        • If Ping packets were used in the same manner, results may not be representative of actual performance of a VoIP install
        • Trilithic does RTP and ICMP, depending on destination of IP data packet
          • They sometimes use Ping packets
    • Voice packets are treated with a higher priority than data packets received from the same cable modem
        • Referred to as Quality of Service (QoS)
        • DSAM VoIPCheck capable of being setup with UGS (Unsolicited Grant Service) Flow to resemble call QoS
  • What does VoIPCheck Test? – continued
    • Customer can choose to install the JDSU Advanced IP (AIP) Server near the Media Gateway
      • From JDSU, not yet in a deployable package
        • Talk to Sales/marketing on the availability
      • DSAM can perform VoIP testing to this server
      • Result determines quality of the entire path to AIP Server
        • Segments the network: RF (HFC) and IP
        • (Media Gateway – Furthest Point of control for MSO)
  • CMTS Loop
    • First screen for VoIPCheck
    • Provides packet info
      • Packet loss, delay, and jitter
      • Quality info
        • Mean Opinion Score (MOS)
        • R-Value
    • Continuously sending/receiving VoIP packets to/from the CMTS
    • Packet statistics and quality metrics are updated approximately every 2.5 seconds.
    • Treats every 1.25 seconds as a new ‘call’
      • MOS and R-Value susceptible to issues even after the test has been running for long periods
    • Show quality data of the drop since the test was initiated
      • Instantaneous – Current
      • Average – Avg
      • Maximum – Max
      • Minimum – Min
  • Segmentation
    • Provides a segmentation view of the system
      • RF portion to CMTS
      • IP portion to AIP Server
    • Allows technicians to determine which ‘legs’ of the network are causing issues
    • Performed exactly like the CMTS Loop test
      • alternates between testing with the CMTS and the Advanced IP Server
    • Check if and where issues with voice services reside
      • within the HFC – CMTS Loop
      • IP Backbone – Server Loop
    • Show results – ‘Data Menu’ selection
      • packet statistics
      • quality values
    • ‘ Data Menu’ can be used to select which data results to display
      • Current
      • Average
      • Extreme – (Max/Min)
  • VoIPCheck Configuration
    • IP address and port number of the server must be configured within the DSAM
      • Port number entered for the server must match the port number configured on the server
      • Port number that is entered here can be utilized when setting up QoS
        • Described later
    • Select which CODEC will be simulated by the test
      • CODEC affects the values calculated in the MOS and R-Value
      • Due to compression and bandwidth requirements, CODEC’s will have different theoretical max values for MOS and R-Value
        • maximum value for MOS on the G.711 protocol is 4.2 instead of the 5.0 that may be expected
    • Size of the jitter buffer to simulate
      • Default is 40ms – Approx avg to CMs
  • Setting up QoS for VoIPCheck
    • Make VoIPCheck more closely resemble the quality attained on the actual VoIP network
      • Necessary to employ the same QoS within the two environments
    • CM config file for DSAM needs to be created
      • Force VoIPCheck to utilize a Unsolicited Grant Service (UGS) flow on the upstream
      • A guaranteed bandwidth flow on the downstream
    • See Appendix A from the App Note – DSAM VoIP Offering
  • PacketCable TM VoIP Overview
    • Perform full PacketCable TM VoIP test
      • Provisioning
      • Signaling
      • Voice quality testing
    • Done by using the eMTA within the DSAM
    • DSAM also contains a speakerphone – Mic and Speaker
    • Has the ability to join a PacketCable™ network and function as a telephone
    • Phone calls can be initiated or received by the DSAM
    • Quality of the call can be quickly assessed
  • MTA Provisioning
    • Begins by provisioning the CM within the DSAM
    • Provisioning the eMTA next
    • Each step along the way is displayed
      • Should any step fail, a dialog will display describing the error information
    • Once online
      • eMTA continues by initializing endpoint(s) with the Call Management System (CMS)
      • And obtains a phone number(s)
    • Once all provisioning is complete, the DSAM will be ‘ready’ to place and receive phone calls
    provisioning and signaling steps
  • VoIP Signaling
    • PacketCable uses NCS (Network-based Call) Signaling to initiate calls
    • DSAM capable of exercising signaling capabilities
      • DSAM can be utilized to test for dial tone
      • Make phone calls to test call quality
      • Proving the signaling paths to all necessary servers
    • DSAM has the ability to test signaling to both on-net and off-net destinations
      • Only difference is the phone number to test
      • From the DSAM user’s perspective
    • DSAM will perform Dynamic Quality Of Service (DQoS) setup
      • Done during the call setup and teardown portion of the signaling
      • Necessary based on the PacketCable TM network configuration
      • Same setup that would be required by any MTA on the system
    • The Call quality statistics the DSAM measures is based on the actual setup of an MTA and experiences a phone call just like an MTA
  • Voice Quality Testing
    • DSAM will enter the ‘Ongoing Call’ screen
      • Once a call has been initiated or received
    • Measuring packet statistics, and continuously recording the quality of the call
      • Provides packet loss, jitter, and delay
      • Both local (DSAM) and remote endpoints
      • Gives a picture of upstream and downstream packet performance
    • MOS allows technicians to quickly assess call quality from location’s drop
      • If quality is determined unsatisfactory, technician analyzes the packet statistics to determine whether the low quality is a product of packet loss, delay, or jitter
      • Then take the appropriate action to fix the problem
  • Required Testing and Setup Done by Operators (I)
    • PacketCable™ is a complex and developing standard
      • ‘ Gray zones’
        • each vendor and/or operator implements setup parameters slightly different than others
      • These differences are attributed to vendor’s and/or operator’s own interpretation of the standard
      • This is why each operator puts all PacketCable™ (or EuroPacketCable™) network elements together - such as CMTS and MTA - in a lab or controlled environment and test for compatibility
    • DSAM is a CM, CPE (Customer Premise Equipment) and MTA in one device
      • Requires some degree of compatibility testing in the lab / control environment as a new MTA vendor
    • Purpose of this testing
      • Meets the specific MSO/operator PacketCable™ VoIP implementation setup
      • Provide full VoIP test capability in the field while controlling the security risks
  • Required Testing and Setup Done by Operators (II)
    • Create DSAM specific config files to meet specific VoIP implementation
      • Each MTA vendor gets its own config files
    • Manage test device separately from regular MTA
      • Provisioning different for DSAM
      • DSAM is a “Roving” MTA
        • Can not be tied to one CMTS or CMTS blade
      • Handling of phone number and billing
  • DSAM and MTA Security
    • Addressed with authentication and encryption processes
      • Protect the service revenue
        • Prevent people from stealing services
      • Protect service privacy
        • Prevent people from listening to other’s conversation
      • Built into both DOCSIS® 1.1 and PacketCable™ (EuroPacketCable™)
      • Each certified device has a set of certificates
    • Only CableLabs® certified devices can go through the security processes and obtain access to services
        • When security features are enabled
      • This makes testing extremely hard
        • Test devices do not possess certificates (CableLabs® will not certify)
        • Test devices are built differently to meet the demands in the field
        • Do not meet all requirements of consumer-focused DOCSIS® 1.1 and PacketCable™
    • JDSU/Acterna and CableLabs® have come up with a process for DOCSIS® security
      • Self-signed certificates
        • Meets the testing needs of operators
        • Keeping the integrity of the security process
      • CableLabs® has not yet endorsed Self-Signed certificates for PacketCable™ networks
        • Method DSAM uses for PacketCable™ security
  • DSAM VoIP Provisioning Setup Overview
    • Process of joining a PacketCable ™ voice network is complicated
    • Multiple sequences the eMTA must complete
    • Some steps optional depending on how an operator decides to setup and deploy the PacketCable ™ network
    • This table is taken from the PacketCable ™ Secure Provisioning spec
      • It describes each step involved with an eMTA joining a VoIP network
      • Will be referenced throughout the presentation when describing optional steps, or requiring special attention
  • DSAM VoIP Provisioning Setup – PacketCable MTA Device Provisioning – DHCP
    • The following DHCP ‘options’ must be present in the offer received by the MTA to continue its provisioning attempt
    • DHCP options required by the MTA in an ‘offer’
      • Option 1: Subnet Mask
      • Option 3: Router / Default Gateway
      • Option 6: Domain Server
      • Option 7: SYSLOG Server IP
      • Option 12: MTA Hostname (FQDN)
      • Option 15: Domain Name (FQDN)
      • Option 122 (or 177): As specified in the PacketCable Provisioning Specification
  • DSAM VoIP Provisioning Setup – DOCSIS® DHCP
    • An MTA must join a DOCSIS ® network as a CM prior to joining a PacketCable™ VoIP network
    • A few specifics pertaining to DOCSIS ® provisioning will aid the MTA attempting to come online
      • DHCP
        • CM (and MTA) use Dynamic Host Control Protocol (DHCP) to obtain its IP info
        • MTA will effectively broadcast a request for IP credentials
        • In this broadcast, the CM and MTA will include a list of the ‘required info’ it needs to successfully join the network
        • DHCP Server will reply with an ‘offer’ that contains all info it can supply
          • Including Service flow type: Secure, Hybrid, Basic
        • PacketCable has defined two DHCP options to allow a CM to support an MTA
          • DSAM is designed to support either of the two options
          • Option 177
            • This was an early option defined by CableLabs for PacketCable (it is obsoleted by 122)
          • Option 122: This is the new definition of the PacketCable DHCP Option
  • DSAM VoIP Provisioning Setup – DOCSIS ® Security (BPI+)
    • DSAM platform relies on a self-signed security architecture
    • If DOCSIS ® BPI+ is to be implemented on the network, (DSAM and Secure DOCSIS® presentation)
        • Preparing DSAM in a Secure DOCSIS ® Network
  • DSAM VoIP Provisioning Setup – DOCSIS ® DQOS
    • PacketCable™ takes advantage of a DOCSIS ® 1.1 service - DQOS
    • A CM can request a ‘high Guaranteed Bandwidth’ Service Flow from the CMTS with DQOS
    • The GC (Gateway Controller) within the CMS (Call Management System) is the Policy Decision Point for this service
    • CMTS must perform an admission check when a resource management request is received
    • Due to complications of the 3 rd party handshake, DSAM allows the operator to bypass this DQOS capability if desired
      • DQOS Disabled - the simplest of cases
        • No special action is necessary in the network
        • MTA will use the ‘Best Effort’ Service Flow of the CM to pass Signaling and Voice traffic
      • “ DQOS Lite”
        • DSAM will dynamically create a UGS
        • Classifier for voice traffic will be based on IP addresses of source and destination as well as the ports
        • Config file should be used to create a TOS flow for the signaling
          • Typically uses the identifier in the packets to route signaling on the appropriate flow
        • To inform DSAM what the TOS should be set to, the MTA config file should set the pktcSigDefCallSigTos value from the pktcSigMib appropriately
      • Secure DQOS Enabled
        • Requires operators have DQOS enabled and Gate Controller functionality
        • Make sure DSAM is not “tied” to a specific CMTS
        • DQOS and COPS protocol require the CMS contact CMTS to create a Gate for the MTA to use when creating a high priority ‘service flow’.
        • For the DSAM to function throughout a network, across CMTS’s, the GC must be able to determine which CMTS the DSAM is currently attached through dynamically, and not tie the DSAM to a specific CMTS
  • DSAM VoIP Provisioning Setup – PacketCable MTA Device Provisioning
    • MTA Device provisioning focuses on an MTA taking necessary steps to join a VoIP network
    • This involves the following
      • obtaining IP configuration
      • announcing itself to the network
      • downloading configuration data from provisioning server
    • Once MTA has successfully joined the network, individual ‘endpoints’ within the DSAM / MTA will initialize
  • DSAM VoIP Provisioning Setup – PacketCable MTA Device Provisioning – Provisioning Flow
    • Currently 3 types of provisioning Flows
      • SECURE, BASIC, and HYBRID
    • DSAM does not Automatically recognize the PacketCable defined HYBRID provisioning flow.
      • As such, the DSAM will not automatically recognize the, HYBRID.1 or HYBRID.2 flow descriptions delivered to the MTA in Option 122 sub-option 6
    • BASIC flow has been shown to work in our Lab
      • BASIC.1, BASIC.2
    • PacketCable Secure (default)
      • Currently supported as the default
      • Requires additional setup
  • Provisioning Flows - BASIC
    • BASIC.1
      • Very different from Secure Flow
      • Has been shown to work in Lab
    • BASIC.2
      • Not much different than BASIC.1 (SNMP communication at end)
  • Provisioning Flows - Hybrid
    • HYBRID.1
      • Currently attainable using configurable items in TPP/FDM
    • HYBRID.2
      • Not much different from HYBRID.1 (TPP Configurable)
  • DSAM VoIP Provisioning Setup – PacketCable MTA Device Provisioning – Flow Options
    • Once an MTA is online, no difference between Secure, BASIC, or HYBRID mode when testing voice quality
    • If DSAM can be provisioned, all tests will be valid representations of voice quality that is being experienced by the MTA
  • DSAM VoIP Provisioning Setup – PacketCable MTA Device Provisioning – Provisioning Flow – Security
    • Kerberos: Additional security to avoid eavesdropping
    • Kerberos Disabled
      • DSAM can support configurations where operator chooses to bypass Kerberos security
      • In such a scenario, DSAM will bypass steps 9 – 14 as defined in the Embedded-MTA Secure Power-on Initialization Flow
    • Kerberos Enabled
      • Flow
        • DSAM can support configurations when the operator chooses to enable Kerberos security
        • In such a scenario, DSAM will perform steps 9-14 as defined in the Embedded-MTA Secure Power-on Initialization Flow
      • Authentication:
        • DSAM relies on a self-signed security architecture
        • If Kerberos security is to be employed, the KDC server must be configured to recognize DSAM as a trusted entity
  • DSAM VoIP Provisioning Setup – PacketCable MTA Device Provisioning – Provisioning Flow – SNMP
    • SNMPv2c
      • DSAM has capability to use SNMPv2c and bypass the security involved in the SNMPv3 spec
      • SNMPv2c used by DSAM to send the enrollment INFORM to the provisioning and subsequently by the provisioning server to set the config file name within DSAM
      • The community used to access all data can be set either through the config of DSAM, or by sending the community name in the CM config file
      • To set the community name in the CM config file, set the docsDevNmAccessCommunity MIB to appropriate community name
      • DSAM will use the first Read-Only and the first Read-Write communities specified in the CM config file for the MTA
    • SNMPv3
      • DSAM supports the SNMPv3 provisioning flow as defined in the Embedded-MTA Secure Power-on Initialization Flow
    • SNMP: Simple Network Management Protocol
  • DSAM VoIP Provisioning Setup – PacketCable MTA Device Provisioning –MTA Endpoint Provisioning
    • MTA authenticates itself to the CMS and establishes a security association with call server
      • Security Association could be no security
      • Has to be completed successfully to permit further call signaling
    • MTA Signaling - Media Gateway Profile
      • Operators will typically want to create a Media Gateway Profile specifically for DSAM on the network
  • DSAM MTA Summary
    • Not Simple setup process
    • Requires collaboration from both Cable Operators and JDSU
    • Best in-depth VoIP troubleshooting tool available