Transcript juniper

End-to-End Network Services:
What is Really Missing?
Mark Williams
Liaison, R&E Networks, APAC
[email protected]
APAN, Singapore, July 18th, 2006
Copyright © 2006 Juniper Networks, Inc.
www.juniper.net
1
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
2
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
3
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
4
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
5
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 Inter-Domain
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
6
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
7
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
8
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-path-comp
Copyright © 2006 Juniper Networks, Inc.
www.juniper.net
9
In other words: great stuff !
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.
Sure, it is a
Great, on our side
lightpath
Iitthink
for A.
willtoo
beitfor
aisλuniv
Me
Do you know
Ah, yes I can
what
is he
Ok, but
have to
provide
Need
toaquestion.
check
check
policies
asking
about?
Good
MPLS
the
interface
Yes.
for circuit
univ
Need
alsoBtoLet’s
check
my
BB
capacity
with
univ
B
build
a mailing
list …
GRID
project
need
the
AndWe
what
aboutX
our
interconnection?
NOCs expertise
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 inter-domain
GMPLS TE
Policing
A 21-A31
Path comp
Path
What is missing ?
R1-A21
Path comp
R1
Path
Bw= 100
CT = IP Premium
Path
A11
NREN 1
A21
A22
Inter-AS TE-LSP R1-R2 : bw = 100m, CT = IP Premium
ASBR-Path: A21-A31-R2


A 31-R2
Path comp
A31
Path
R2
Resv
Resv
NREN 2
A12

Path
A23
Resv
Resv
Resv


Policing
A24
A32
NREN 3
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 LSP 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 expansion)
• 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
Today’s networks
The IPsphere Reference
Architecture
SSS
Today’s 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
What’s 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
Copyright © 2006 Juniper Networks, Inc.
“Hey, I can
offer services
X, Y, and Z!”
“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”
(XML/SOAP)
Service
Directory
“Get Credentials”
XML/SOAP
(UDDI)
Trust Agent
“Confirm
Credentials”
Service Description
“Request Service”
(WSDL)
XML/SOAP
Client
Copyright © 2006 Juniper Networks, Inc.
Service Federation
Service
www.juniper.net
26
What the IPsphere Is…and Isn’t

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 scalability—it doesn’t 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 metrics—as 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-per-service 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