• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Juniper Networks Presentation Template-EMEA
 

Juniper Networks Presentation Template-EMEA

on

  • 948 views

 

Statistics

Views

Total Views
948
Views on SlideShare
944
Embed Views
4

Actions

Likes
0
Downloads
51
Comments
0

1 Embed 4

http://www.slideshare.net 4

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
  • Animation Key: The yellow rectangles represent planes of controllability . Bottom to top of slide represents the evolution from physical network elements towards human experiences, through intermediate levels of abstraction. Left to right of slide represents the breadth of each plane, which holds the capability of controlling aspects of the associated layer. The white-to-blue shaded arrow represents the identification of control levels derived from within the associated plane of controllability. Left to right of slide represents increasing levels of control variable’s involvement . Bottom to top of slide represents the connection path between the control levels. The red ovals represent network model realizations from staying roughly within three columns.
  • Start with service planning…
  • Key point: VoiP packets are small when compressed codes are used. and should be identified and processed (given the appropriate priority) at line rate
  • Delay also have impact on jitter, thus has to be limited, otherwise jitter will be high.
  • Indicate the Jitter importance for voice traffic. For voice people, Jitter is the most important parameter.
  • Also point out that packet loss impact depends on coding and compression. higher the compression is, more important the impact of loss is.
  • Session timeout timer is implementation dependent. But it is safe to say that IP network has to provide comparable recovery performance with traditional circuit switched networks. In a typical voice PoP design, voip gateway is connected into two redundant ayer2 switches and each switch is then connected into two redundant edge routers. The total recovery time end-to-end thus consists of recovery within the voice PoP, and recovery across the core. MPLS based fast recovery isn’t applicable end-to-end since most voice gateways are not MPLS aware.
  • Just note that some SPs had done testing of carrying VoIP with Ipsec tunnel. The results show that when multiple hops are present, the encryption overhead caused by Ipsec is significant and caused notable voice quality degradation.
  • What are the issues I need to consider while designing a VoIP network?
  • What are the issues I need to consider while designing a VoIP network?
  • What are the issues I need to consider while designing a VoIP network?
  • What are the issues I need to consider while designing a VoIP network?
  • What are the issues I need to consider while designing a VoIP network?
  • What are the issues I need to consider while designing a VoIP network?
  • Primary point – JUNOS has always had the ability to restart RPD without resetting the PFE, which carries on forwarding during RE restart. This is not the same as RE failover or hitless failover cases, because only one RE is involved, not 2, where an RE failover is performed. Hitless RE failover refers to even further improvements to Routing Engine failover –. The key difference with Hitless RE failover is that the failover does not require the RE to reset the PFEs as well. This key difference allows forwarding to continue uninterrupted, and also enables hitless software upgrades. The benefits of Hitless RE failover are further discussed later under Graceful Restart.

Juniper Networks Presentation Template-EMEA Juniper Networks Presentation Template-EMEA Presentation Transcript

  • Packet Voice Backbone Network Design Matt Kolon February 23rd, 2004 APRICOT 2004 - Kuala Lumpur
  • Agenda
    • Packet voice essentials
      • Quick background: VoIP Applications
      • Customer Goals for Voice
      • VoIP Traffic Characteristics
    • Packet voice backbone design
      • Class of service
      • High Availability
      • MPLS
  • Business: IP Voice Trunking IP PBX Enterprise HQ Enterprise Remote Site IAD POTS SIP
    • Service Provided: Point-to-Point “IP trunk” with low-latency QoS and guaranteed bandwidth. Usually to replace a pure FR service.
    • SP implements it with circuit-oriented access network(s) and a Traffic Engineered MPLS tunnel in the IP/MPLS backbone
    • All VoIP “application” intelligence resides in enterprise private devices (e.g. IAD/Media Gateway, IP PBX, SIP phones, etc)
    IP trunk ATM FR/TDM DSLAM IP/MPLS MPLS LSP ETH/VLAN
  • Business: [Vo]IP transport VPNs IP PBX Enterprise HQ Enterprise Remote Sites IAD POTS SIP
    • Service Provided: Multipoint IP VPN with low-latency QoS and guaranteed bandwidth, suitable for voice traffic. Often part of a multi traffic class IP VPN offering (VoIP being only one traffic class).
    • SP implements it with circuit-oriented access network(s) and a mesh of Traffic Engineered MPLS tunnels in the backbone. Or pure Diffserv approach with traffic trend monitoring. Or Layer 2 VPLS. Or IPSec…
    • All VoIP “application” intelligence resides in enterprise private devices
    (Vo)IP VPN POTS IAD DSLAM FR/TDM DSLAM ETH/VLAN IP VPNs
  • Business: IP VPNs + Managed VoIP IP PBX Enterprise HQ Enterprise Remote Sites IAD POTS SIP
    • Service Provided: Multipoint IP VPN with low-latency QoS and guaranteed bandwidth; Managed VoIP equipment in customer premises.
    • SP implements it with circuit-oriented access network(s) and a mesh of Traffic Engineered MPLS tunnels in the backbone. Or pure Diffserv approach with traffic trend monitoring. Or Layer 2 VPLS. Or IPSec. Or private line (e.g. FR) links. Etc.
    • All VoIP “application” intelligence resides in managed devices (e.g. IAD/Media Gateway, IP PBX, etc) located in customer premises.
    (Vo)IP VPN POTS IAD IP Telephony DSLAM FR/TDM DSLAM ETH/VLAN IP VPNs
  • Business: TDM/telephony, VoIP core CSU/DSU Enterprise Site 1 Enterprise Site 2
    • Service Provided: regular TDM Telephony (transport and application)
    • SP implements it with a TDM access network, Media Gateways, an IP Core, a PSTN core, and PSTN mediation mechanisms. This is a Class 4/5 replacement application, not directly visible to the end users.
    • VoIP “application” intelligence (servers and gateways) hosted by the SP, overlaid on IP backbone, coupled with PSTN “intelligence”.
    TDM / Telephony TDM PBX TDM / Telephony Softphone POTS SIP POTS TDM TDM TDM IP/MPLS MPLS LSP GE GE TDM Softswitch PSTN/SS7
  • Carrier: signaling transport
    • Service Provided: IP VPN to convey IP-based signaling & control messages (SS7-over-IP, SIP, H.323, MGCP/Megaco, TCAP/IN, etc) with proper CoS and insulation.
    • SP implements it with an IP/MPLS Core. Could be operated by the voice carrier, or outsourced to an IP provider.
    • VoIP “application” intelligence (servers and gateways) hosted by the SP, overlaid on IP backbone, coupled with PSTN intelligence.
    Softswitch Signaling Class 4/5 Media Gateway IP/MPLS
  • Carrier: inter-domain VoIP peering
    • Service Provided (to end users): public telephony (VoIP or POTS)
    • Main goal is to create a VoIP peering point between carriers
    • SP implements it with “virtual” IP-to-IP gateways, plus inter-domain signaling (e.g. SIP or SS7). May require true media/codec transcoding, or “simple” IP forwarding.
    • Complex business peering issues are addressed by the signaling layer.
    IP/MPLS MPLS LSPs Softswitch SIP/H.323 Gatekeeper IP-to-IP “Virtual” Gateways IP/MPLS MPLS LSPs Softswitch SIP/H.323 Gatekeeper Peering Signaling
  • Business: IP Centrex, Softswitch SS7 PSTN Modem Enterprise Site POTS
    • Service Provided: IP Centrex (a.k.a. Hosted IP Telephony) to Small & Medium VoIP-enabled Businesses.
    • SP implements it with a broadband access network(s), a VPN enabled IP/MPLS backbone, softswitches with Centrex intelligence, and PSTN gateways (transport & signaling).
    • All VoIP “application” intelligence is hosted by the SP, as well as PSTN gateway mechanisms.
    IP VPN SIP MG IP Centrex “ Virtual PBX” DSLAM FR/TDM IP/MPLS with VPNs Softswitch Sig. Gateway Media Gateway
  • Residential: VoIP / telephony Household/SMB
    • Service Provided: regular telephony services (transport and application), via VoIP, in addition to regular Broadband Internet.
    • SP implements it with a broadband access network, an IP/MPLS Core, a PSTN core, and PSTN mediation mechanisms.
    • VoIP “application” intelligence hosted by the SP, overlaid on IP backbone, and coupled with PSTN “intelligence”
    • CPE could be a mere bridge, or an IP router, or a full-blown media gateway (POTS phones). Home network could be ETH, WLAN, etc.
    IP / Telephony CPE Household/SOHO SIP or H.323 POTS IP / Telephony CPE SIP or H.323 POTS CMTS DSLAM CMTS IP/MPLS MPLS LSP (hierarchical) DSLAM Softswitch PSTN/SS7 INTERNET
  • Agenda
    • Packet voice essentials
      • Quick background: VoIP Applications
      • Customer Goals for Voice
      • VoIP Traffic Characteristics
    • Packet voice backbone design
      • Class of service
      • High Availability
      • MPLS
  • Goals for Packet Voice Networks
    • Quality
      • Deliver a grade of voice service equivalent to that provided by the current Public Switched Telephone Network (PSTN).
    • Multiservice
      • Voice service must live on a common IP backbone with a set of other services.
    • Flexibility
      • Must be capable of supporting future applications that may not yet be fully defined.
  • Quality: MOS Model
    • Voice quality in the PSTN network has historically been measured using ‘mean opinion score’ (MOS).
    • The mean opinion score measures the subjective quality of a voice call.
    • Historically the telephony providers invited people and used various call types (with delay, echo etc.) and recorded the results.
    • MOS scores for “acceptable” voice have been dropping, but quality is still important.
  • Quality: Voice-worthy IP Backbones
    • Sufficient bandwidth for voice + other services
    • Delay: Less than 40msec
    • Jitter: Less than 20msec
    • Loss: Less than 2%
    • Availability: Better than 4 9s, less than 1% blocking
    • Security: No unauthorized intrusion or DoS effects
    • Predictability: None of this changes in unforseeable ways
  • Engineering VoIP Experience Levels Over-Provisioned Network Over-Subscribed Network Carrier-Grade Multi-Service Network Flat Access / Core Integrated End-to-End Best Effort Diff-Serv MPLS (Core) / Static (Access) MPLS (Core) / Dynamic (Access) None (State-less) Planning/Reporting (Historical) Reactive (Real-time) Network Resources Experience Levels QoS Service Level State Enhanced Delivery Assured Experience Best Effort
  • Core Domain VoIP Solutions Core Access Access Over-Provisioned Network Best Effort
  • Core Domain VoIP Architecture Best Effort
    • A Best Effort Experience is achieved by transporting voice over IP networks without special treatment
      • All packets delivered according to equal prioritization router queuing throughout network
    • Best effort engineered networks require over-provisioning to account for peak traffic bursts associated with data applications and busy voice hours
    • Studies and experience both show that today’s well engineered over-provisioned networks based on current routing technologies can support most voice services
  • Core Domain VoIP Architecture Best Effort Router Failure 
    • Failure Detection ~ 300 ms – 1+ sec (without optimizations)
    • Route Convergence ~ 10+ sec (area size dependant)
    • Causes temporary service interruption, degradation of capacity
  • Core Domain VoIP Architecture Best Effort  Link Congestion
    • Routing protocols unable to detect route around congestion
    • Causes temporary service interruption, degradation of capacity
  • Core Domain VoIP Architecture Best Effort – Pros & Cons
    • Pros
    • Inexpensive
    • Simple
    • Studies show that over-provisioning provides satisfactory delay and jitter performance
    • Sufficient strategy for voice-only and over-provisioned networks
    • Cons
    • Performance levels not maintainable across failures and congestion
    • Not adequate for over-subscribed networks
    • Challenges inherent with building over-provisioned networks
    • Does not provide admission control constructs
  • Core Domain VoIP Solutions Core Access Access Over-Subscribed Network Enhanced Delivery Differentiated Services
  • Core Domain VoIP Architecture Enhanced Delivery
    • Differentiated Services (Diff-Serv) facilitates the ability to provision separate service classes such that they receive particular treatment levels
    • Packets marked accordingly before entering the network
    • Participating routers process packets according to Diff-Serv marking
    • Router Diff-Serv processing variables
      • Queuing (priority levels)
      • Scheduling (strict, weighted, round-robin, etc)
      • Congestion avoidance (RED, WRED)
  • Core Domain VoIP Architecture Enhanced Delivery
    • DiffServ markings (DSCP) scale well
    • DSCP’s can be AS-Dependant
      • Router DSCP mediation requirement
    • DSCP may be mapped to other QoS technologies across network
      • QoS migration
      • Network segment QoS interworking
    • DiffServ adds deterministic behavior to packet class transport
      • This benefit enhances transport behavior in secondary path re-route optimizations
  • Core Domain VoIP Architecture Enhanced Delivery
    • Cycle through output queues emptying from highest to lowest priority
    • DiffServ markings map to queue level
    • Queuing schedulers typically allow for variable weighting/emptying
    • Queue sizes typically variable/provisionable
    Medium Priority Queue High Priority Queue Low Priority Queue
  • Core Domain VoIP Architecture Enhanced Delivery Router Failure 
    • Failure Detection ~ 300 ms – 1+ sec (without optimizations)
    • Route Convergence ~ 10+ sec (area size dependant)
    • Re-Route performance doesn’t benefit from DiffServ treatment
    • Causes temporary service interruption, degradation of capacity
  • Core Domain VoIP Architecture Enhanced Delivery  Link Congestion
    • Routing protocols unable to detect route around congestion
    • High-priority-marked VoIP flows will take longer to be affected by congestion than lower priority flows
    • May cause temporary VoIP service interruption, degradation of capacity, will affect other services
  • Core Domain VoIP Architecture Enhanced Delivery – Pros & Cons
    • Pros
    • Adequate for over-subscribed networks
    • Enhanced flow treatment for VoIP across failure re-route paths
    • Lowers per-router hop latency
    • Adds flow-based traffic engineering model
    • Scales easily
    • Cons
    • Performance levels not guaranteed across failures and congestion
    • Link bandwidth statistics not maintained or usable
    • Does not enable admission control constructs
  • Core Domain VoIP Solutions Core Access Access Assured Experience MPLS-TE Carrier-Grade Multi-Service Network
  • Core Domain VoIP Architecture Assured Experience
    • Assured Experience networks are built upon an intelligent network resource plane
    • Allow the service provider to guarantee deterministic performance to its customers under all network conditions
      • Even during network congestion and element failures
    • Facilitate multi-service network infrastructures
  • Core Domain VoIP Architecture Assured Experience
    • The Intelligent Network Resource Plane…
      • Maintains resource state, such as
        • Link Bandwidth – up/down, total and current allocation
      • Facilitates connection-oriented traffic engineering constructs, such as…
        • Constraint Based Routing Control
        • Flow Classification and Forwarding
      • Supports fault tolerance constructs, such as
        • Fail-over Resources – routes, network elements
  • Core Domain VoIP Architecture Assured Experience – MPLS
    • MPLS supports the requirements of Intelligent Network Resource Plane
    • MPLS was designed to ease the provisioning and maintenance of efficient packet data networks
    • IGP and BGP routing protocols building forwarding tables based on shortest path only
    • MPLS separates the route control and packet forwarding such that policy-based paths may be constructed
  • Core Domain VoIP Architecture Assured Experience – MPLS
    • MPLS is based on…
      • Label Switched Paths (LSP)
      • Link Attribute Distribution (IGP/BGP protocol extensions)
      • Traffic Engineering Databases (TED)
      • Constrained-Shortest-Path-First Algorithm (CSPF)
      • Label Distribution Protocols (LDP)
      • Label Edge Routers (LER) and Label Switch Routers (LSR)
    • MPLS-TE facilitates constraint-based routing
    • We’ll talk more about MPLS items later…
  • Core Domain VoIP Architecture Assured Experience – MPLS Route Protection
    • Primary LSP / Secondary LSP Configuration
      • Allows for backup physical path TE
    • Fast Rerouting
      • Facilitates dynamic routing around link / node failures
    • Fate Sharing
      • Limit backup LSP crossing of the same physical elements as primary LSP
  • Core Domain VoIP Architecture Assured Experience – MPLS
    • Traffic Engineering creates LSP’s
    • Labels are distributed to construct LSP’s
    • Packets are classified / Labels added
      • L2/L3 policy application
    • Upstream flows policed, downstream flows shaped
    • Queue and drop accordingly
    • LSR’s only inspect label
    • Label and interface table lookup
      • Output label and interface
    • Label is removed from packets
    • Packets are routed to destination
    LER LSR LER
  • Core Domain VoIP Architecture Assured Experience – MPLS Router Failure 
    • Failure Detection ~ 20 – 30 ms
    • Fast Reroute < 50 ms
    • Small amount of packet loss during failover
    • Service interruption not noticeable, minimal capacity degradation
  • Core Domain VoIP Architecture Assured Experience – Pros & Cons
    • Pros
    • State-full, intelligent network resource plane
    • Designed to ease TE design, maintenance and management
    • Facilitates class-based forwarding for multi-service networks
    • Interworks with disparate QoS mechanisms and transport technologies
    • Supports hierarchical forwarding
    • Cons
    • Fully meshed topologies suffer from n 2 scaling issues
  • Multiservice: Service Classes
    • From this… To this….
    • Easy to think of as “CoS”, but actually involves much more than traditional router CoS or QoS mechanisms.
  • Multiservice: Bundled Service Offerings
    • Plain VoIP service model is proven to be non-sustainable
      • First generation of pure VoIP carriers are gone
      • Price of 1 min of voice has fallen through the floor
    • VoIP with other services is the way to go
      • Value-add: Unified messaging, voice accessible content, video telephony
      • Additional non-voice: Broadcast video, surveillance, etc. VPNs and other business services
      • Generate more revenue, key differentiator from competitors
      • Can be offered at minimum additional cost
  • Final Thought on Goals: Who Really Knows?
    • Future service revenue
      • By definition unknowable, will always surprise us…
        • Immense possibility in diverse areas such as mobile, micropayment, handheld videoconferencing…
      • Infrastructure must have:
        • Unrestricted future service rollout
          • Vendors must design flexible hardware and software platforms
        • Upgradeable without forklift
        • Capability to support many services at one time, without the services affecting each other
    Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net
  • Agenda
    • Packet voice essentials
      • Quick background: VoIP Applications
      • Customer Goals for Voice
      • VoIP Traffic Characteristics
    • Packet voice backbone design
      • Class of service
      • High Availability
      • MPLS
  • QoS: Bandwidth
    • VoIP traffic is constant bit stream, bandwidth required varies with which codec used, # of voice sample per packet, and transport media used.
    • Even G.711 packets are only ~80 bytes, each call only ~112 kbps.
    • VoIP packet is very small for compressed codecs
      • G.729 with two 10ms samples/frame yields 24Kbps without layer2 headers
    • Line rate processing of VoIP packets is crucial!
  • QoS: Delay
    • ITU G.114: <150ms for one-way, e2e
    • Delay Budget:
      • Packet formation delay, O(10ms)
      • Packet switching delay, O(10us) per Hop
      • Serialization delay, (#bits/link rate*#Hop)
      • Propagation delay, (1ms/100mile)
      • Queuing delay, (variable)
    • typical backbone delay requirement: <30ms
  • QoS: Jitter
    • Definition: Variations in packet arrival time
    • Causes:
      • Queuing variation under changing network load condition
      • Load sharing over changing paths
    • De-jitter (“playout”) buffer in gateways
      • Static or dynamic
      • Adds to the overall delay
    • Best to avoid causes of Jitter rather than trying to buffer it away.
  • QoS: Packet Loss
    • UDP as transport
      • no flow control
      • doesn’t tolerate packet loss very well
    • <1% to avoid quality degradation
    • <5% if VoIP gateway provides concealment mechanism
    • Higher compression rates demand lower loss budgets
  • Network Availability & Recovery
    • Availability
      • Common SLA for VoIP network: 99.995% or 26 min/yr
      • Availability needs continue to increase
    • Recovery
      • O(sub-second) to avoid session timeout and new call setup
      • VoIP gateway to gateway recovery usually spans over several segments
      • Layer 3 based network recovery is generally unacceptable
  • Network Security
    • Guard against un-trusted network elements and network-level attacks
    • Stateful and stateless firewall capabilities may be necessary
    • Authentication to Prevent Fraud
      • RADIUS most common deployment
    • Confidentiality is emerging as another basic security requirement for VoIP
      • Carry VoIP traffic within VPN, such as IPsec tunnel or MPLS VPN
      • Increased security vs. encryption overhead for VoIP packet
  • Agenda
    • Packet voice essentials
      • Quick background: VoIP Applications
      • Customer Goals for Voice
      • VoIP Traffic Characteristics
    • Packet voice backbone design
      • Class of service
      • High Availability
      • MPLS
  • Topological Assumptions
    • Routers deployed in pairs at each site
      • Primarily for fault tolerance
      • Also useful for load sharing
    • Intra-site connections required in all topologies
      • Must be at least same capacity as inter-site trunk links
  • Core Topologies
    • Star-connected Core
      • “Outer core” connected to two “super-routers”
      • Simple routing and forwarding
      • Probably least expensive
      • Concerns about redundancy
  • Core Topologies
    • Fully-connected Mesh
      • Each router connected to every other site
      • Also simple routing and forwarding
      • Perhaps most expensive
      • Mesh can always be reduced!
  • Core Topologies
    • Half-mesh router groups
      • Each router connected to ~half of other sites
      • More complex routing and forwarding
      • Many full-mesh benefits without the expense
      • Success depends on engineering to particular needs
  • Edge-core Topologies 1
    • Single uplink per router edge site
      • Two connections to two routers in one core site
      • Availability largely dependent on physical layout
      • Usually lowest cost
  • Edge-core Topologies 2
    • Single uplink per router edge site
      • Two site connections to two separate routers
      • Availability depends on physical media
      • Somewhat low cost
  • Edge-core Topologies 3
    • Partially duplicated edge router uplinks
      • Three connections to three separate routers
      • One dual-homed, one not
      • Particularly useful in MPLS topologies
      • High availability
      • Somewhat high cost
  • Edge-core Topologies 4
    • Fully duplicated edge router uplinks
      • Four connections to four separate routers
      • Both edge routers dual-homed
      • Highest availability
      • Highest cost
  • Site Connection to Edge Routers
    • Many variants on dual-homed designs possible
    • Essential idea is suitable for gateway or softswitch sites
    • Best-effort traffic may enter through separate aggregation points
    Media Gateways
  • IGP Selection
    • Two options:
      • ISIS
      • OSPF
    • Very close race!
    • Biggest issue is probably legacy deployment in current network, and customer comfort.
    • ISIS has slight edge in terms of sub-second failure detection
    • Main point is that a successful network can be built with either.
  • IGP Configuration
    • Issues to consider
      • Hierarchy (areas or levels)
      • Hello Timers
        • BFD changes things here!
      • Authentication for security
      • Addressing plan
        • ISIS requires ISO NET lo0 addresses
      • Metrics
      • Load balancing
  • Load-balancing Considerations
    • Two approaches to load balancing
      • Per-destination
        • Single path chosen from equal-cost next hops
        • Simpler to predict
      • Per-flow
        • Flow distributed between equal-cost next hops
        • Policy can restrict potential traffic path
    • Choice depends primarily on topology and other requirements
    • Most voice engineers more comfortable with per-destination
  • Forwarding Protection Protocol Options
    • Link Redundancy
      • MLPPP – T1/E1 Link aggregation
      • 802.3ad – Ethernet aggregation
      • SONET/SDH aggregation
    • SONET/SDH APS/MPS
    • Virtual Router Redundancy Protocol (VRRP)
    • Standard IGP protocols
      • OSPF
      • ISIS
    • Bidirectional Forwarding Detection (BFD)
  • Bidirectional Forwarding Detection (BFD)
    • IETF Draft co-authored by Juniper and Cisco
    • Optimized timer-based link failure detection protocol
      • Brings link failure detection in line with today’s high-speed transport technologies
    • Reduces link failure recognition from seconds to 10’s of milliseconds
      • Provisionable for link/service requirements
    • Operates at packet forwarding plane
      • Independent from routing protocols and applications
    • When run between edge router and media gateway, provides network resource to VoIP service link
  • MG to Router Connection with BFD
    • VoIP Line Card Failure
      • Connectivity of A1 protected by B1 (vice-versa)
        • Call preserved only under specific MG application control
    • Router PIC Failure
      • Connectivity of A1 and B1 protected by A2 and B2 respectively (vice-versa)
        • Call preserved with packet-loss period (dependant on detection and re-route times)
    • Router System Failure
      • Connectivity of A and B protected by Abu and Bbu respectively (vice-versa)
    MG BFD-A1 BFD-B1 BFD-B2 BFD-A2 BFD-A1bu BFD-B1bu BFD-B2bu BFD-A2bu VoIP Line Cards Line Cards Line Cards
  • Agenda
    • Packet voice essentials
      • Quick background: VoIP Applications
      • Customer Goals for Voice
      • VoIP Traffic Characteristics
    • Packet voice backbone design
      • Class of service
      • High Availability
      • MPLS
  • IP CoS Functions
    • IP Flow
    • IP Precedence bits , DSCP Byte
    • MPLS CoS bits
    • Incoming Physical Interface
    • Incoming Logical Interface
    • Destination IP address
    Priority Queuing Traffic Classification & Marking Per-flow Rate Policing Congestion Avoidance W R R RED PLP=0 100% 100% PLP=1 Stream 100%
  • Converged Network CoS Design
    • In a voice / best effort network, three classes (at least) of service are necessary:
      • IP network control traffic
        • Low bandwidth requirements, not sensitive to latency, jitter
        • Must not be starved
      • Voice signaling and bearer traffic
        • Highest latency and jitter requirements
      • Best effort data traffic
        • Whatever capacity is left
    • More complex configurations may or may not be needed in other network designs (e.g. with VPN service)
    • More classes = more complexity, no way around this.
  • Converged Network CoS Design
    •  Queue 0 : IP Network Control traffic
      • Allocated bandwidth : 5% (the default for NC)
      • Priority: High; this guarantees that NC traffic will never be starved of bandwidth.
      • No RED drop profile assigned, as NC traffic should never be dropped.
  • Converged Network CoS Design
    •  Queue 3 : Voice Signaling and Bearer traffic
      • Initial requirement is 50% of total traffic.
      • Allocated bandwidth: 20%; although doesn’t really matter as this queue gets strictly high priority.
      • Strictly High Priority: voice can take as much bandwidth as it needs.
    • RED drop profile: drop nothing until queue is full, then drop everything.
      • Dropping packets randomly is not very suitable on voice traffic.
      • Forces head dropping (rather than tail dropping) once queue is full.
  • Converged Network CoS Design
    •  Queue 1 : Best effort
      • Allocated bandwidth: remaining 75%.
      • Not guaranteed
      • Priority: Low; this traffic is served only if there is no voice traffic, and there is bandwidth available.
      • RED drop profile: medium. This can be fine tuned, perhaps start to drop when queue is 70%, with a probability of 30%, then drop 100% of the traffic when queue fullness reaches 90%.
      • Medium RED drop profile will limit the TCP congestion synchronization phenomena that would occur otherwise.
  • More Services Possible!
    • Multiservice queuing
      • Service VoIP Queue Aggressively to Avoid Filling the Queue
    WRR Service Rate = 5% WRR Service Rate = 65% WRR Service Rate = 15% WRR Service Rate = 15% Queue 0 = 50% Queue 1 = 35% Queue 2 = 10% Queue 3 = 5% VPN Traffic VoIP Traffic Network Control Traffic Best Effort Traffic
  • Agenda
    • Packet voice essentials
      • Quick background: VoIP Applications
      • Customer Goals for Voice
      • VoIP Traffic Characteristics
    • Packet voice backbone design
      • Class of service
      • High Availability
      • MPLS
  • Don’t Stop Sending the Voice!
    • It doesn’t matter what happens otherwise…
      • Customers only notice when the call is interrupted
    • Many call this idea “Non-Stop Forwarding”
    • Main Principles of NSF
      • Data Plane should not be disrupted
      • Control plane failures should not effect forwarding
      • Failures happen but the infrastructure can recover gracefully
      • Management/Routing sessions can be re-connected unnoticed
    • Many Vendors Adopting this approach
      • Not all, some favor fully redundant protocol state mirroring
  • Graceful Restart - How ?
    • Restarting node preserves the forwarding state
    • Control plane failure known only to the Routing peers
    • Routing peers preserve routing information of restarting node
    • Restarting node (re)learns its routing information from its routing peers
    • No preservation of any of the protocol-related state across the restart on restarting node
  • Graceful Restart - How ? P P P P PE 1 PE 2 PE 3 Separate control and data planes Other routers are never made aware of failure Neighbors hide failure from all others routers in the network When router recovers, neighbors sync up without disturbing forwarding. If router’s control plane fails, data plane can keep forwarding packets
  • Graceful Restart - How ? (cont.)
    • Graceful restart mechanisms are protocol specific:
      • BGP for Interdomain routing
      • ISIS and OSPF for IGPs
      • LDP and RSVP for LSP management
      • BGP/MPLS specific to MPLS VPN management
      • RIP – already built in, but a draft nonetheless
    • All these are currently IETF drafts, but implemented by major vendors
    • (this isn’t an unusual situation, many examples of this these days)
  • Hitless RE Switchover
    • Protects against Single Node Hardware Failure
    • Primary (REP) and Secondary (RES) utilize keepalive process
      • Automatic failover to RES
      • Synchronized Configuration
    • REP and RES share:
      • Forwarding info + PFE config
    • REP failure does not reset PFE
      • No forwarding interruption
      • Only Management sessions lost
      • Alarms, SNMP traps on failover
    Keep Alive Routing Engines Packet Forwarding Engines
  • Agenda
    • Packet voice essentials
      • Quick background: VoIP Applications
      • Customer Goals for Voice
      • VoIP Traffic Characteristics
    • Packet voice backbone design
      • Class of service
      • High Availability
      • MPLS
  • IP-only Path Selection
    • Largely dependent on routing protocols
    • Adjustable only through metrics
      • Changes tend to be global
      • Difficult on per-application basis
      • Extremely manual and labor-intensive in nature
      • Requires offline path computation
  • IP-only Network Reliability Mechanisms
    • Connection-oriented transport (TCP)
      • Not used for realtime traffic like voice
    • Dependence on underlying network infrastructure
      • E.g. SONET/SDH APS, Ethernet VRRP, ATM
      • Not IP-based, therefore not network-wide
    • Routing protocol recovery
      • Relatively slow convergence
      • Potential system-wide effects
      • BFD improves this, but not enough by itself
  • Enter MPLS
    • Low-overhead virtual circuits for IP!
    • Gives many Voice-friendly attributes to IP
      • DiffServ-compatible CoS
      • Deterministic path selection
      • Failure recovery via:
        • Fast reroute
        • Secondary LSPs
      • Planning and determinism through circuit-like traffic engineering
  • MPLS-TE network optimization
    • Traffic engineering allows deterministic paths for Voice and other realtime data, similar to circuit switched networks
    • Constraint-based routing can dynamically choose paths best suited to applications or types of traffic
    Kuala Lumpur Jakarta Manilla Tokyo Hong Kong Seoul Taipei Singpore label-switched-path HK_to_Tokyo { to Tokyo; from Hong_Kong; admin-group {exclude red} cspf}
  • MPLS CoS Capabilities
    • EXP field (and label) can be used for CoS
    • DiffServ-compatible
      • Consistent meanings can exist for MPLS EXP (and label) and IP DiffServ per-hop behaviors
      • Core (MPLS) and edge (IP/DiffServ) PHBs can be related and consistent
    IP Packet 32 bits L2 Header MPLS Header TTL Label (20-bits) CoS S
  • What is Diff-Serv TE ?
    • Diff-Serv: scheduling/queueing behaviour at each node depends on traffic type (indicated by DSCP/EXP setting)
    • MPLS TE: use of constraints to control placement of LSPs. Typically, various traffic classes share the same LSP. Bandwidth reservations do not take account of the classes of traffic involved.
    • MPLS Diff-Serv TE:
      • Traffic divided into up to eight Class-Types.
      • CSPF and RSVP take the Class-Type into account when computing path of LSP.
      • Results in More granular bandwidth reservation.
    • On each link in network, can have separate bandwidth constraints for each type of traffic
      • E.g. limit the bandwidth taken by voice LSPs on a link to a maximum of 40%, data LSPs take the rest.
    • Diff-Serv-aware MPLS Traffic Engineering
    • Guaranteed bandwidth for MPLS
      • Combines MPLS Diffserv and Diffserv TE
      • Provides strict point to point QoS guarantees
    CoS / QoS & Forwarding Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net MPLS Diff-Serv + MPLS DS-TE Aggregated State (DS) Aggregate Admission Control (DS-TE) Aggregate Constraint-based Routing (DS-TE) MPLS Guaranteed Bandwidth No state Aggregated state Per-Flow state Best effort Diff-Serv RSVP v1 & Int-Serv
  • How DS-TE Operates
    • Operations Performed by the Ingress LSR
    Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 1) Store information from IGP flooding 3) Examine user defined constraints 4) Calculate the physical path for the LSP 5) Represent path as an explicit route 2) Store traffic engineering information Routing Table Extended IGP Traffic Engineering Database (TED) User Constraints Constrained Shortest Path First Explicit Route RSVP Signaling
  • MPLS failure recovery
    • Fast reroute allows rapid switching to alternate link segments while longer-term repairs are made
    • Secondary LSPs provide deterministic alternate paths during link failure
    • Possible in a consistent, network-wide manner
  • MPLS Fast Reroute LSR1 LSR2 LSR3 LSR4 LSR5 Primary Primary Primary Primary Detour Detour Detour Single user command at head end to enable Fast Reroute.
    • Fast reroute is signaled to each LSR in the path
    • Each LSR computes and sets up a detour path that avoids the next link and next LSR
    • Each LSR along the path uses the same route constraints used by head-end LSR
  • MPLS Fast Reroute:Recovery Times MSeconds
  • Summary
    • VoIP deployments are going ahead
      • Good for provider profits
      • Good for customer services and needs
    • The question is no longer “if”, but rather “how”
    • Luckily:
      • There are tools that make voice backbones
        • Possible
        • High-quality
        • Profitable
      • Diff-serv, NSF, and MPLS are up to the job
  • Thank You