Difference between revisions of "VPP/HostStack/SessionLayerArchitecture"

From fd.io
< VPP‎ | HostStack
Jump to: navigation, search
(Session Layer Architecture)
(Session Layer Architecture)
Line 3: Line 3:
 
TBD: walk through
 
TBD: walk through
  
[[File:Session API.png|850px|center|Session API Diagram]]
+
[[File:Session API.png|900px|center|Session API Diagram]]
  
 
=== Session Namespaces ===
 
=== Session Namespaces ===

Revision as of 21:41, 7 March 2018

Session Layer Architecture

TBD: walk through

Session API Diagram

Session Namespaces

In order to constrain the range of communication, applications are supposed to provide at attachment time, the namespace they pertain to and a secret. Namespaces are configured in advance/independently and serve as a means of associating applications to network layer resources like interfaces and fib tables. Therefore they serve as a means to constrain source ips to be used and limit the scope of the routing. If applications request no namespace, they are assigned to the default one, which at its turn uses the default fib and by default has no secret configured.

Multiple namespaces can use the same fib table, in which case local inter-namespace communication uses shared memory fifos. However, if the namespaces use different fib tables, communication can be established only post ip routing, if any fib table/vrf leaking is configured so shared memory communication is not supported anymore. It should be noted that when a sw_if_index is provided for a namespace, zero-ip (inaddr_any) binds are converted to binds to the requested interface.

Session Tables

Another option for applications is to provide the scope of their communication within a namespace. That is, they can request a session layer local scope, as opposed to a global scope that requires assistance from transport and network layers. In this mode of communication, shared-memory fifos (cut-through sessions) are used exclusively. Nonetheless, in_addr_any (zero) local host ip addresses must still be provided in the session establishment messages due to existing application idiosyncrasies.

This separation allowed us to define a type of session layer ACLs, something we call session rules, whereby connections are allowed/denied/redirected to applications. The local tables are namespace specific, and can be used for egress session/connection filtering: i.e., connects to a given ip or ip prefix + port can be denied. Whereas, global tables are fib table specific, and can be used for ingress filtering: i.e., incoming connects to ip/port can be allowed or dropped.

The session rules are implemented as a match-mask-action data structure and support longest ip prefix matching and port wildcarding.