A hierarchical, NSI compatible, topology proposal for NML

Slides:



Advertisements
Similar presentations
Intra-Carrier Solutions Enabled by the OIF NNI Erning Ye Nortel Networks.
Advertisements

G : DCM Signaling Mechanism Using GMPLS RSVP-TE ITU-T Workshop on IP-Optical, Chitose, Japan 7/11/2002 Dimitrios Pendarakis, Tellium, Inc. ITU-T.
Mapping Service Templates to Concrete Network Semantics Some Ideas.
Lawrence Berkeley National LaboratoryU.S. Department of Energy | Office of Science Network Service Interface (NSI) Inder Monga Co-chair, Network Services.
NORDUnet Nordic infrastructure for Research & Education NSI in the SDN Environment (from perspective of an NSI fellow) Jerry Sobieski NORDUnet Presented.
© 2006 Open Grid Forum Network Service Interface in a Nut Shell GEC 19, Atlanta, GA Presenter: Chin Guok (ESnet) Contributors: Tomohiro Kudoh (AIST), John.
NORDUnet Nordic infrastructure for Research & Education LHCONE “Point-to-Point Connection Service” Service Definition Jerry Sobieski.
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 04. Other.
Chapter 18. IP: Internet Protocol Addresses
Resource Pooling A system exhibits complete resource pooling if it behaves as if there was a single pooled resource. The Internet has many mechanisms for.
PROTOCOLS AND ARCHITECTURE Lesson 2 NETS2150/2850.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED SYSTEMS.
1 Version 3 Module 8 Ethernet Switching. 2 Version 3 Ethernet Switching Ethernet is a shared media –One node can transmit data at a time More nodes increases.
Internet Telephony Helen J. Wang Network Reading Group, Jan 27, 99 Acknowledgement: Jimmy, Bhaskar.
Chapter 19 Binding Protocol Addresses (ARP) Chapter 20 IP Datagrams and Datagram Forwarding.
COE 342: Data & Computer Communications (T042) Dr. Marwan Abu-Amara Chapter 2: Protocols and Architecture.
Network Layer IS250 Spring 2010
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
FIREWALL TECHNOLOGIES Tahani al jehani. Firewall benefits  A firewall functions as a choke point – all traffic in and out must pass through this single.
Additional SugarCRM details for complete, functional, and portable deployment.
Lab 5: NAT CS144 Review Session 7 November 13 th, 2009 Roger Liao.
Introduction to Network Layer. Network Layer: Motivation Can we built a global network such as Internet by extending LAN segments using bridges? –No!
Protocols and the TCP/IP Suite
Virtual Circuit Network. Network Layer 2 Network layer r transport segment from sending to receiving host r network layer protocols in every host, router.
Learningcomputer.com SQL Server 2008 Configuration Manager.
Distributed Computing COEN 317 DC2: Naming, part 1.
LAN Switching and Wireless – Chapter 1 Vilina Hutter, Instructor
Internet Protocol ECS 152B Ref: slides by J. Kurose and K. Ross.
Lecture # 3 & 4 Chapter # 2 Database System Concepts and Architecture Muhammad Emran Database Systems 1.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED SYSTEMS.
NSI Topology Wishes OGF Lyon Sep 2011 Jerry Sobieski.
Ch- 8. Class Diagrams Class diagrams are the most common diagram found in modeling object- oriented systems. Class diagrams are important not only for.
The Client-Server Model And the Socket API. Client-Server (1) The datagram service does not require cooperation between the peer applications but such.
1 draft-lefaucheur-emergency-rsvp-00.txt RSVP Extensions for Emergency Services Francois Le Faucheur - Francois Le.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED SYSTEMS.
Basics of the Domain Name System (DNS) By : AMMY- DRISS Mohamed Amine KADDARI Zakaria MAHMOUDI Soufiane Oujda Med I University National College of Applied.
NSI Service Definition Federation of providers A group of network providers get together and decide that they wish to offer a multi-domain connection services.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED SYSTEMS.
Network No network resources exist outside a network Transport resources inside network –Link, Nodes, ports – are used to create connections between network.
© 2006 Open Grid Forum Network Services Interface Policy-based routing enforcement John MacAuley, ESnet 4 th February 2015.
© 2006 Open Grid Forum NML Agenda OGF 34, Oxford.
Topology Issues in Inter-Domain Connection Services Jerry Sobieski (NORDUnet) The Cynic’s Perspective & Jeroen van der Ham (University of Amsterdam) The.
© 2006 Open Grid Forum A hierarchical, NSI compatible, topology proposal for NML Jerry Sobieski NORDUnet Presented at OGF 34.
NSI Topology v2.0 Version 1.2 John MacAuley, ESNET September 22, 2014 Uppsala.
ITU Liaison on T-MPLS Stewart Bryant
Network Layer COMPUTER NETWORKS Networking Standards (Network LAYER)
What is a Protocol A set of definitions and rules defining the method by which data is transferred between two or more entities or systems. The key elements.
Network Hardware for Expanding Network
Lab A: Planning an Installation
Dynamic Circuit Networks Topology Description Issues
Whirlwind Tour Of Lectures So Far
Thierry Ernst (INRIA and WIDE) Hesham Soliman (Ericsson)
Objective: ARP.
Efficient Policy-Based Routing without Virtual Circuits
Network Services Interface
A Deterministic End to End Performance Verification Architecture
A hierarchical, NSI compatible, topology proposal for NML
draft-ietf-teas-yang-te-topo-01
NSI Topology Thoughts on how topology fits into the NSI architecture
NSI Service Definition
Integration of Network Services Interface version 2 with the JUNOS Space SDK
Availability Query / Internal Topology
CHAPTER 3 Architectures for Distributed Systems
Single-Area OSPF (Open Shortest Path First Protocol)
Net 323 D: Networks Protocols
Network Services Interface
CHAPTER 8 Network Management
An Update on Multihoming in IPv6 Report on IETF Activity
High Interest Subject: NGN – End-to-End QoS
Network Architecture By Dr. Shadi Masadeh 1.
Presentation transcript:

A hierarchical, NSI compatible, topology proposal for NML Jerry Sobieski NORDUnet Presented at OGF 34

Hierarchical topology… The existing NSI topology model does not provide a consistent mechanism for exposing intra-domain topological structure. The base model hides all internal structure…which is good in many (most) high level cases…. But… Where a network wishes to do so, it should be able to expose additional internal structure or state in a measured and graduated degree…down to the hardware minutia if so desired.

NML recommendations This proposal retains the NSI abstractions at the highest topological layer, and retains the NSI model internally as smaller NSI domains are defined A key relation called an “alias” is defined to link STPs (NML Ports) at any desired level to STPs at the next lower (more detailed) level. An Alias is an internal topological construct that should probably be stored at the lower level (more detailed level). It therefore stays private until/unless that level is announced externally. (local agents will not have a problem using this relation.) An Alias could [alternatively] reference a conventional NML topological object – thus mapping the NSI topology to appropriate NML object as the local topology manager deems appropriate.

NSI Topology Example Current existing NSI topology model: only L0 has structure, L1+ is opaque (private) PSNC Topo level 1 NDN.EFDX Opaque internal Topo level 1 NDN Pionier Universal space Topo level 0 STPs (NML Ports) Internet2 Internet2 Topo level 1 NetherLight-o NDN SDPs (NML Links) NetherLight Topo level 1 NDN ION-o

Proposed Hierarchical NSI Topology Example Proposed NorthernLight topology: L0 & internal L1 objects are publically announced by NorthernLight; As a Worldview, this topo would say I2, PSNC, and NL only announced L0 information. As a Local Topology from NDN, this is the only L0 information that NorthernLight can provide (i.e. its direct adjacencies) PSNC Topo level 1 NDN.EFDX Topo level 1 NDN Pionier Universal space Topo level 0 NYC Level 2 CPH CPH Level 2 POZ ION Blue links are “aliases” indicating an level transition in the topology. (Aliases act similarly to SDPs, so red and blue relations are simple logical links.) NYC AMS Internet2 Internet2 Topo level 1 NDN NetherLight NetherLight Topo level 1 NDN

Hierarchical Topology Proposal Bi-directional Example topo{ name $L0$; /* level 0 is the universal space */ topo{ name NDN.EFDX; version 2012-02-29-18:42:23 /* level 1 topology */ NSA https://orval.grid.aau.dk:9443/NSI/services/ConnectionService port Pionier, NetherLight, Internet2 bidirectional; topo{ name CPH; location lat 24.1234 lon -57.2345; /* level 2 topology */ port AMS, POZ, NYC bidirectional; } topo{ name NYC; location lat 24.1234 lon -87.2345; /* level 2 topology */ port ION, CPH bidirectional; link NYC:CPH, CPH:NYC; /* level 2 to level 2 */ alias NDN.EFDX:Pionier, CPH:POZ; /* level 1 to level 2 boundary links */ alias NDN.EFDX:NetherLight, CPH:AMS; /* level 1 to level 2 boundary links */ alias NDN.EFDX:Internet2, NYC:ION; /* level 1 to level 2 boundary links */ Link NDN.EFDX:Pionier, Pionier.EFDX:NDN; /* NDN level 1 port to Pionier level 1 port */ Link NDN.EFDX:NetherLight, NetherLight.EFDX:NDN; /* level 1 port to level 1 port */ Link NDN.EFDX:Internet2, Internet2.EFDX:NDN; /* level 1 port to level 1 port */

Modular description network $L0${ /* level 0 is the top level universal space */ has_networks NDN.EDFX, Pionier.EFDX, NetherLight.EFDX, Internet2.EFDX; link CPH:POZ, Pionier.EFDX:NDN; /* SDP */ link CPH:AMS, NetherLight.EFDX:NDN; /* SDP */ link NYC.ION:Internet2, Internet2.EFDX:NDN; /* SDP */ } network NDN.EDFX { ; version 2012-02-29-18:42:23 /* level 1 network */ NSA https://orval.grid.aau.dk:9443/NSI/services/ConnectionService; has_networks CPH, NYC; port CPH:POZ, CPH:AMS, NYC:ION bidirectional; /* STPs */ link NYC:CPH, CPH:NYC; /* SDP */ network Pionier.EFDX { NSA https://..... port Pionier.EFDX:NDN; network NetherLight.EFDX {...} network Internet2.EFDX {...} network CPH { ; location lat 24.1234 lon -57.2345; /* level 2 network */ port AMS, POZ, NYC bidirectional; /* STPs */ network NYC { ; location lat 24.1234 lon -87.2345; /* level 2 network */ port ION, CPH bidirectional; /* STPs */

Modular description / network view network $L0${ /* level 0 is the top level universal space */ has_networks NDN.EDFX, Pionier.EFDX, NetherLight.EFDX, Internet2.EFDX; } network NDN.EDFX { ; version 2012-02-29-18:42:23 /* level 1 network */ NSA https://orval.grid.aau.dk:9443/NSI/services/ConnectionService; has_networks CPH, NYC; port CPH:POZ, CPH:AMS, NYC:ION bidirectional; /* STPs */ link CPH:POZ, Pionier.EFDX:NDN; /* SDP */ link CPH:AMS, NetherLight.EFDX:NDN; /* SDP */ link NYC.ION:Internet2, Internet2.EFDX:NDN; /* SDP */ network Pionier.EFDX { NSA https://..... port Pionier.EFDX:NDN; link Pionier.EFDX:NDN, CPH:POZ; /* SDP */ network NetherLight.EFDX {...} network Internet2.EFDX {...} network CPH { ; location lat 24.1234 lon -57.2345; /* level 2 network */ port AMS, POZ, NYC bidirectional; /* STPs */ link CPH:NYC, NYC:CPH; /* SDP */ network NYC { ; location lat 24.1234 lon -87.2345; /* level 2 network */ port ION, CPH bidirectional; /* STPs */ link NYC:CPH, CPH:NYC; /* SDP */

Modular description / with alias network $L0${ /* level 0 is the top level universal space */ has_networks NDN.EDFX, Pionier.EFDX, NetherLight.EFDX, Internet2.EFDX; } network NDN.EDFX { ; version 2012-02-29-18:42:23 /* level 1 network */ NSA https://orval.grid.aau.dk:9443/NSI/services/ConnectionService; has_networks CPH, NYC; port CPH:POZ alias NDN.EDFX:Pionier , CPH:AMS alias NDN.EDFX:NetherLight, NYC:ION alias NDN.EDFX:Internet2 bidirectional; /* STPs */ link NDN.EFDX:Pionier, Pionier.EFDX:NDN; /* SDP */ link NDN.EFDX:NetherLight, NetherLight.EFDX:NDN; /* SDP */ link NDN.EFDX:Internet2, Internet2.EFDX:NDN; /* SDP */ network Pionier.EFDX { NSA https://..... port Pionier.EFDX:NDN; link Pionier.EFDX:NDN, NDN.EFDX:Pionier; /* SDP */ network NetherLight.EFDX {...} network Internet2.EFDX {...} network CPH { ; location lat 24.1234 lon -57.2345; /* level 2 network */ port AMS, POZ, NYC bidirectional; /* STPs */ link CPH:NYC, NYC:CPH; /* SDP */ network NYC { ; location lat 24.1234 lon -87.2345; /* level 2 network */ port ION, CPH bidirectional; /* STPs */ link NYC:CPH, CPH:NYC; /* SDP */

Uni-directional Circuits Bi-directional and symmetric notions of “connections” are based in historical design of analog voice circuits where the same signal capacity was required in both directions This is clearly no longer the case with digital data telecommunications and networking. Asymmetric flows (different BW requirements forward and reverse) have largely been ignored in conventional IP network engineering due to statistical multiplexing and assumption of balanced client-server distributions MPLS TE development has addressed issues of asymmetric loads As applications begin to leverage NSI for performance guarantees, symmetric bi-directional connections will prove to be very inefficient use of transit resources and potentially limiting for Uni-directional “connections” provide a more atomic service element for Connection Services such as NSI.

NSI Topology Example Current existing NSI topology model: only L0 has structure, L1+ is opaque Universal space Topo level 0 PSNC Topo level 1 NDN.EFDX Opaque internal Topo level 1 NDNi Pionier-o NDNo Pionier-i STPs (NML Ports) Internet2-i Internet2-o Internet2 Topo level 1 NDNo NetherLight-o NetherLight-i NDNi SDPs (NML Links) NetherLight Topo level 1 NDNi NDNo ION-o

Proposed Hierarchical NSI Topology Example Proposed NorthernLight topology: L0 & internal L1 objects are publically announced by NorthernLight; As a Worldview, this topo would say I2, PSNC, and NL only announced L0 information. As a Local Topology from NDN, this is the only L0 information that NorthernLight can provide (i.e. its direct adjacencies) PSNC Topo level 1 NDN.EFDX Topo level 1 NDNi Pionier-o Universal space Topo level 0 NYC Level 2 NDNo CPHo Pionier-i IONi NYCi CPH Level 2 POZo CPHi IONo POZi Blue links are “aliases” indicating an external level transition in the topology NYCo Internet2-i AMSo AMSi Internet2-o Internet2 Topo level 1 NDNo NetherLight-o NetherLight-i NDNi NetherLight Topo level 1 NDNi NDNo

Hierarchical Uni-directional Topology Proposal Example topo{ name $L0$; /* level 0 is the universal space */ topo{ name NDN.EFDX; version 2012-02-29-18:42:23 /* level 1 topology */ NSA https://orval.grid.aau.dk:9443/NSI/services/ConnectionService port Pionier-i, NetherLight-i, Internet2-i inbound; port Pionier-o, NetherLight-o, Internet2-o outbound; topo{ name CPH; location lat 24.1234 lon -57.2345; /* level 2 topology */ port AMSi, POZi, NYCi inbound; port AMSo, POZo, NYCo outbount; } topo{ name NYC; location lat 24.1234 lon -87.2345; /* level 2 topology */ port IONi, CPHi inbound; port IONo, CPHo outbount; link NYC:CPHi, CPH:NYCo; /* level 2 to level 2 */ link NYC:CPHo, CPH:NYCi; /* level 2 to level 2 */ alias NDN.EFDX:Pionier-i, CPH:POZi; /* level 1 to level 2 boundary links */ alias NDN.EFDX:Pionier-o, CPH:POZo; /* level 1 to level 2 boundary links */ alias NDN.EFDX:NetherLight-i, CPH:AMSi; /* level 1 to level 2 boundary links */ alias NDN.EFDX:NetherLight-o, CPH:AMSo; /* level 1 to level 2 boundary links */ alias NDN.EFDX:Internet2-i, NYC:IONi; /* level 1 to level 2 boundary links */ alias NDN.EFDX:Internet2-o, NYC:IONo; /* level 1 to level 2 boundary links */ Link NDN.EFDX:Pionier-i, Pionier.EFDX:NDNo; /* NDN level 1 port to Pionier level 1 port * Link NDN.EFDX:Pionier-o, Pionier.EFDX:NDNi; Link NDN.EFDX:NetherLight-i, NetherLight.EFDX:NDNo; /* level 1 port to level 1 port */ Link NDN.EFDX:NetherLight-o, NetherLight.EFDX:NDNi; Link NDN.EFDX:Internet2-i, Internet2.EFDX:NDNo; /* level 1 port to level 1 port */ Link NDN.EFDX:Internet2-o, Internet2.EFDX:NDNi;

Notes on NSI Uni-directional Uni directional circuits do not conflict with existing bi-directional service Protocol remains the same. Some topology will need amending to reflect uni-directional STPs Reservation Req already has the directionality parameter – so this will make it useful This will also cause the WG to think about “compositional” services E.g. How do you define a bi-directional connection pair that is either asymmetric or diverse How do we reference other Connections to specify things like parallel but reversed, diverse, etc

Other Topological considerations NML: Syntactic and name formalizations can be defined as make sense…just need to maintain NSI conceptual functionality. This is looking very good (Thanks to NML Freek, JdvH, Roman, Jason) We need to resolve some specification issues regarding topologies (e.g. do we nest them, or list them..) - not religious issues NML: How do we map seemlessly from the abstract NSI constructs to the existing NML information? Again, I think this is syntactic mechanics…not a moral or theological issue

Mapping NSI STPs to local detail topo{ name $L0$; /* level 0 is the universal space */ topo{ name NDN.EFDX; version 2012-02-29-18:42:23 /* level 1 topology */ NSA https://orval.grid.aau.dk:9443/NSI/services/ConnectionService port Pionier, NetherLight, Internet2 bidirectional; topo{ name CPH; location lat 24.1234 lon -57.2345; /* level 2 topology */ port{ name=AMS; mode=bidirectional } port{ name=POZ; mode=bidirectional } port{ name=NYC; mode=bidirectional } } topo{ name NYC; location lat 24.1234 lon -87.2345; /* level 2 topology */ port{ name=ION; mode=bidirectional } port{ name=CPH; mode=bidirectional } link NYC:CPH, CPH:NYC; /* level 2 to level 2 */ alias NDN.EFDX:Pionier, CPH:POZ; /* level 1 to level 2 boundary links */ alias NDN.EFDX:NetherLight, CPH:AMS; /* level 1 to level 2 boundary links */ alias NDN.EFDX:Internet2, NYC:ION; /* level 1 to level 2 boundary links */ Link NDN.EFDX:Pionier, Pionier.EFDX:NDN; /* NDN level 1 port to Pionier level 1 port */ Link NDN.EFDX:NetherLight, NetherLight.EFDX:NDN; /* level 1 port to level 1 port */ Link NDN.EFDX:Internet2, Internet2.EFDX:NDN; /* level 1 port to level 1 port */

Other Topological considerations NSI: How does an NSA learn global topology… NSI: How does an NSA announces or distribute their [public] topology… NSI Decision point: Can we agree in principle to implement an “alias” [sdp] functionality in V2.0 ? Can we agree in principle to implement uni-directional Connections in V2.0 ? (details TBD)

Merging topologies Merging topologies- Intelligent semantic analysis of topology descriptions is necessary when merging two topologies: E.g. “link aruba:a1, bonaire:b1” is equivalent to “link bonaire:b1, aruba:a1” E.g. “port a1, a2, a3 inbound;” is equivalent to “port a1 inbound; port a3, a2 inbound;” E.g. “topo{ link a,b; topo{…}; }” is equivalent to “topo{ topo{…}; link a, b;}”

Topology issues addressed BTR Type Value pairs The issue was how to express “other information” associated with STPs Proposed: field separators are tbd <STP> := <network> “:” <locid> [“,” <TVP> ]* <TVP> := <type> “=“ <string> Example: esnet.ets:ps80,vlan=1780 STPs are *still* identifiers – how the TVP types and associated values are used is a service specific Thus, a Reservation Req could submit: Source= “nl:cph1,port=ge0/1/4,vlan=4000” Dest= “ndn:cph2-xe3/2/1.2001”

Mapping NSI STPs to local detail NSI Network{ name NDN.EFDX; version 2012-02-29-18:42:23 NSA https://orval.grid.aau.dk:9443/NSI/services/ConnectionService STP{ name=“NDN.EFDX:Pionier,vlan=4000” bidirectional } STP{ name=“NDN.EFDX:NetherLight,vlan=4001” bidirectional } STP{ name=“NDN.EFDX:Internet2,vlan=4002” bidirectional } SDP “NDN.EFDX:Pionier,vlan=4000”, Pionier:CPH1; SDP “NDN.EFDX:NetherLight,vlan=4001”, Netherlight.EFDX:CPH4001; SDP “NDN.EFDX:Internet2,vlan=4002”, ION.EFDX:NDN-NYC; }

Mapping NSI STPs to local detail topo{ name $L0$; /* level 0 is the universal space */ topo{ name NDN.EFDX; version 2012-02-29-18:42:23 /* level 1 topology */ NSA https://orval.grid.aau.dk:9443/NSI/services/ConnectionService port Pionier, NetherLight, Internet2 bidirectional; topo{ name CPH; location lat 24.1234 lon -57.2345; /* level 2 topology */ port{ name=AMS, mode=bidirectional, mapsTo=“router=cph-nsi.nordu.net, port=ge0/0/10, unit=1780”; port{ name=POZ, mode=bidirectional, mapsTo=“router=cph-nsi.nordu.net, port=ge0/2/0, unit=1780”; port{ name=NYC, mode=bidirectional, mapsTo=“cph2-nsi.nordu.net eth0.1780”; } topo{ name NYC; location lat 24.1234 lon -87.2345; /* level 2 topology */ port{ name=ION, mode=bidirectional, mapsTo=“router=nyc-nsi.nordu.net, port=ge2/19, unit=1780”; port{ name=CPH, mode=bidirectional, mapsTo=“router=nyc-nsi.nordu.net, port=ge2/12, unit=1780”; link NYC:CPH, CPH:NYC; /* level 2 to level 2 */ alias NDN.EFDX:Pionier, CPH:POZ; /* level 1 to level 2 boundary links */ alias NDN.EFDX:NetherLight, CPH:AMS; /* level 1 to level 2 boundary links */ alias NDN.EFDX:Internet2, NYC:ION; /* level 1 to level 2 boundary links */ Link NDN.EFDX:Pionier, Pionier.EFDX:NDN; /* NDN level 1 port to Pionier level 1 port */ Link NDN.EFDX:NetherLight, NetherLight.EFDX:NDN; /* level 1 port to level 1 port */ Link NDN.EFDX:Internet2, Internet2.EFDX:NDN; /* level 1 port to level 1 port */

Other Related STP/SDP issues TBD Enumeration: How do we define large sets of similar STPs? <network><locid> [ , <TVP>]* <TVP> := <type> “=“ <value> [“..” <value>]* Path Guidance (anypoint guidance) Source/Dest set specification Ex: destination= esnet:ps[0..100,102,104,177] any *one* of these STPs is acceptable Loosen the endpoint constraints Ex: destination= esnet:* (any available STP in esnet) esnet:*! (first available STP inside esnet) esnet:~ (transit esnet ) Some of these require an “ero” style capability These are critical to solving exhaustive search issues