Network connectivity use case modeling and yaml syntax
This presentation is the property of its rightful owner.
Sponsored Links
1 / 15

Network Connectivity Use Case Modeling and YAML Syntax PowerPoint PPT Presentation


  • 80 Views
  • Uploaded on
  • Presentation posted in: General

Network Connectivity Use Case Modeling and YAML Syntax. [email protected] 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

Download Presentation

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Network connectivity use case modeling and yaml syntax

Network Connectivity Use CaseModeling and YAML Syntax

[email protected]


Use cases

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


1 a client server single l4 port

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


1 b c client server multiple l4 ports

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


2 a symmetric connectivity

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


2 a symmetric connectivity1

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

Backup Slides


Requires provides

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


Connectsto thus far

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.


Additional use cases

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


Multiple network l4 ports or protocols

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!)


Network connection in opposite direction than req cap

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


Symmetric connectivity

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)


2 a symmetric connectivity2

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


1 b client server multiple l4 ports

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


  • Login