End-to-End Network Services: What is Really Missing?

1. End-to-End Network Services: What is Really Missing? Mark Williams Liaison, R&E Networks, APAC miw@juniper.net APAN, Singapore, July 18th, 2006

2. 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 ?

3. Agenda • Current Inter-domain situation • Internet • Evolution of inter-domain networking protocols • Some interesting IETF work • What is missing • Towards the standardization of a new “business” layer

4. Multicast Multicast Multicast IP Premium IP Premium IP Premium VPN VPN VPN IPv6 IPv6 IPv6 What are the current inter-domain networking interfaces today ? R&E net 1 R&E net 2 ? MP-EBGP R&E net 3

5. 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

6. 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

7. Agenda • Current Inter-domain situation • Internet • Evolution of inter-domain networking protocols • Some interesting IETF work • What is missing • Towards the standardization of a new “business” layer

8. 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/

9. 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

10. In other words: great stuff !But here is what is missing: Do you know what is he asking about? Ah, yes I can provide a MPLS circuit Ok, but have to check policies for univ B Need to check the interface with univ B Good question. Need also to check my BB capacity Yes. Let’s build a mailing list … Sure, it is a lightpath Please provide me one Gb/s pipe between Point A and Point B Great, on our side it will be a λ I think it is for GRID project X Me too for univ A. And what about our interconnection? We need the NOCs expertise Universities, Research Labs etc… NRENs, MANs, etc…

11. 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

12. Path Path Path Path Path Bw= 100 CT = IP Premium Resv Resv Resv Resv Resv Inter-AS TE-LSP R1-R2 : bw = 100m, CT = IP PremiumASBR-Path: A21-A31-R2 Potential implementation with IETF inter-domain GMPLS TE Policing Policing A 21-A31 Path comp A 31-R2 Path comp What is missing ? • 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 NREN 2 R1-A21 Path comp NREN 1 NREN 3 A31 A11 A23 A21 R2 R1 A32 A24 A12 A22

13. 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?

14. 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

15. Agenda • Current Inter-domain situation • Internet • Evolution of inter-domain networking protocols • Some interesting IETF work • What is missing • Towards the standardization of a new “business” layer

16. The need for a “Business Layer” What is an IPsphere ? A pan-service framework IPsphere Defined by the IPsphere Forum Leveraging Service Oriented Architecture (SOA) Providing business structure for IP services

17. 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

18. 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 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 IPsphere Forum Membership

19. A model for IPspheres The IPsphere Forum defines an IPsphere as a network comprised of three basic “strata” The IPsphere Reference Architecture Service Structuring Stratum Network Policy & Control Traffic Handling

20. Today’s networks The IPsphere Reference Architecture Today’s IP networks reside in the lower two strata SSS e.g. NMS, OSS, policy servers NP&C e.g. SDH, Routers, firewalls, etc. TH

21. What’s different about an IPsphere? IPspheres add a Service Structuring Stratum which leverages Service Oriented Architectures (SOA): “no need to reinvent the wheel” The IPsphere Reference Architecture SSS NP&C The SSS allows networks to “publish” their service capabilities TH

22. 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!” “Well, I can offer Y and Z, but no X!” “Just Z for me!” NP&C NP&C NP&C TH TH TH

23. The creation of a true “business layer” The Service Structuring Stratum provides this framework – allowing service capabilities to be joined together in unprecedented ways “Hey, I can offer services X, Y, and Z!” “Well, I can offer Y and Z, but no X!” SSS “Just Z for me!” NP&C NP&C NP&C TH TH TH

24. “Get Credentials” “Find Service” XML/SOAP (XML/SOAP) Service Description Service Description “Request Service” (WSDL) (WSDL) XML/SOAP 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 “Publish” Service Directory Trust Agent “Confirm Credentials” (UDDI) Service Federation Client Service

25. 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.

26. 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

27. Thank You !

28. 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