Update 01-introduction.md

documentation/design/01-introduction.md

@@ -38,6 +38,18 @@ Instead there are two use cases to be considered in the implemenation works that
 * Primary: optical domain SDN-controller for the CoCSN project
 * Secondary: SDN-controller for our local labs to manage an Ethernet-based lab environment
 
+### Primary: optical domain SDN-controller for the CoCSN project
+
+For this use case we initally do not consider the direct control of optical network elements, e.g., Optical Add-Drop Multiplexer (OADM) but we focus on optical network domains managed by another (SDN) controllers. The goSDN controller communicates with this domain controller and can request information about the optical network elements, the links between them and the optical and logical configuration of the network domain. 
+
+In a second step, the goSDN controller has to communicate with multiple domain controllers and has to find potential interchange points between these multiple domains. This is the preparation for a later step in this use case, when the goSDN controller has to find a network path between two end-points across multiple optical domains, including backup paths. 
+
+The intention here is to use an existing SDN southbound interface, very likely based on RESTCONF. 
+
+### Secondary: SDN-controller for our local labs to manage an Ethernet-based lab environment
+
+For this use case we consider one of our local labs, e.g., either the telecommunications or networking lab, and how this lab with all its networking parts can be managed by the goSDN controller. In this case, the controller has to learn about all (network) elements, the links and the topology by obtaining all the required information and its own topology computation. This will require an interface between goSDN and the network components that is potentially beyond the typical SDN southbound interfaces. 
+
 ## Structure of this Memo
 
 This memo starts with this introduction that sets the stage for the theoretical underpinings of the SDN-controller