End-to-End Network Services:

What is Really Missing?

Mark Williams
Liaison, R&E Networks, APAC
miw@juniper.net
APAN, Singapore, July 18th, 2006

Copyright 2006 Juniper Networks, Inc.

www.juniper.net

Objective of this presentation

R&E community requires more network services
than simply any-to-any connectivity (commodity
Internet)
Guaranteed bandwidth on Demand, Multicast,
IPv6, VPNs, etc
End-users are rarely both/all connected to one
single network managed by one operator
How can we provide end-to-end services ?
How can we dynamically enable network resource for a
given user and application ?

Copyright 2006 Juniper Networks, Inc.

www.juniper.net

Agenda
1. Current Inter-domain situation
Internet
2. Evolution of inter-domain networking
protocols
Some interesting IETF work
3. What is missing
Towards the standardization of a new
business layer
Copyright 2006 Juniper Networks, Inc.

www.juniper.net

What are the current inter-domain

networking interfaces today ?
R&E net 1

R&E net 2

Multicast

Multicast
IP Premium

VPN
IPv6

IP Premium

MP-EBGP

VPN
IPv6

R&E net 3
Multicast
IP Premium
VPN
IPv6

Copyright 2006 Juniper Networks, Inc.

www.juniper.net

Inter-domain is essentially BGP

BGP is great
Scalable
Implementation: >1.000.000 routers in Forwarding Table
Architecture: Confederations, Route Reflectors, Multiple
Planes, Outbound Route Advertisements, Route Target
Filtering

Multi-protocol: IPv4, IPv6

Multi-service: Unicast, Multicast, L3VPN, L2VPN,
VPLS

BUT it is only about reachability

Copyright 2006 Juniper Networks, Inc.

www.juniper.net

Current Limit of Internet Technologies

Internet proved its any-to-any connectivity
capability
But it is just a connectivity service
Today Public Network lacks:

Dynamic Service Activation of Advanced InterDomain Capabilities characterized by 3

dimensions:
QoS {bandwidth, drop, latency}, Security and
Reliability
Requires new peering capabilities and
techniques
It is no longer a question of just exchanging route
information

Copyright 2006 Juniper Networks, Inc.

www.juniper.net

Agenda
1. Current Inter-domain situation
Internet
2. Evolution of inter-domain networking
protocols
Some interesting IETF work
3. What is missing
Towards the standardization of a new
business layer
Copyright 2006 Juniper Networks, Inc.

www.juniper.net

Examples of Recent Inter-domain

Initiatives in the IETF (1)
Flow Specification Disseminations (or Dynamic
firewall filtering)
draft-marques-idr-flow-spec
Mailing list:
http://www.cqr.org/mailman/listinfo/flow-spec

End to end Inter-domain Multicast with AMT

draft-ietf-mboned-auto-multicast
BSD-based gateway and relay available
today
Open source project funded by Juniper
http://www.mountain2sea.com/amt/

Copyright 2006 Juniper Networks, Inc.

www.juniper.net

Examples of Recent Inter-domain

Initiatives in the IETF (2)
Inter-domain MPLS VPNs and Multicast VPN
draft-raggarwa-l3vpn-2547-mvpn

Inter-domain GMPLS Traffic Engineering

draft-ietf-ccamp-inter-domain-rsvp-te
draft-vasseur-ccamp-inter-domain-pd-pathcomp

Copyright 2006 Juniper Networks, Inc.

www.juniper.net

In other words: great stuff !

Do you
Ah, yes I
know
Ok, what
but have
cantoprovide
Need
to
check
is he Good
asking
question.
a
MPLS
check
the
Yes.also
Lets
policies
for
Need
to
about?
Sure, it is a
circuit
check
interface
Great, on our
univ
Bmy BB
build
a
lightpath
I
think
it
is
for
capacity
side
willfor
beuniv
a A.
with
univ Blist
Meittoo
mailing
GRID
project
We
need
the
what
And
about

our
XNOCs
interconnection?
expertise

But here is what is missing:

Please provide
me one Gb/s
pipe between
Point A and
Point B

Universities,
Research Labs etc

Copyright 2006 Juniper Networks, Inc.

NRENs,
MANs, etc

www.juniper.net

10

Example: Schedulable Deterministic

End to End Pipes
For GRID projects, eVLBI, DEISA, MUPBED, HEC
Facilities, CERN, EGEE etc
Potentially based on Layer 1, 2 or 3 technologies

Copyright 2006 Juniper Networks, Inc.

www.juniper.net

11

Potential implementation with IETF interdomain GMPLS

TE
Policing
Policing
A 21-A31
Path comp
Path

What is missing ?

Path
R1-A21
Path comp Bw= 100

Path
A11

A21

CT = IP Premium

R1

NREN
NREN11

Resv

Resv

A12

Path
A23

A31

Path
R2

Resv

Resv

NREN
NREN22

A22
InterASTELSPR1R2:bw=100m,CT=IPPremium
ASBRPath:A21A31R2

A 31-R2
Path comp

A24

Resv

A32

NREN
NREN33

GMPLS TE is originally intra-domain (RSVP-TE with routing IGP TE extensions)

Inter-domain GMPLS TE extends signaling and routing protocols to set-up an LS
across multiple providers
Need for proper policing and filtering of RSVP-TE messages at NREN boundaries
Filter/modify QoS parameters
Need for scheduling
In this example the Path Computation is performed per domain (route expansio
Need for Provider-chain selection based on NRENs business relationship

Copyright 2006 Juniper Networks, Inc.

www.juniper.net

12

Example: Schedulable Deterministic

End to End Pipes
For GRID projects, eVLBI, DEISA, MUPBED, HEC
Facilities, CERN, EGEE etc
Potentially based on Layer 1, 2 or 3 technologies
Need for a Capacity Management Middleware
Already several initiatives in R&E
However some challenges: Licences, network
technologies required, standard used, multi-domain
support, features/flexibility, security mechanisms,
integration with other tools, vendor dependency

Question: How can we converge to a common tool

supported both by the global R&E community and
the industries?
Copyright 2006 Juniper Networks, Inc.

www.juniper.net

13

Napkins approach
Wish List:
Ubiquity

Limited users, but can be anywhere so it

requires any-to-any capabilities, potentially
Technology independent

Platform/Vendor independent
Domain independent
Federative

Why not solving all on-demand type of

network service at one stroke? Is there a
common framework possible?
Prefigure future public networks

Copyright 2006 Juniper Networks, Inc.

www.juniper.net

14

Agenda
1. Current Inter-domain situation
Internet
2. Evolution of inter-domain networking
protocols
Some interesting IETF work
3. What is missing
Towards the standardization of a new
business layer
Copyright 2006 Juniper Networks, Inc.

www.juniper.net

17

The need for a Business Layer

What is an IPsphere ?
IPsphere

A pan-service framework
Defined by the IPsphere Forum

Leveraging Service Oriented Architecture (SOA)

Providing business structure for IP services

Copyright 2006 Juniper Networks, Inc.

www.juniper.net

18

Did they have NRENs and GRIDs use

case in mind ?
hmmm
But IPsphere offers:
A common framework for all kinds of use cases
Based on standard protocols and technologies
No overlap with other standardization bodies: very
focused on the business layer for a seamless integration

Network Technology independent

Network Management independent
Platform/Vendor independent
Service delivery is Domain independent

A standardized model, with a strong Go-to-Market

motivation
Involves the whole industry: many SPs, manufacturers, OSS,
application vendors

Copyright 2006 Juniper Networks, Inc.

www.juniper.net

19

IPsphere Forum Membership

Alcatel
America Online
Bezeq
Brasil Telecom
Brighthaul
BT
Cellcom
China Unicom
CIMI Corporation
Cisco Systems
Colubris Networks
Datapower
Ericsson
fmc.service
France Telecom
GeoTrust
Huawei
Hewlett Packard
IBM

Copyright 2006 Juniper Networks, Inc.

Juniper Networks
Korea Telecom
Level 3
Lucent Technologies
Masergy
Nexagent
NexTone
Oracle
Packeteer
Polycom
Qwest
Red Zinc
Siemens
T-Com
Time Warner Telecom
T-Systems
Telenor
Tellabs
Telstra
Ulticom

www.juniper.net

20

A model for IPspheres

The IPsphere Reference

Architecture
Service Structuring Stratum

The IPsphere Forum

defines an IPsphere as a
network comprised of
three basic strata

Network Policy & Control

Traffic Handling

Copyright 2006 Juniper Networks, Inc.

www.juniper.net

21

Todays networks

The IPsphere Reference

Architecture
SSS

Todays IP networks reside

in the lower two strata
e.g. NMS, OSS, policy servers

NP&C
e.g. SDH, Routers, firewalls, etc.
TH

Copyright 2006 Juniper Networks, Inc.

www.juniper.net

22

Whats different about an

IPsphere?
The IPsphere Reference
Architecture
SSS

NP&C

TH

Copyright 2006 Juniper Networks, Inc.

IPspheres add a Service

Structuring Stratum which
leverages Service Oriented
Architectures (SOA): no need to
reinvent the wheel

The SSS allows networks to

publish their service
capabilities

www.juniper.net

23

Why is this so important?

The SOA framework using mechanisms like SOAP, XML,
UDDI allows IP networks to publish their service
capabilities into a structured operational framework
Hey, I can
offer services
X, Y, and Z!

Copyright 2006 Juniper Networks, Inc.

Well, I can
offer Y and Z,
but no X!

Just Z for
me!

NP&C

NP&C

NP&C

TH

TH

TH

www.juniper.net

24

The creation of a true business

layer
The Service Structuring Stratum provides this framework
allowing service capabilities to be joined together in
unprecedented ways

SSS

Hey, I can
offer services
X, Y, and Z!

Copyright 2006 Juniper Networks, Inc.

Well, I can
offer Y and Z,
but no X!

Just Z for
me!

NP&C

NP&C

NP&C

TH

TH

TH

www.juniper.net

25

How Web Services create/maintain

Federations
Inherently loosely
coupled approach,
using enables
federations to be as
flexible and
exclusionary as
needed

IPsphere concept adds the

ability for network services
to be described and offered
for attachment
Service
Description
(WSDL)

Publish
Find Service Service
(XML/SOAP)

Directory

Get
XML/SOAP
Credentials

(UDDI)

Request
XML/SOAP
Service
Client

Copyright 2006 Juniper Networks, Inc.

Service Federation

Trust
Agent

Confirm
Credential
s
Service
Description
(WSDL)

Service

www.juniper.net

26

What the IPsphere Isand Isnt

The IPsphere is a model for putting network services into a

business context by linking service creation with service ordering
and fulfillment.

The IPsphere is based on web services principles for the exchange

of business information, making it easy for it to manage the
elements of higher-layer services that require identity
management and reliable communications, including grid
computing and ASP services.

The IPsphere is not a strategy to create services on the network,

provide QoS, or manage resources at the physical level. It is
compatible with most emerging standards, and the IIC will work to
insure it stays that way.

The IPsphere is not an alternative to the Internet, it is an

alternative to the Internet model applied to non-Internet services.

Copyright 2006 Juniper Networks, Inc.

www.juniper.net

27

Conclusion
Deploying a Inter-domain Services requires:
Both a vertical and horizontal approach
A synergy between NREN, end-users (e.g. GRIDs communities),
but also with industries
The problem can be addressed from different angles: but practical
development and standardization work should be conducted
together
The winning solution will be federative, vendor and domain
independent, simple to adapt to any current or future
infrastructures and technologies
The top model will not solve specifically one network service
A common framework for all on-demand network services
IPSPhere Forum: http://www.ipsphere.org/
Overview:
http://www.ipsphereforum.org/newsevents/07nollereprint.pdf

Copyright 2006 Juniper Networks, Inc.

www.juniper.net

28

Thank You !

Copyright 2006 Juniper Networks, Inc.

www.juniper.net

29

Summary

IP-Based but Interoperable with Other Protocols

The IPsphere model is infinitely flexible. It is based on the assumption of a
universal IP core, but is interoperable with other protocols/networks via the CNI

Application-facilitating but not Application Specific

It facilitates the creation of applications like ASP and content services but
without any protocols or elements that are specific to those applications

Managed at the Traffic Partition Level for Efficiency

It manages traffic not at the service level but at the traffic class level for
greater operational scalabilityit doesnt matter how many services you offer,
just how many distinctively different levels of network QoS and security you
offer

Capable of Making Security an Element of Service Quality

With IPspheres, security is the next dimension of QoS after the usual
availability, latency, bandwidth, and loss metricsas it should be

Capable of Supporting Contemporary or New Services

New and legacy services can be mapped to IPsphere infrastructure in the same
way, and new and legacy interfaces can even share a common service.

Capable of Single-Carrier or Connected-Carrier Operation

Finally, IPspheres can be used to support services on a single-carrier-perservice basis or services that extend across multiple carriers. Where the latter
model is used, carrier cooperation and settlement are totally controlled at the
I-ICI

Copyright 2006 Juniper Networks, Inc.

www.juniper.net

30