The Future of Packet Handling Alan Taylor. The Future of Packet Handling From Internet to...

The Future of Packet Handling

Alan Taylor

The Future of Packet HandlingFrom Internet to Infrastructure

Legacy Data

Internet InternetNew Public Network

Voice

Cap

Grow

Cap

Mobile

Public

IP

Legacy Data

Voice

Maintain reliability and quality

Grow IP to Multi-terabit

Cable

Agenda

Packet Handling Routing Nodes

Packet Handling across the Network Diffserv Traffic Engineering

Packet Handling with Optical Paths GMPLS

System Partitioning

Update

ForwardingTable

PacketPacketProcess

orProcess

or

Switch FabricSwitch Fabric

ForwardingTable

Routing Software OSRouting Software OS

I/O CardI/O Card

Optimum System Partitioning Clean division of

tasks Each partition is a

consistent interface Light traffic levels

across partition Independent scaling

design decisions Each block works

well within its limits

#1

#2

#3

Routing Software OS

Purpose built for Internet scale

Optimised for stability as never in forwarding path

Modular design for high reliability

Processes run in their own protected memory space

Modules can be restarted independently and gracefully

Best-in-class routing protocol implementations

Operating SystemOperating System

Pro

tocols

Ad

jacen

cy M

gm

t

Ch

assis

Mg

mt

SN

MP

Secu

rity

Optimised Software Partitioning

Co-Operative Multi-tasking Process run until finished Good data consistency Real time functions poorly

served

Pre-Emptive Multi-tasking Scheduled time slices to

each process UNIX-like kernel operation Separate real time

functions Not appropriate for shared

data functions

Operating SystemOperating System

Pro

tocols

Ad

jacen

cy M

gm

t

Ch

assis

Mg

mt

SN

MP

Secu

rity

Agenda




What Is Traffic Engineering?

Ability to control traffic flows in the network

Optimize available resources

Move traffic from IGP path to less congested path

SourceSource DestinationDestination

Layer 3 RoutingLayer 3 Routing Traffic EngineeringTraffic Engineering

Traffic Engineering with MPLS

IngressIngressLSRLSR

EgressEgressLSRLSR

Common IP control plane Explicitly routed MPLS path Controlled from ingress using RSVP signalling Constraint Based Routing extensions to IS-IS

or OSPF Fast Reroute reliability options

User defined LSP User defined LSP constraintsconstraints

Routing TableRouting Table

Extended IGPExtended IGP

Traffic EngineeringTraffic EngineeringDatabase (TED)Database (TED)

UserUserConstraintsConstraints

ConstrainedConstrainedShortest Path FirstShortest Path First

Constraint-Based Routing: Service Model

Operations Performed by the Ingress LSROperations Performed by the Ingress LSR

1) Store information from IGP flooding1) Store information from IGP flooding

3) Examine user defined constraints3) Examine user defined constraints

4) Calculate the physical path for the LSP4) Calculate the physical path for the LSP

5) Represent path as an explicit route5) Represent path as an explicit route

6) Pass ERO to RSVP for signaling6) Pass ERO to RSVP for signaling

2) Store traffic engineering information2) Store traffic engineering informationExplicit RouteExplicit Route

RSVP SignalingRSVP Signaling

ParisParis

LondonLondon

StockholmStockholm

MadridMadrid

RomeRome

GenevaGeneva

MunichMunich

label-switched-path madrid_to_stockholm{ to Stockholm; from Madrid; admin-group {include red, green} cspf}

Constraint-Based Routing Example

Combines Traffic Engineering with Diffserv

MPLS paths meeting per class service requirements

Constraint Based Routing per Class Bandwidth constraints per ClassAdmission Control per Class over different

bandwidth pools Independent Preemption PrioritySpecified in draft-lefaucheur-diff-te-proto-01.txt

Diffserv Aware Traffic Engineering





ConstrainedConstrainedShortest Path FirstShortest Path First

Constraint-Based Routing: Service Model

Operations Performed by the Ingress LSROperations Performed by the Ingress LSR

1) Store information from IGP flooding1) Store information from IGP flooding

3) Examine user defined constraints3) Examine user defined constraints

4) Calculate the physical path for the LSP4) Calculate the physical path for the LSP

5) Represent path as an explicit route5) Represent path as an explicit route

6) Pass ERO to RSVP for signaling6) Pass ERO to RSVP for signaling

2) Store traffic engineering information2) Store traffic engineering informationExplicit RouteExplicit Route


Constraint-Based Routing: Extended IGP

Distributes topology and traffic engineering information

IGP Extensions Maximum reservable bandwidth per CT Remaining reservable bandwidth per CT Link administrative groups (colour)

Mechanisms Opaque LSAs for OSPF New TLVs for IS-IS





Constrained ShortestConstrained ShortestPath First (CSPF)Path First (CSPF)

Explicit RouteExplicit Route


Constraint-Based Routing: TED








Maintains traffic engineering information learned from theextended IGP

Contents Up-to-date network

topology information Current reservable bandwidth

of links per CT Link administrative groups

(colours)

Constraint-Based Routing: User Constraints

User-defined constraints appliedto path selection

Bandwidth requirements per CT Hop limitations Administrative groups (colors) Priority (setup and hold) Explicit route (strict or loose) Overbooking per CT Preemption Priority for each class








Constraint-Based Routing: CSPF Algorithm








For LSP = (highest priority) to (lowest priority)For LSP = (highest priority) to (lowest priority)

Prune links with insufficient bandwidth Prune links with insufficient bandwidth for CTfor CT

Prune links that do not contain an included colorPrune links that do not contain an included color

Prune links that contain an excluded colorPrune links that contain an excluded color

Calculate shortest path from ingress to egressCalculate shortest path from ingress to egress

Select among equal-cost pathsSelect among equal-cost paths

Pass explicit route to RSVPPass explicit route to RSVP

END FOREND FOR

NewNewYorkYork

AtlantaAtlanta

ChicagoChicago

SeattleSeattle

LosLosAngelesAngeles

SanSanFranciscoFrancisco

KansasKansasCityCity

DallasDallaslabel-switched-path SF_to_NY {label-switched-path SF_to_NY { to New_York;to New_York; from San_Francisco;from San_Francisco; CT EFCT EF BW 100 MB;BW 100 MB;}}

Constraint-Based Routing: with DS-TE

Agenda




IP Service(Routers)

Optical Transport(OXCs, WDMs)

Optical Core

The Emerging Two-Layer Network

Packet Routing Layer provides- Any-to-any datagram connectivity Packet Processing granularity Class of Service classification and handling IP service delivery

Optical Layer provides flexible optical bandwidth

Dynamic provisioning of optical bandwidth provides growth and innovative service creation

Generalized MPLS

Extends MPLS control plane to support multiple switching types Packet switching TDM switching (SONET/SDH) Wavelength switching (lambda) Physical port switching (fiber)

GMPLS sets up LSPs of a particular type (therefore between like devices / ports) Eg, Router-to-Router using TDM or -switch; Or, TDM-to-TDM using -switch; Etc.

Generalized MPLS

Uses existing and evolving technologies Based on IP routing and signaling Builds on MPLS, and includes MPLS Distinction: packet vs. non-packet MPLS

Is not a protocol, but a suite of protocols Just as MPLS is not a protocol

Facilitates parallel evolution in the IP and transmission domains

“Supports” peer and overlay models

Overlay and Peer Models

Overlay model Two independent control planes

IP/MPLS routing

Optical domain routing

Router is client of optical domain

Optical topology invisible to routers

Peer model Single integrated control plane

Router and optical switches are peers

Optical topology is visible to routers

?

GMPLS Mechanisms

Extensions to OSPF and IS-IS Forwarding adjacency LSP hierarchy Constraint-based routing Signaling extensions Link Management Protocol (LMP) Link bundling

ISIS extensions to carry GMPLS information New sub-TLVs for Extended IS Reachability TLV

Outgoing/Incoming Interface Identifier Maximum LSP Bandwidth Link protection

New TLVs Link descriptor (encoding and transmission rate) Shared risk link group (list of SRLGs)

Defined in draft-ietf-isis-gmpls-extensions-09.txt

GMPLS: IGP Extensions

OSPF extensions to carry GMPLS information New sub-TLVs for the Link TLV within the TE Opaque LSA

Outgoing/Incoming Interface Identifier Link protection type Link descriptor (encoding and transmission rate) Shared risk link group (list of SRLGs) Maximum LSP bandwidth sub-TLV (replaces maximum link

bandwidth)

Defined in draft-ietf-ccamp-ospf-gmpls-extensions-05.txt

GMPLS: IGP Extensions

GMPLS: Forwarding Adjacency

A node can advertise an LSP into IGP Establish LSP using RSVP/CR-LDP signaling IGP floods FA-LSP Link state database and traffic engineering database

maintains conventional links & FA-LSPs A second node wanting to create an LSP can use an FA-

LSP as a”link” in the path for a new lower order LSP The second node uses RSVP to establish label bindings

for the lower order LSP

ATMSwitch

ATMSwitch

SONET/SDHADM

SONET/SDHADM

Ingress Node(high order LSP)

Egress Node(high order LSP)

FA-LSP

Ingress Node(low order LSP)

Egress Node(low order LSP)

GMPLS: LSP Hierarchy

Improves scalability through LSP aggregation Packet capable links can support multiple levels

via label stacking Allows hierarchy of link aggregation

mechanisms LSPs always start and terminate on similar

interface types Achieved via construction of LSP regions

FA-LSC

FA-TDMFA-PSC

BundleBundleFiber nFiber n

Fiber 1Fiber 1

FSC CloudLSC

CloudTDMCloud

PSCCloud

LSCCloud

TDMCloud

PSCCloud

ExplicitLabel LSPs

Time-slotLSPs Fiber LSPsLSPs

ExplicitLabel LSPs

Time-slotLSPsLSPs

(multiplex low-order LSPs) (demultiplex low-order LSPs)


Routing TableRouting Table Traffic EngineeringTraffic EngineeringDatabase (TED)Database (TED)




GMPLS: Constraint-Based Routing

Reduce the level ofmanual configuration

Input to CSPF: Path performance

constraints Resource availability Topology information

(including FA-LSPs) Output: Explicit route

for GMPLS signaling


Label Related Formats Generalized Label Request

Link Protection Type LSP Encoding Type

Generalized Label Object supports implicit TDM, λ, or fiber labels

Suggested Label Label Set

Support for bidirectional LSPs

GMPLS: RSVP Signaling Extensions

SONET/SDHADM

SONET/SDHADM

RESVRESV

PATHPATH

GMPLS: Link Management Protocol

Core functions of the Link Management Protocol Control channel management Link property correlation

Additional tools specified for LMP Link connectivity verification Fault isolation

See draft-ietf-ccamp-lmp-03.txt

LMPLMP LMPLMP LMPLMP LMPLMP

Conclusion

Routing Nodes based on clean and consistent partitioning Hardware and software

Handling different traffic classes across the Network Diffserv Traffic Engineering

Routing Layer interaction with Optical Paths GMPLS

Thank You

http://www.juniper.net

The Future of Packet Handling Alan Taylor. The Future of Packet Handling From Internet to...

Documents

Transcript of The Future of Packet Handling Alan Taylor. The Future of Packet Handling From Internet to...