1 / 15

Network Connectivity Use Case Modeling and YAML Syntax

Network Connectivity Use Case Modeling and YAML Syntax. dpalma@vnomic.com. Use Cases. Client to Server connectivity Single L4 port Multiple network L4 ports or protocols required to realize the connectivity Network connection in opposite direction than Req /Cap relationship

kelli
Télécharger la présentation

Network Connectivity Use Case Modeling and YAML Syntax

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Network Connectivity Use CaseModeling and YAML Syntax dpalma@vnomic.com

  2. Use Cases • Client to Server connectivity • Single L4 port • 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

  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: tcp dest_port: 2049 … - lockd_tcp: ip_proto: tcp dest_port: 32803 Initiator indicates which side of the connectsTo relationship initiates the connection. Symmetric means either side (any order). Consumer is default matching today’s semantic. Any combination of ports can be specified. ‘src_port’ specifies client side ‘dest_port’ specifies server side ‘src_from’ and ‘src_to’ specify client port range ‘dest_from’ and ‘dest_to’ specify server port range

  5. 2(a) Symmetric connectivity All providers can initiate in any order. This means the orchestrator can ignore order. 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. For servers derived from same compute node we don’t need to say more. 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. <properties of an endpoint capability> initiator: symmetric port_specs: - jgroups_multicast: ip_proto: igmp dest_port: 2049

  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)

  7. Backup Slides

  8. Requires/Provides • EndPoints are Capabilities • Component A requires and endpoint E1 which B provides • Component A resolves to B (and its subclasses) at assembly time Component A Component B Requires (E1) Provides (E1) Connector

  9. ConnectsTo (thus far) • Component A connectsTo Component B • i.e. Component A requires a connection to Component B Component A Component B Requires (E1) Provides (E1) ConnectsTo Client Server Connection • 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.

  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 this Component A Component B Requires (E1) Provides (E1) Client Server 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: ‘port_spec_defs’ should be scoped by namespace They can be provided at the root level of documents and implicitly as part of the environment They could be generalized as part of a more general ‘connectivity spec’ <property of an endpoint capability> port_specs: - nfs_tcp - nfs_udp <root document level> port_spec_ defs: - nfs_udp - nfsd_udp: ip_proto: udp dest_port: 2049 …

More Related