NORDUnet Nordic I nfrastructure for Research & Education Open Issues for Dynamic Hybrid Network Services Jerry Sobieski Director, International Research Initiatives NORDUnet Presented to TERENA End-to-End Workshop December 1 & 2, 2009 Amsterdam, NL
NORDUnet Motivation and Caveats Nordic I nfrastructure for Research & Education Hybrid networks for Research and Education have • become an important new means for advanced applications to acquire the types of predictable and deterministic performance they desire. Dynamic hybrid network services will introduce • both dramatic new flexibility for distributed application teams as well as simplified operations for the R&E networks themselves. The observations expressed here are not critiques - • just observations of issues that I believe are important to get right at the outset in order to insure adoption and growth
NORDUnet What are we talking about? Nordic I nfrastructure for Research & Education • Dynamic “circuit” provisioning • Currently Layer2 Ethernet services • Layer “2.5” IP/MPLS in some networks • Global reach • What is required to accomplish this? • A documented architecture that describes how it all will work five years out: • When we have 1000+ networks offering dynamic circuit provisioning (some well managed, some not…) • When we have 10,000+ users globally • When we have 100,000 network elements participating at different transport layers • When we are suporting application specific networks for 1000s of different projects • When we need to interoperate with non-academic networks • When we need to manage multiple transport protocols
NORDUnet What do we need? Nordic I nfrastructure for Research & Education • Keep in mind what the user must do to utilize these services: • Simple processes to install necessary end system software • Simple and clear interfaces for using the services • Clear articulated architecture for building out the reach • Into the regional networks • Into campus environments • Into labs and end systems • Smaller networks need this type of documentation to guide them over the next few years as they go thru infrastructure upgrades
NORDUnet A few areas to work on: Nordic I nfrastructure for Research & Education • Simplified [user] installation requirements • Simplified software complexities • Clearly defined services • For performance verification and debugging • Scalable services • Control plane protocols • Authorization mechanisms • Federated and generalize cyber-resource management structure • Including user tools for managing resources and application specific distributed environments
NORDUnet KI SS Nordic I nfrastructure for Research & Education • Simplicity will be the single most important characteristic that will promote adoption within the end-user and near-end user environments • The control plane software must be • Brain dead easy for users to install !!! • Includes UNI software, routing (INNI)software (if necessary), authorization rights, etc. • Provide a clear and simple programmatic API • Automated control/data plane configuration • “DHCP” for hybrid end-systems - easy user configuration of TE addresses and layer specific TNA registration (LMP-like functions) • Simplicity aids the network operator as well • Means that the hybrid networking control software (broadly construed) does not impose large scale dependencies within existing software/hardware • The protocols are standards compliant (I.e. supported by vendors) and interoperate reliably (validated and tested.)
NORDUnet Reduced Software Complexity Nordic I nfrastructure for Research & Education • Minimize control plane software dependencies: • Specific versions of scripting languages, interpretive languages/tools, bloated libraries meant for specialized server environments or rapid development. • These dependencies create complexity and excessive cost to adoption • Minimize built-up Layering: • Layer software only where it makes sense * functionally* - not simply because some other software lies between your function and lower layers. • The latter may be useful in a proof of concept, but does not work well wide scale adoption • Ex: Developing provisioning interfaces for vendor specific NMSs rather than implementing a standard protocol native to the device • Ex: Web Services require XML, SOAP, Tomcat, PHP, X509, … could we offer a user programatic interface that does not require such overhead (Certainly YES!) • How easy is it for Joe User to write a “hello world” application?
NORDUnet Common Service Definitions Nordic I nfrastructure for Research & Education Minor differences in service provisioning among/between networks can • create unexpected incompatibilities or sub-par performance The “ Service Definition ” specifies the service characteristics offered by • the provider… and experienced by the end user. It does not specify how the service is engineered or provisioned, it simply • specifies what is delivered to the end user. How the service provider(s) decides to construct the service infrastructure is not part of the Service Definition. A well defined service should be predictable : • The user knows in advance what to expect from the service in terms of • performance or other characteristics A well defined service is verifiable : • It can be measured at the service delivery point(s) and found to conform to • the predicted (or committed) service characteristics A well defined service is repeatable : • It behaves exactly same way every time it is invoked - but only with respect to • the defined characteristics A well defined [circuit] service is end to end : • It should not matter which provider(s) or which networks are involved in • delivering the service for the end users – they will all result in conforming capabilities as experienced by the end user.
NORDUnet Common Service Definitions Nordic I nfrastructure for Research & Education Service Definitions are arbitrary. • A Service Definition is a specific set of service parameters and allowed • values/defaults for those parameters, that form the complete set of measurable service characteristics. E.g. MTU < = 9000 Bytes; or • SpanningTreeProtocol := notTransported; • Any service characteristic that is not explicitly defined in the service • definition is thereby explicitly undefined i.e. the user can neither expect it to be present nor expect it to be absent. • Service Definitions are flexible • They can be modified, augmented, enhanced, refined, etc from time to • time as the community sees fit. In the near term, the GLIF should adopt several basic broad and inclusive • definitions that allow the process of define-deploy-review-refine to begin. There may be multiple Service Definitions: “basic • Ethernet”, “hicap Ethernet”, “TDM”, “Infiniband”, “Packet”) Differentiating services is somewhat arbitrary, but should reflect • fundamentally different network service capabilities. It is conceivable that some services may be subsets of others, or offer a • base set of characteristics inherited by an entire family of service dialects.
NORDUnet Common Service Definitions Nordic I nfrastructure for Research & Education • A Common Service Definition should have a formalized specification document…could be a BNF style spec or XML spec • An example: Service_Name := := Ethernet_LightPath Ethernet_LightPath; ; � Service_Name � := 2006.01.10_1.1beta; := 2006.01.10_1.1beta; Version � Version � := The := The “ “Ethernet_LightPath Ethernet_LightPath” ” service is a service is a Description � Description � point to point service that is to be used by large capacity point to point service that is to be used by large capacity users with certain performance criteria. ; users with certain performance criteria. ; IEEE_802.3; // plain ol ol’ ’ ethernet ethernet Framing := IEEE_802.3; // plain � Framing := � Frame Size <= 9252 Bytes ; 9252 Bytes ; � � Frame Size <= := 1 Mbs to 10 Gbs Gbs by 1 Mbs; by 1 Mbs; := 1 Mbs to 10 Data Rate � � Data Rate = { 1GE | 1GE_tag | 10GE | 10GE_tag }; Access mode : = { 1GE | 1GE_tag | 10GE | 10GE_tag }; � Access mode : � Pacing Window := .1 second; // used to constrain .1 second; // used to constrain buf req buf req � Pacing Window := � Frame Loss Rate <= 1E <= 1E- -8; // BER=1E 8; // BER=1E- -12 and 9000B 12 and 9000B datagrams datagrams � Frame Loss Rate � VLAN_transport = False ; = False ; // no VLAN stacks supported // no VLAN stacks supported � VLAN_transport � SpanningTree = False ; // no STP on the = False ; // no STP on the vlan/port vlan/port � SpanningTree � • This could as easily be implemented asan XML document…
Recommend
More recommend
