[Nsi-wg] Topology Abstract sent to Terena

[Jeroen van der Ham]

Hello,

Jerry and I quickly slapped together the following abstract for Terena on Topology handling in NSI. I've attached it below.

Jeroen.

At two recent events, the GLIF meeting in Rio de Janeiro and SuperComputing11 in Seattle, many parties collaborated to create the first interoperable automated inter-domain circuit provisioning demonstration. The demonstration showed that seven different implementations could successfully communicate to exchange path reservations, queries and requests.
 
In the demonstrations at GLIF and SC11 we have used a static centrally managed global topology description for a very small and very simple network. This description was expressed using a simple OWL[OWL] ontology. This ontology allowed domains to describe themselves, and express their edgeports, (the service destinations inside each network). The domain description also contained a description of the Network Service Agent responsible for that network domain, including its address, and perhaps most importantly – the adjacencies that existed between the networks.   This information was minimally sufficient, but we learned – even from this very small pilot project – that a more powerful and automated topology model is critically important.

Over ten different networks provided resources for this Automated GOLE testbed. The topology for this testbed was provided before the demonstration and remained static throughout.
 
Several issues have been identified in this demonstration concerning topology handling:
·      Topology distribution
·      Path Selection and Allocation
·      Security and Trust
 
 
Topology Distribution

The central, static topology description for the fulfilled the needs of the demonstration, however in a practical application the topology will need to be distributed in a different manner. Domains must be able to define and advertise their own topology, which may be somewhat different than their actual physical infrastructure.  The difference between the actual physical infrastructure inside a network, and the publicly advertised topology is important for scaling and summarizing purposes, and often perceived to be a security or privacy issue. The global scope and complexity dictates a distributed approach to topology discovery and exchange – which introduces concerns about coherency and convergence of topology information.   Further, the form in which the topology information is passed around  - the ontology and representation – is critical for common exchange and shared interpretation of the information contained in the topology.  
 
These issues are complex, but they are not intractable. The NSI WG is exploring these aspects and how the inter-relate to NSI Framework and protocol(s). 
Path Selection and Allocation

 
Conventional switching technologies such as Ethernet or MPLS employ multiplexing of streams over underlying links by creating “labels” to identify packets belonging to particular flows.  These labels could be a timeslot, a VLAN identifier, wavelengths, etc.   When such labels cross network boundaries, NSI considers them to be abstract service stitching points for concatenating connections between adjacent network domains.     
 
Several important features of NSI are 1) its abstraction of “connections” to be technology agnostic pipes, 2) its introduction of “tree” mode path segmentation and reservation which separates of path selection and resource confirmation into remote and local functions respectively.
On the other hand, given the current network technologies, the NSI protocol must be able to provision connections between ports using specific labels (e.g. VLANs, timeslots, wavelengths). We can either model these implicitly by mapping topologies, or explicitly in the topologies:
	• In the implicit case the connection abstraction does not recognize physical hardware features such as VLANs, Wavelengths, VCGs, etc .  -- “labels” in a general sense – just inter-domain adjacencies.   To NSI labels are part of the termination points, “endpoints” for circuits across each domain.   And with tree mode path selection, NSI introduces the notion of remote pathfinding – where inter-domain path selection is done remotely by external agents but the path (resource) reservation is still done locally by each network along the selected path.   This last point creates a serious quandary for the NSI topology description as it introduces a potentially very large search space for available transit points.
	• When modelled explicitly the label is described as part of the endpoint specification. This label can still be specified in a technology agnostic abstraction. The domain topologies will have to describe available labels on their ports. While this decreases the path search space, it does add the label dimension for pathfinding and messaging.


These issues inter-relate in that they pose challenges not just for path finding, but impact the abstraction model and the protocol(s) as well.
 
The NSI WG is must consider these aspects carefully in order to maintain the power of the technology agnostic abstractions and service models, while at the same time finding the appropriate topological representation and semantics that make for an efficient, generalized and scalable path finding process for both chain and tree mode connection handling.
Security and Trust

Creating a globally available network for circuit provisioning also raises security considerations.   This has been a key requirement of NSI from day one and has been designed into the NSI service model and the CS protocol.  Each and every service request is authorized at each network boundary, and communication between each network service agent is authenticated and similarly authorized.   However, while the mechanisms are in place to pass security credentials among cooperating agents, the specifics of those credentials – how they apply to the service requested is more complex.  This is the “security profile”.   The roles of various entities requesting or providing services, the value or class of the information that may be exchanged in a service request or the function performed itself, and the local policies of each network must be considered and some minimal set of security profile agreed to in order for efficient inter-domain authorization to work reliably.
 
These security concerns apply equally to topology exchange.   It should not be possible, for instance, for attackers to disrupt operations by injecting malicious information into the system, while at the same time allowing legitimate agents to provide appropriate  A comprehensive topology architecture will carry a wide array of information besides simple data plane connectivity...it may contain peering relations at the service plane, it may carry policy descriptions, it may contain varying amounts of state information.   So the topology exchange process must be provably secure so that participating agents are authenticated, and the actual content of the expressed topology should be verifiable and “valid” in context of other known topology.    

Topology is key to pathfinding, and so being able to rely on the veracity and timeliness of the topology information – trust- is critical to a secure and reliable global inter-operability.    These are just a few of the topics that must be considered for a comprehensive Distributed Topolgy Exchange architecture.