UMMTS Optimization

RJIL UMMTS OPTIMIZATION

By-Md Mahboob Alam Shubham Guptam

RUMA-II

Reliance Architecture and Terminology

RUMA-II

Unified MPLS Mobile Transport

4

RUMA-II

MPLS Operation

RUMA-II

Transport Architecture-Access to Core

Large Network, Multi-Area Design with IP/MPLS Access

Single AS

May 22 2015

Lesson 2MPLS Traffic Engineering

RUMA-II

Reliance Jio Infocomm Limited 7

RUMA-II

Traffic Engineering Overview

• Traffic engineering is manipulating your traffic to fit your network.• Network engineering is building your network to carry your

predicated traffic.• TE is commonly used in voice telephony networks.• TE is a process of measures, models, and controls of traffic to

achieve various goals.• TE for data network provides an Integrated approach to managing

traffic at Layer 3.

Confidential

RUMA-II


RUMA-II

Traffic Engineering Motivations

• Reduce the overall cost of operations by more efficient use of bandwidth resources.• Prevent a situation where some parts of a network are over utilized (congested), while

other parts remain under utilized.• Implement traffic protection against failures.• Enhance SLA in combination with QoS.

Confidential

RUMA-II


RUMA-II

Business Drivers for Traffic Engineering

• Routers forward traffic along the least-cost route discovered by routing protocols.• Network bandwidth might not be efficiently utilized:• The least-cost route might not have enough resources to carry all the

traffic.• Alternate paths might be underutilized.

Confidential

RUMA-II


RUMA-II

Business Drivers for Traffic Engineering (Cont.)

• Lack of resources results in congestion in two ways:• When network resources themselves are insufficient to accommodate

offered load.• When traffic streams are inefficiently mapped onto available resources

• Some resources are over utilized while other remain under utilized.

Confidential

RUMA-II


RUMA-II

Traffic Engineering with a Layer 3 Model

Layer 3 Model with No Traffic Engineering

Confidential

RUMA-II


RUMA-II

Traffic Engineering with a Layer 3 model

• The current forwarding paradigm, centered around “ destination-based”, is not enough.• Support for “explicit” routing (source routing) is not enough.• Supported workarounds are static routes, policy routing.• Provide controlled backup and recovery.

Confidential

RUMA-II


RUMA-IITraffic Engineering with the MPLS TE Model

• Tunnel is assigned labels that represent the path (LSP) through the system.• Forwarding within the MPLS network is based on label (no Layer 3 lookup).

Confidential

RUMA-II


RUMA-IITraffic Engineering with the MPLS TE Model (Cont.)• The MPLS TE LSPs are created by RSVP.• The actual path can be specified:

• Explicitly defined by the system administrator• Dynamically defined using the underlying IGP protocol

Confidential

RUMA-II


RUMA-II

Traffic Tunnels: Concepts

The concept of MPLS TE traffic tunnels was introduced to overcome the limitations of hop-by-hop IP routing:

• A tunnel is an aggregation of traffic flows that are placed inside a common MPLS label-switched path.

• Flows are then forwarded along a common path within a network.

Confidential

RUMA-II


RUMA-II

Traffic Tunnels: Concepts (Cont.)

• The unidirectional single class of service model encapsulates all of the traffic between an ingress and an egress router.• The different classes of service model assigns traffic into separate tunnels with

different characteristics.

Confidential

RUMA-II


RUMA-II

Traffic Tunnels: Characteristics

• A traffic tunnel is distinct from the MPLS LSP through which it traverses:• More than one TE tunnel can be defined between two points:

• Each tunnel may pick the same or different paths through the network.• Each tunnel will use different MPLS labels.

• A traffic tunnel can be moved from one path onto another, based on resources in the network.

• A traffic tunnel is configured by defining its required attributes and characteristics.

Confidential

RUMA-II


RUMA-II

Traffic Tunnels: Attributes

• Attributes are explicitly assigned through administrative action.• A traffic tunnel has several characteristics:

• Its ingress (headend) and egress (tail end) label switch routers• The forwarding equivalence class that is mapped onto it• A set of attributes that determine its characteristics

Confidential

PE1

Headend

PE3

Tail End

TT1

PE2 PE4

RUMA-II


RUMA-II

Traffic Tunnels: Attributes (Cont.)

• The administrator enters the relevant information (attributes) at the headend of the traffic tunnel:• Traffic parameter: Resources required for tunnel (for example, required

bandwidth)• Generic path selection and management: Path can be administratively specified

or computed by the IGP• Resource class affinity: Can include or exclude certain links for certain traffic

tunnels• Adaptability: Traffic tunnel to be reoptimized?• Priority and preemption: Importance of a traffic tunnel and possibility for a

preemption of another tunnel• Resilience: Desired behavior under fault conditions

Confidential

RUMA-II

RUMA-II

Network Links and Link Attributes

• Resource attributes (link availability) are configured locally on the router interfaces:• Maximum bandwidth

• The amount of bandwidth available• Link affinity string

• Allows the operator to administratively include or exclude links in path calculations• Constraint-based specific metric

• The TE default metric

RUMA-II

RUMA-II

Constraint-Based Path Computation

• Constraint-based routing is demand-driven.• Resource-reservation-aware routing paradigm:

• Based on criteria including, but not limited to, network topology • Calculated at the edge of a network:

• Modified Dijkstra algorithm at tunnel headend (CSPF [constraint-based SPF] or PCALC [path calculation])

• Output is a sequence of IP interface addresses (next-hop routers) between tunnel endpoints

RUMA-II

RUMA-II

Constraint-Based Path Computation (Cont.)

• Constraint-based routing takes into account these three elements :• Policy constraints associated with the tunnel and physical links • Physical resource availability • Network topology state

• Two types of tunnels can be established across those links with matching attributes:• Dynamic—Using the least-cost path computed by OSPF or IS-IS• Explicit—Using a path that is defined with Cisco IOS configuration commands

RUMA-II


RUMA-II

Confidential

Constraint-Based Path Computation (Cont.)RUMA-II


RUMA-II

Confidential

Constraint-Based Path Computation (Cont.)RUMA-II

RUMA-II

Traffic Engineering Processes

• Information distribution• Path selection and calculation• Path setup• Tunnel admission control• Forwarding of traffic on to tunnel• Path maintenance

RUMA-II

RUMA-II

Role of RSVP in Path Setup Procedures

• When the path has been determined, a signaling protocol is needed:• To establish and maintain label-switched paths (LSPs) for traffic tunnels• For creating and maintaining resource reservation states across a network (bandwidth

allocation)• Resource Reservation Protocol (RSVP) was adopted by the MPLS workgroup of the

IETF.

RUMA-II

RUMA-II

Path Setup with RSVP

• When the path has been calculated, it must be signaled across the network.• Reserve any bandwidth to avoid “double booking” from other TE reservations.• Priority can be used to preempt low priority existing tunnels.

• RSVP is used to set up TE LSP.• PATH message (from head to tail) carries LABEL_REQUEST.• RESV message (from tail to head) carries LABEL.

• When the RESV message reaches the headend, the tunnel interface is up.• RSVP messages exist for LSP teardown and error signaling.

RUMA-II

RUMA-II

RSVP and Tunnel Admission Control

• On receipt of PATH message:• Router checks whether there is bandwidth available to honor the reservation.• If bandwidth is available, then RSVP is accepted.

• On receipt of a RESV message:• Router actually reserves the bandwidth for the TE LSP.• If preemption is required, lower priority LSPs are torn down.

• OSPF or IS-IS updates are triggered.

RUMA-II

RUMA-II

Forwarding Traffic to a Tunnel

• IP routing is separate from LSP routing and does not see internal details of the LSP.• The traffic must be mapped to the tunnel:

• Static routing: The static route in the IP routing table points to an LSP tunnel interface.• Policy routing: The next-hop interface is an LSP tunnel.• Autoroute: SPF enhancement

• The headend sees the tunnel as a directly connected interface (for modified SPF only).• The default cost of a tunnel is equal to the shortest IGP metric, regardless of the path

used.

RUMA-II

RUMA-II

IP Forwarding Database Modification with Autoroute

• The autoroute feature enables the headend to see the LSP as a directly connected interface:• This feature is used only for the SPF route determination, not for the constraint-based path

computation.• All traffic that is directed to prefixes topologically behind the tunnel endpoint (tail end) is

forwarded onto the tunnel.• Autoroute affects the headend only; other routers on the LSP path do not see the

tunnel.• The tunnel is treated as a directly connected link to the tail end.

RUMA-II


RUMA-II

Confidential

Autoroute Topology (OSPF and IS-IS)

Tunnel 1: R1-R2-R3-R4-R5

Tunnel 2: R1-R6-R7-R4

RUMA-II


RUMA-II

Confidential

Autoroute Topology (OSPF and IS-IS) (Cont.)

From the perspective of R1: Next hop to R5 is Tunnel 1.

Next hop to R4 and R8 is Tunnel 2. All nodes behind the tunnel are routed via the tunnel.

3232

RUMA-II

May 22, 2015

RUMA-II

Module-IIIHigh Availability and Fast convergence


RUMA-II

High Availability and Fast convergence

• Lesson 1: FRR• Lesson 2: LFA• Lesson 3: NSF/NSR – ISIS,BFD• Lesson 4: BGP-NHT&PIC

Confidential

May 22, 2015

RUMA-II

Lesson 1:Fast Reroute (FRR)

RUMA-II

Fast Reroute

•Preconfigured backup tunnels

•Notification through IGP and RSVP.

•Headend attempts to establish a new LSP (rerouting).

RUMA-II

Fast Reroute: Case Study

RUMA-II

• Link Protection for the Core 1–Core 6 Link

Link Protection with FRR

RUMA-II

Node Protection with FRR

• Node Protection for Core 5

End-to-end tunnel onto which data normally flows

Bypass (backup) static tunnel to take if there is a failure

POP A

Core 1

Core 7

Core 6

POP B

POP C

Protected Node

Next-Next-Hop Backup Tunnel

X

RUMA-II

Cisco Nonstop Forwarding

• Cisco NSF is applicable in platforms with dual RPs and works together with SSO.• Cisco NSF allows:

• Routing neighbor relationships remain established during SSO.• Routes on neighboring routers remain valid.• Forwarding of data packets continues while routing process on new RP converges.

• Cisco NSF is supported by:• Routing protocols (OSPF, IS-IS, EIGRP, BGP)• Forwarding operation (Cisco Express Forwarding)

• Device has to be Cisco NSF-capable.• Neighboring device has to be Cisco NSF-aware.

RUMA-II

Cisco NSF Overview

• One RP is active, one is standby.• Cisco Express Forwarding on the active RP synchronizes the FIB and adjacency

table to the standby RP.• Upon switchover, the new active RP uses the old FIB and adjacency table to

forward packets while the routing protocol reconverges.• BGP has to:

• Establish neighbor relationship without causing a reset of neighbor relationship.• Learn routing information.

• As the routing protocol starts to repopulate the RIB, it updates Cisco Express Forwarding.

June, 2015

RUMA-II

Lesson 2:LFA (Loop Free Alternate)


RUMA-II

LFA FRR (Loop Free Alternate Fast Reroute)

Confidential


RUMA-II

Remote LFA FRR (Loop Free Alternate Fast Reroute)

Confidential


RUMA-II

Remote LFA FRR Protection

Confidential


RUMA-II

Remote LFA FRR- Comparison

Confidential


RUMA-II

Remote LFA FRR- Benefits

Confidential

May 22, 2015

RUMA-II

Lesson 4:BGP PIC & Bidirectional forwarding

RUMA-II

BGP Prefix Independent Convergence

• PIC enhances BGP convergence, regardless of number of BGP prefixes.• PIC stores BGP backup/alternate path for each prefix in BGP, RIB, and FIB tables.• When the primary goes down, CEF quickly selects different egress port for affected

destination.

SPAS 123Customer CE1

CE2

PE1

PE2

Internet

RUMA-II

Bidirectional Forwarding Detection for BGP

BFD Control PacketsEcho Packets

R1 R2

• Extremely lightweight hello protocol that uses UDP to test bidirectional communication

• Used to detect failures in the forwarding path between two adjacent routers• Millisecond resolution of forwarding plane failure• Relies on routing protocols to detect neighbors

RUMA-II

• Routing protocol (BFD client) bootstraps BFD to create BFD session to a neighbor:• BFD client receives link status change notification. • Receive and transmit intervals are negotiated and configurable.

• Two systems agree on a method to detect failure.• In case of failure, BFD notifies BFD client:

• BFD client independently decides on action.

BFD Operation

R1 R2

BGP Neighbors

BFD Neighbors

BGP BFD

BFD BFD

BGP Bootstraps BFD

May 22, 2015

RUMA-II

Thank You

Documents

UMMTS Optimization