Your SlideShare is downloading. ×
0
Inter-domain Routing Issues
Inter-domain Routing Issues
Inter-domain Routing Issues
Inter-domain Routing Issues
Inter-domain Routing Issues
Inter-domain Routing Issues
Inter-domain Routing Issues
Inter-domain Routing Issues
Inter-domain Routing Issues
Inter-domain Routing Issues
Inter-domain Routing Issues
Inter-domain Routing Issues
Inter-domain Routing Issues
Inter-domain Routing Issues
Inter-domain Routing Issues
Inter-domain Routing Issues
Inter-domain Routing Issues
Inter-domain Routing Issues
Inter-domain Routing Issues
Inter-domain Routing Issues
Inter-domain Routing Issues
Inter-domain Routing Issues
Inter-domain Routing Issues
Inter-domain Routing Issues
Inter-domain Routing Issues
Inter-domain Routing Issues
Inter-domain Routing Issues
Inter-domain Routing Issues
Inter-domain Routing Issues
Inter-domain Routing Issues
Inter-domain Routing Issues
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Inter-domain Routing Issues

295

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
295
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • GFP: Generic Framing Procedure VCAT: Virtual Concatenation LCAS: Link Capacity Adjustment Scheme
  • The Service Structuring Stratum is a VPN where business message exchanges take place among IPsphere partners. These exchanges are based on established IT principles of distributed computing called “service-oriented architecture” or “web services”. That means that messages take place between a set of applications (“services”) that represent offered partnership relationships, and a “parent” application that represents the service provider who owns the customer order. Because the IPsphere SSS uses web services standards, the SSS can be viewed as an overlay on the currently defined SOAP and WS protocols, and applications supporting the IPsphere can use web services tools for authentication, reliable messaging, resource modeling, etc. The “services” of the SSS are application elements that translate between SSS messages and protocols that can be used to control the underlying network. These protocols can generally follow one or both of two models: 1. They can be used to set values in a policy database that will then be used to manage interactions at the CNI and ICI points in the network. 2. They can be used to generate commands to the network management system of a network, creating provisioning statements that will then set up network behaviors.
  • A service is created in the IPsphere by executing a “script” that describes how Elements from various contributing partner carriers are to be assembled, parameterized, and interconnected. This script will have, for each contributed element, a sequence of messages for Setup, Execute, and Assure components. Similarly each Element/Component combination will have a Start, Negotiate, Complete, and Alert message handling. Elements are published in a directory (in web services, the UDDI). When the administrative owner receives an order, the order is first translated to a template. This translation process is performed by the administrative owner’s service management system in what is called the “Parent” application. The purpose of this translation or dissection is to select the Elements that will be used to fulfill the order, from the list of available Elements. The process of dissecting an order in this way would include both topology-related selection issues (what providers can reach the necessary points) and policy/pricing/contract issues (who gives the best price, who has the most convenient processes, etc.). When the order has been dissected the output is both a script that lists the involved elements and a template that describes the service to be created. The script then passes the template via the UDDI to the Elements, and the Elements provide a software bridge to the network management/policy management capabilities of the physical network. The Setup Component of the script verifies the participation of each provider and negotiates service attributes. The Execute Component actually initiates the creation of the service on the network, and the Assure Component provides for ongoing operational monitoring.
  • Transcript

    • 1. Schedulable Deterministic End-to-End Pipes Jean-Marc Uzé, juze@juniper.net 2nd TERENA NREN-Grids Workshop, Amsterdam, Monday 17 October 2005
    • 2. Looking at a complex problem from different angles To do: Find x It’s there
    • 3. Requirements for SDE2EP <ul><li>Guaranteed: </li></ul><ul><ul><li>Bandwidth </li></ul></ul><ul><ul><li>Delay </li></ul></ul><ul><ul><li>Jitter </li></ul></ul><ul><ul><li>(no) Packet/Frame Loss </li></ul></ul><ul><ul><li>No reordering </li></ul></ul>Monitoring and Accounting Scheduling Granularity Security Control Failure Restoration … Do you like this acronym?
    • 4. Who needs SDE2EP ? <ul><li>Projects </li></ul><ul><ul><li>E.g. eVLBI, DEISA, GRID Projects (IRIS-GRID, GridIreland, NorduGrid, SEE-GRID, Hungarian ClusterGrid Infrastructure), MUPBED, GN2 Testbed, LOFAR, Evergrow </li></ul></ul><ul><li>Connectivity to research infrastructures </li></ul><ul><ul><li>E.g. HEC Facilities, Earth Observation </li></ul></ul><ul><li>Connectivity with special networks/sites </li></ul><ul><ul><li>E.g. CERN, USA & Starlight </li></ul></ul>
    • 5. How can be provided a SDE2EP ? <ul><li>Layer 1 Technologies </li></ul><ul><ul><li>Wavelength Division Multiplexing (WDM) </li></ul></ul><ul><ul><li>All-optical switches </li></ul></ul><ul><ul><li>SDH/SONET (GFP, VCAT, LCAS) </li></ul></ul><ul><li>Layer 2 Technologies </li></ul><ul><ul><li>Ethernet (plain or VLAN) </li></ul></ul><ul><ul><li>PPP </li></ul></ul><ul><ul><li>Layer 2 MPLS VPNs </li></ul></ul><ul><li>Layer 3 Technologies </li></ul><ul><ul><li>Differentiated Services </li></ul></ul>
    • 6. Need for a Capacity Management Middleware <ul><li>A significant number of tool development initiatives </li></ul><ul><ul><li>BMP, CATI, Operax, SBM, Tequila, DRAC, DRAGON, ODIN, UCLP </li></ul></ul><ul><li>Challenges: </li></ul><ul><ul><li>Licences, network technologies required, standard used, multi-domain support, features/flexibility, security mechanisms, integration with other tools, vendor dependency </li></ul></ul><ul><li>Question: How can we converge to a common tool supported both by the global R&E community and the industries? </li></ul>
    • 7. Napkins approach <ul><li>Wish List: </li></ul><ul><ul><li>Ubiquity </li></ul></ul><ul><ul><ul><li>Limited users, but can be anywhere so it requires any-to-any capabilities, potentially </li></ul></ul></ul><ul><ul><ul><li>Technology independent </li></ul></ul></ul><ul><ul><li>Platform/Vendor independent </li></ul></ul><ul><ul><li>Domain independent </li></ul></ul><ul><ul><li>Perennial </li></ul></ul><ul><ul><li>Federative </li></ul></ul><ul><ul><li>Why not solving all “on-demand” type of network service at one stroke? Is there a common framework possible? </li></ul></ul><ul><ul><li>(Prefigure future public networks) </li></ul></ul>
    • 8. Divide and Conquer Transport Network Higher Layer Middleware Transport Network Business Layer Business Layer Network Management Network Management 3 3 4 4 1 1 2
    • 9. Example of IETF inter-domain GMPLS Traffic Engineering <ul><li>GMPLS TE is originally intra-domain (RSVP-TE with routing IGP TE extensions) </li></ul><ul><li>Inter-domain GMPLS TE extends signaling and routing protocols to set-up an LSP across multiple providers </li></ul><ul><li>Need for proper policing and filtering of RSVP-TE messages at SP boundaries </li></ul><ul><ul><li>Filter/modify QoS parameters </li></ul></ul><ul><li>Need for scheduling </li></ul><ul><li>In this example the Path Computation is performed per domain (route expansion) </li></ul><ul><ul><li>Need for Provider-chain selection based on SPs business relationship </li></ul></ul>SP 1 SP 2 SP 3 R1 R2 A12 A21 A22 A23 A24 A31 A32 A11 Policing Policing R1-A21 Path comp A 21-A31 Path comp A 31-R2 Path comp I nter-AS TE-LSP R1-R2 : bw = 100m, CT = IP Premium ASBR-Path: A21-A31-R2 Path Path Path Path Bw= 100 CT = IP Premium Path Resv Resv Resv Resv Resv
    • 10. Case of PCE Model for Path Computation <ul><li>Collaboration between PCE (Path Computation Element) in each AS to find an inter-provider constrained path (Recursive CSPF) </li></ul><ul><li>Allows for Border Nodes selection but not Provider-chain selection </li></ul><ul><li>Need for Provider-chain selection based on SPs business relationships </li></ul><ul><li>Need for policing of inter-PCE communication </li></ul><ul><li>Need for scheduling </li></ul>SP 1 SP 2 SP 3 R1 R2 A12 A21 A22 A23 A24 A31 A32 PCE PCE PCE Path Response Policing Policing A11 I nter-AS TE-LSP R1-R2 : bw = 100m AS-Path: 1-2-3 Path Request R1-R2 Bw, delay AS-path 1-2-3 Path Response A22-A31-R2
    • 11. The need for a “Business Layer” IPsphere A pan-service framework Defined by the IPsphere Forum Providing business structure for IPservices Leveraging Service Oriented Architecture (SOA) What is an IPsphere ?
    • 12. Why SP’s need IPsphere <ul><li>Enable SP’s to move up the value-chain </li></ul><ul><li>Framework that enable new business models </li></ul><ul><li>Help SP’s move away selling dumb “bits” and create a framework which enables SP’s to sell “services” </li></ul><ul><li>Public Internet isn’t good enough to provide next generation services (ie VoD etc) </li></ul><ul><li>Not a replacement for the Internet </li></ul>
    • 13. Did they have GRIDs use case in the context of SDE2EP and NRENs in mind ? <ul><li>… hmmm … </li></ul><ul><li>But IPsphere offers: </li></ul><ul><ul><li>A common framework for unlimited use cases </li></ul></ul><ul><ul><li>Based on standard protocols and technologies </li></ul></ul><ul><ul><li>No overlap with other standardization bodies: very focused on the business layer for a seamless integration </li></ul></ul><ul><ul><ul><li>Network Technology independent </li></ul></ul></ul><ul><ul><ul><li>Network Management independent </li></ul></ul></ul><ul><ul><ul><li>Platform/Vendor independent </li></ul></ul></ul><ul><ul><ul><li>Service delivery is Domain independent </li></ul></ul></ul><ul><ul><li>A standardized model, with a strong motivation to be quickly deployed in live networks </li></ul></ul><ul><ul><ul><li>Involves the whole industry: many SPs, manufacturers, OSS, application vendors </li></ul></ul></ul>
    • 14. A model for IPspheres The IPsphere Reference Architecture Traffic Handling Network Policy & Control Service Structuring Stratum The IPsphere Forum defines an IPsphere as a network comprised of three basic “strata”
    • 15. Today’s networks The IPsphere Reference Architecture TH NP&C SSS Today’s IP networks reside in the lower two strata e.g. SDH, Routers, firewalls, etc. e.g. NMS, OSS, policy servers
    • 16. What’s different about an IPsphere? The IPsphere Reference Architecture 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 TH NP&C SSS
    • 17. Why is this so important? TH NP&C The SOA framework – using mechanisms like SOAP and XML – allows IP networks to “publish” their service capabilities into a structured operational framework TH NP&C TH NP&C “ Hey, I can offer services X, Y, and Z!” “ Just Z for me!” “ Well, I can offer Y and Z, but no X!”
    • 18. The creation of a true “business layer” TH NP&C The Service Structuring Stratum provides this framework – allowing service capabilities to be joined together in unprecedented ways TH NP&C TH NP&C “ Hey, I can offer services X, Y, and Z!” “ Just Z for me!” “ Well, I can offer Y and Z, but no X!” SSS
    • 19. Notion of Federations CNI 4. Provide network environment for the exchange – akin to ‘projector, whiteboard, audio… SS NP&C TH CNI ICI ICI CNI SS NP&C TH SS NP&C TH Tele-presence application 1. All clients start behind a “Trust Barrier”: akin to being ‘in the lobby’ 2. To get inside clients present credentials, and receive authorizing “token”: akin to a ‘badge’ 3. “Federate” other clients participating in the activity: akin to populating the ‘meeting room’ CNI (Client to Network Interface) (Inter-Carrier Interface)
    • 20. Service Decomposition Model Application Access / Projection Transport / Connection Access / Projection A typical application or retail service is made up of a series of “Elements” from one or more of the classes shown above. Endpoint Elements represent either service users/access points or content/processing capabilities (storage, grid, ASP, etc.). Access/Projection is the Element that represents the “last mile” connection to the user; it could be DSL, cable, wireless, etc. Transport/Connection represents the core network. Each Element used to create a service is contributed by a provider by publishing it via the Service Structuring Stratum. The process of service creation in the IPsphere model is the process of assembling published Elements into services/applications. An Element is also a software link between the IPsphere’s business-layer functions and the control behavior of the network. Consuming Resource Producing Resource IT oriented services NW oriented services Content / Processing Endpoint Endpoint
    • 21. Elements, Components, Messages Endpoint Endpoint Access/ Projection Access/ Projection Transport/ Connection Transport/ Connection Service Transport/ Connection Access/ Projection Endpoint A service is made up of a series of “Elements”, “Transport Connection”, “Access/Projection”, and “Endpoint”. For each element, there are a series of “Components” representing the phases of service setup. These are “Setup” for initial business negotiation, “Execute” for actual service creation on the network, and “Assure” for the ongoing operational phase of the service. Each Component phase consists of four message steps; “Start” which initiates the Component, “Negotiate” which exchanges parameter values until a set is agreed upon, “Complete”, which signals the end of a Component activity, and “Alert” which is an out-of-sequence indicator of a problem that has arisen.
    • 22. How SSS Messages Influence the Network ICI ICI ICI CNI CNI Web Services Framework (UDDI) N M S N M S N M S N M S IPsphere Service Structuring Stratum <ul><li>There are several models for service creation based on how partner providers connect: </li></ul><ul><ul><li>- Facility Connect: Permissive (Internet-like) connection </li></ul></ul><ul><ul><li>- Policy Connect: Signalling through the ICI is policy-mediated </li></ul></ul><ul><ul><li>- Service Connect: Provisioned services explicitly linked at the ICI (NMS provisioning) </li></ul></ul>
    • 23. A Quick Summary of Principles <ul><li>The IPsphere divides a service into Elements, which include Access/Projection, Transport/Connection, and Endpoint. A given service may have any number of elements of any of these types as needed, and services are created by combining Elements contributed by providers. </li></ul><ul><li>A provider participating in the IPsphere will contribute at least one Element for at least one service, but will likely contribute many elements for many services. </li></ul><ul><li>The contribution will be made by publishing a set of web services onto the SSS VPN, supporting all of the components associated with each element/service combination the carrier supports. </li></ul><ul><li>The creation of a pan-provider service involves a web-service-based exchange of messages between the administrative owner who coordinates the service on behalf of the customer, and the providers who contribute elements to the service. </li></ul><ul><li>Each Element is a software “method” or module that is published as a web service and which links to underlying network management or policy management capabilities to actually control the service. </li></ul><ul><li>This process takes place at the Service Structuring Stratum level of the IPsphere Reference Architecture. </li></ul>
    • 24. IPsphere SOA Framework SMS Application/Script Translate order to template Identify partner carriers/Elements Setup Start A/P Setup Complete A/P Setup Start T/C Setup Complete T/C Execute Start A/P Execute Complete A/P Setup Start C/P Element Setup Complete C/P Element Execute Start C/P Element Execute Complete C/P Element Assure Start A/P Assure Start T/C Assure Start C/P C/P Element T/C Element A/P Element UDDI Service Structuring Stratum
    • 25. IPsphere Forum Membership <ul><li>Alcatel </li></ul><ul><li>America Online </li></ul><ul><li>Bezeq </li></ul><ul><li>Brasil Telecom </li></ul><ul><li>Brighthaul </li></ul><ul><li>BT </li></ul><ul><li>Cellcom </li></ul><ul><li>China Unicom </li></ul><ul><li>CIMI Corporation </li></ul><ul><li>Cisco Systems </li></ul><ul><li>Colubris Networks </li></ul><ul><li>Datapower </li></ul><ul><li>Ericsson </li></ul><ul><li>fmc.service </li></ul><ul><li>France Telecom </li></ul><ul><li>GeoTrust </li></ul><ul><li>Huawei </li></ul><ul><li>Hewlett Packard </li></ul><ul><li>IBM </li></ul><ul><li>Internet 2 </li></ul><ul><li>Juniper Networks </li></ul><ul><li>Korea Telecom </li></ul><ul><li>Level 3 </li></ul><ul><li>Lucent Technologies </li></ul><ul><li>Masergy </li></ul><ul><li>Nexagent </li></ul><ul><li>NexTone </li></ul><ul><li>Oracle </li></ul><ul><li>Packeteer </li></ul><ul><li>Polycom </li></ul><ul><li>Qwest </li></ul><ul><li>Red Zinc </li></ul><ul><li>Siemens </li></ul><ul><li>T-Com </li></ul><ul><li>Time Warner Telecom </li></ul><ul><li>T-Systems </li></ul><ul><li>Telenor </li></ul><ul><li>Tellabs </li></ul><ul><li>Telstra </li></ul><ul><li>Ulticom </li></ul>
    • 26. IPsphere Forum Leadership Positions <ul><li>Omar Elloumi, Alcatel , Secretary </li></ul><ul><li>Keith Dickerson, BT , Board Member </li></ul><ul><li>Monique Morrow, Cisco , Vice Chair </li></ul><ul><li>Christian Jacquenet, FT , Board Member </li></ul><ul><li>Yi Zhao, Huawei , Board Member </li></ul><ul><li>Kevin Dillon, Juniper , Chairman </li></ul><ul><li>Tom Walsh, Lucent , Treasurer </li></ul><ul><li>Donal Morris, Red Zinc , Board Member </li></ul><ul><li>Andreas Mueller-Schubert, Siemens , Board Member </li></ul><ul><li>Roger Wenner, T-Com , Board Member </li></ul><ul><li>Sten Nordell, Telenor , Board Member </li></ul><ul><li>Andy Malis, Tellabs , Board Member </li></ul><ul><li>Douglas O’Leary, Verizon , Board Member </li></ul>
    • 27. Working Group Structure Business Dimensions WG Reference Architecture WG Reference Implementation WG E WG F WG G WG IPsphere Forum Board Work Program leader Publications Team Marketing Committee Chair: Kevin Dillon (JNPR) v. chair: Donal Morris (Red Zinc) Chair: Ian Stanley (Telstra) v. chair: David Weinberg (JNPR) Chair: Mathew Ford (BT) v. chair: Phil Jacob (Cisco) Chair: Arianna Nikitas (Tellabs) v. chair: Todd Shimizu (JNPR)
    • 28. Conclusion <ul><li>Deploying a Schedulable Deterministic End-to-End Pipes service requires: </li></ul><ul><ul><li>Both a vertical and horizontal approach </li></ul></ul><ul><ul><li>A synergy between NREN and GRIDs communities, but also with industries </li></ul></ul><ul><li>The problem can be addressed from different angles: but practical development and standardization work should be conducted together </li></ul><ul><li>The winning solution will be federative, vendor and domain independent, simple to adapt to any current or future infrastructures and technologies </li></ul><ul><li>The top model will be SDE2EP independent </li></ul><ul><ul><li>A common framework for all “on-demand” network services </li></ul></ul>
    • 29. The solution is in its path To do: Find x <ul><li>All you need to know: </li></ul><ul><li>Sum of angles in a triangle is 180° </li></ul><ul><li>The two base angles of an isosceles triangle are equal </li></ul><ul><li>Two additional lines will be sufficient to find x </li></ul>
    • 30. References <ul><li>GEANT2 Deliverables </li></ul><ul><ul><li>DJ.3.2.1: GÉANT2 Bandwidth on Demand (BoD) User and Application Survey </li></ul></ul><ul><ul><li>DJ3.2.2: Initial Review of Technologies Related to the Provision of Bandwidth-on-Demand (BoD) Services </li></ul></ul><ul><li>IPSPhere Forum: http://www.ipsphere.org/ </li></ul><ul><ul><li>Overview: http://www.ipsphereforum.org/newsevents/07nollereprint.pdf </li></ul></ul>
    • 31. Thank you

    ×