Constraint-Based Unicast and Multicast: Practical Issues

1

IMIC, 8/30/99

Constraint
-
Based Unicast and Multicast:

Practical Issues

Bala Rajagopalan

NEC C&C Research Labs

Princeton, NJ

braja@ccrl.nj.nec.com

2

IMIC, 8/30/99

What is Constraint
-
Based Routing?

•
Includes QoS
-
based routing and policy routing

•
New jargon to establish technical territory

•
Devised in the context of MPLS LSPs, but applies to microflows also
(generically, “flows”)

Flow with BW,
Delay, Loss &
Policy
Requirements

Link with bw, delay, loss
properties

Network with
bw, delay, loss
properties

Inter
-
domain
routing policies

Source

Dest

3

IMIC, 8/30/99

A Methodology for IP Network Design

Flow
Routing

Node
-
Pair Traffic
Demands & Initial
Topology

Link Capacity
Determination

Traffic Flow
on Links

Scheduling &
Buffering Scheme

Topology Optimization

Network Topology
& Routing

•

Constraint
-
based routing capability results in efficient design and resource utilization

4

IMIC, 8/30/99

Traffic Engineering and Constraint Based Routing

•
Current

TE

goal

is

to

map

traffic

onto

the

network

such

that

available

resources

are

utilized

efficiently

and

QoS

requirements

of

traffic

is

satisfied

•
MPLS

LSPs

are

envisioned

for

creating

virtual

trunks

that

carry

traffic

between

node

pairs

(equivalent

of

frame
-
relay

or

ATM

PVCs)
.

LSPs

isolate

resources

for

different

flow

aggregates

LSP 1

LSP 2

LSP 3

Microflows within an LSP

Routing constraints:

•

Resource requirement

•

Priority & Preemption

•

Policy

•

Resiliency requirement

Re
-
optimization of routing

5

IMIC, 8/30/99

Service Models (1) : VPN

•
Customer provides point
-
to
-
point demands and QoS requirements

•
Service provider capacity engineers and establishes virtual trunks (LSPs)

SP Network

Internet

Virtual Trunk

6

IMIC, 8/30/99

Service Model (2) : Diffserv

•
Service provider establishes SLAs with customers

–
SLAs indicate service quality based on traffic parameters

–
SLAs need not require customer specification of traffic matrix



Network design is difficult


SLA1

SLA2

SLA3

SLA4

SP1

SP2

source

dest

Traffic from source to dest must
receive treatment as per SLA1,
even though it goes through a
foreign SP. Also, dest may not be
known apriori.

7

IMIC, 8/30/99

Traffic Engineering for Diffserv

•
In principle:

–
Derive

point
-
to
-
point

demands

from

SLAs

and

traffic

measurements

–
Determine

virtual

trunking

requirements

between

node

pairs

–
Establish

trunks

using

CBR

dest

SLA1

SLA2

SLA3

SLA4

SP1

SP2

source

Virtual Trunks

8

IMIC, 8/30/99

Constraint
-
Based Routing Model in Summary

•
Given
:

Network

topology,

resource

availability,

policy

and

other

attributes

of

nodes

and

links

•
Flows
:

Aggregated

microflows

or

virtual

trunks

•
Dynamism
:

Keep

track

of

network

state

changes
;

dynamic

rerouting

of

flows

after

topological

changes
;

redundant

paths

and

load
-
balancing?

•
Routing

architecture
:

Distributed

•
Route

computation
:

Based

on

apriori

notions

of

optimization

of

resource

usage,

traffic

parameters,

routing

metrics,

etc
.

•
Route

computation

trigger
:

By

operator

using

offline

mechanisms

•
Route

maintenance
:

Based

on

specified

policies

•
Multicast
:

??


9

IMIC, 8/30/99

Practical Issues

•
Scalability
:

No

experience

with

large
-
scale

state
-
dependent

routing

in

the

Internet
;

current

proposals

limited

to

intradomain

flat

networks

•
Interdomain

Routing
:

State

transfer

between

domains

for

CBR?

•
Flexibility

in

Routing
:

CBR,

being

a

tool

for

optimization,

invites

proprietary

solutions
.

How

to

accommodate

a

plurality

of

solutions?

•
Multicast
:

What

is

the

model?


–
Static

trees,

computed

centrally

–
Dynamic

trees

on

a

per
-
group

basis?


•
Integration

within

a

service

management

framework
:

Defining

the

interfaces

to

capacity

management,

provisioning,

and

offline

network

analysis
.



10

IMIC, 8/30/99

CBR Approach 1: IGP Extensions (e.g., OSPF)

•
Add

CBR

features

to

existing

IGP

s
.
t
.

changes

are

minimal


•
Some

IGPs

provide

mechanisms

for

adding

new

messages,

e
.
g
.
,

OSPF

transparent

LSAs

Flood Resource LSAs

New route computation proc.

New update procedures

New resource tracking proc.

(only bw defined so far)

Existing DB representation

Only single area considered

Area 1

Area 2

11

IMIC, 8/30/99

CBR Approach 2: Proprietary Protocols

•
Proprietary message formats, update protocols, hierarchy arrangements, database
representation, etc.

•
Proprietary CBR features: Flow definition, priority, preemption, rerouting features, etc.

•
Requires homogeneous equipment

Proprietary Flooding

Area 1

Area 2

12

IMIC, 8/30/99

CBR Approach 3: Distributed Overlay

•
Utilize underlying IGP (DV or link state) for reachability computations

•
Efficient update propagation techniques for scalability (facilitates dynamic routing)

•
IGP
-
independent state representation

–
State aggregation for hierarchical routing possible

–
Metric values not constrained by IGP limitations

•
Requires only the definition of a standard interface between IGPs and CBR protocols, to be
implemented locally

CBR Protocol

CBR Database

Topology Mapping &
Interface Functions

Intra
-
domain LS Protocol

LS Database

To Peers

To Peers

13

IMIC, 8/30/99

CBR Overlay: Essential Ideas

•
CBR protocol utilizes underlying IGP for building an MST of the topology (MST based
on administrative link cost)

•
State information broadcast on the MST

•
State information synchronized and maintained as MST changes

–
Requires interface function to indicate topology change

Pt
-
to
-
Pt or broadcast link

Router

To nodes E
-
I

A

B

C

D

To nodes J
-
M

To nodes N
-
Q

To nodes R
-
W

A: Mcast updates from E
-
I, request sync.
B: Unicast updates from J
-
M
C: Unicast updates from N
-
Q

Network and MST

CBR sync. on a LAN

14

IMIC, 8/30/99

CBR Overlay on OSPF

•
Hierarchical

MST

construction
;

one

for

each

area

and

one

for

the

backbone

•
CBR

topology

database

generated

from

OSPF

database

using

interface

functions


•
Independent

representation

of

network

state,

including

summary

state

for

external

areas

•
Updates

sent

on

backbone

MST

are

propagated

on

area

MSTs

Area 1

Area 2

Backbone Area

Area 1

Area 2

Backbone Area

15

IMIC, 8/30/99

Route Computation