Network Connectivity Use CaseModeling and YAML Syntax

dpalma@vnomic.com

2

Use Cases

1. Client to Server connectivitya. Single L4 portb. Multiple network L4 ports or protocols required

to realize the connectivityc. Network connection in opposite direction than

Req/Cap relationship

2. Symmetric connectivitya. Both A and B can connect to each other in any

order

3

1(a) Client Server, Single L4 port

• Already supported with specific syntax– Server-side port specified– Client-side port not specified, assumed ephemeral

• Do we want to keep special syntax for this case or support only a more general syntax which expresses any number of ports?

<property of an endpoint capability> port: type: integer constraints: - greater_or_equal: 1 - less_or_equal: 65535

4

1(b,c) Client Server, Multiple L4 ports

<properties of an endpoint capability>initiator: *consumer| provider | symmetric port_specs:

- nfsd_udp: <display_name> ip_proto: udp

dest_port: 2049- nfsd_tcp:

ip_proto: tcpdest_port: 2049

…- lockd_tcp:

ip_proto: tcpdest_port: 32803

1. Initiator indicates which side of the connectsTo relationship initiates the connection. Symmetric means either side (any order). Consumer is default matching today’s semantic.

2. Any combination of ports can be specified.

3. ‘src_port’ specifies client side

4. ‘dest_port’ specifies server side

5. ‘src_from’ and ‘src_to’ specify client port range

6. ‘dest_from’ and ‘dest_to’ specify server port range

5

2(a) Symmetric connectivity<properties of an endpoint capability>initiator: symmetric port_specs:

- jgroups_multicast: ip_proto: igmp

dest_port: 2049

1. All providers can initiate in any order. This means the orchestrator can ignore order.

2. connectsTo is about order. This means we cannot allow connectsTo with end points with symmetric initiation. I.e. this is a completely different relationship type.

3. For servers derived from same compute node we don’t need to say more.

4. For different compute nodes we need a relation to denote the members of the symmetric connectivity group. This is an n-ary relation if we want to support 3 or more compute nodes in the same symmetric group.

6

2(a) Symmetric connectivity

• Binary relation with group name property. All providers targeted by the relation with same name belong to same group.– Pros

• Allows us to continue to use binary relation syntax

– Cons• Still implies directionality. For every pair of nodes need relation in

both directions because it is the server which denotes symmetric connectivity unless we make an exception this for this relation

– Explore a non-directional relation. Not obvious since Requirement/Capabilities, the meta construct for relations, is currently fundamentally directional (asymmetric)

Backup Slides

Requires/Provides

Component A Component B

Connector

Requires(E1)

Provides(E1)

• EndPoints are Capabilities • Component A requires and endpoint E1 which B provides• Component A resolves to B (and its subclasses) at assembly time

ConnectsTo (thus far)

Component A Component B

ConnectsTo

Requires(E1)

Provides(E1)

• Component A connectsTo Component B• i.e. Component A requires a connection to Component B

• Connection has been assumed to be a single network connection, e.g. Client connection of TCP to MySQL at well known port 3306 over one network connection.• Client side of connection is assumed to be the requiring side of the relationship.

Client Server

Connection

10

Additional Use Cases

• Multiple network L4 ports or protocols required to realize the connectivity

• Network connection in opposite direction than Req/Cap relationship

• Symmetric connectivity– Both A and B can connect to each other in any

order

11

Multiple network L4 ports or protocols

• Consider NFS– TCP or UDP: 2049(nfsd), 111(rpcbind), 892(mountd), 662(statd)– TCP 32803 (lockd)– UDP 32769 (lockd)

• We must be able to express – Multiple ports– Connection direction (see opposite direction use case)

• Consider firewall filter tuple syntax and treat as directional flow

• Use white-listing (assume everything is disabled by default) NOT black-listing (we don’t know what is open by default!)

12

Network connection in opposite direction than Req/Cap

• A DB is deployed– It requires needs monitoring implemented by an

additional monitoring node– Monitoring node connects to DB node via SSH

(could be any protocol, it is the direction that is important here) to collect metrics

• Need to be able to express thisComponent A Component B

Requires(E1)

Provides(E1)

ClientServer

Connection

13

Symmetric connectivity

• Consider a cluster– They may know each others’ IP address and connect

to each other via the same well known port over TCP– They may use a multi-cast cluster discovery/group

membership protocol• This is peer-to-peer– Any member can initiate communication– Expresses membership– Order is not important (for orchestration)

14

2(a) Symmetric connectivity

• Options for denoting groups– N-ary membership relation

• Pros– Concisely captures the required semantics

• Cons– New construct placed in a top level element which references the end endpoints in the member nodes

• Need to explore syntax details

– *Binary relation with group name property. All providers targeted by the relation with same name belong to same group.• Pros

– Allows us to continue to use binary relation syntax

• Cons– Still implies directionality. For every pair of nodes need relation in both directions because it is the server which

denotes symmetric connectivity unless we make an exception this for this relation

• Explore a non-directional relation. Not obvious since Requirement/Capabilities, the meta construct for relations, is currently fundamentally directional (asymmetric)

– Add a group name to the endpoint properties• Pros

– Sounds simple and is– The name implies membership

• Cons– Has implications in composability but not worse than cross document relations– Not a real relationship so tooling needs a special understanding of this

15

1(b) Client Server, Multiple L4 ports

• It’s useful to define sets of port_specs and refer to them by name, e.g. nfs_udp, nfs_tcp and compose them:

<property of an endpoint capability>port_specs:

- nfs_tcp- nfs_udp

1. ‘port_spec_defs’ should be scoped by namespace

2. They can be provided at the root level of documents and implicitly as part of the environment

3. They could be generalized as part of a more general ‘connectivity spec’

<root document level>port_spec_ defs:

- nfs_udp- nfsd_udp:

ip_proto: udpdest_port: 2049

…