Connectivity Capability Features TOSCA

Aspects of Connectivity GenericIP Connectivity Resolvability: ARP: IP/MAC DNS: Name/IP MDNS: Netconf Routing/bridging/tunneling: Localhost VN IP tables LinkLocal Private/Public Filters Assignment Static IP / DHCP Link Local HostFile/DNS Subnets Mac aspect Performance elements: Bandwidth, latency, reliability, etc. Data Isolation, Encapsulation

Semantic composition of specialized connectivity features. Select one of the mutually exclusive enumerated values from an aspect of connectivity. Combine several of the mutually exclusive enumerated values from one or more aspects. Split connectivity into kinds (ipv4 vs ipv6) and combine with one or more aspect enumerated values (special case of above). Procedures are really TBD by trial and error in this task group; starting with specific connectivity cases to identify declarative features...

Specializations of Connectivity: “localhost” case. Example: Localhost from the routing. IPv4 semantics : communication between nodes that target this network feature will use /8 CIDR block. Relevant properties: “transportLayerProtocol” : “TCP” ; “port” : “2234”. IP address, DNS names, or subnet values ignored. Note that this feature would binds nodes within one VM/OS; scalability options are thereby constrained.

Specializations of Connectivity: simple “arp” case. Arp is used in ipv4 networks to find the layer 2 encapsulation for an ip destination (i.e, the mac address of the interface with a given ip address in the local layer2 “broadcast” domain). For VNs of VMs, this connectivity feature constrains the IP subnet of a specified IP address in various ways. E.g., mac encapsulation is needed; virtual interfaces need to be of the TAP type. Configuration enhancements for bridging will be needed when VN subnets span distinct host systems.

Specializations of Connectivity: “server”+“dhcp”+“arp” case. If a node is a server and has a static IP address given by its TOSCA property, and a cidr block specified for the IP subnet, then the ARP domain using DHCPv4 must be configured to not assign the static server address. In general, there will be specific implications of combining connectivity features with networking property values. Should these implications be generally specified or left to implementation. How do these choices impact claims of TOSCA “portability” of models?

Specializations of Connectivity: “wanbridge tunnel” + “private”+“dhcp”+“arp” case. As before, but spread VN subnets over hosts in 2 clouds (one public, one private). IP address of server is in private range. Some layer 2 encapsulation technique needed to bridge subdomains into ARP broadcast domain. There are many distinct ways to do this. Will it be OK to let this be “up to” the implementation(s)? How will the implementations coordinate their configuration decisions? [Open issue.]

Specializations of Connectivity: “NDP” +“ipv6” case. No ARP for ipv6. “NDP defines five ICMPv6 packet types for the purpose of router solicitation, router advertisement, neighbor solicitation[135], neighbor advertisement[136], and network redirects.ICMPv6