View source for PAT.Data Transport

{{Maturity|2}}
{{Pageheaderbox4PatternType
|PATname=Data Transport
|summary=Comprises a set of facilities to transport data between automated systems
|version=0.31
|owner=J.A.H. Schoonderbeek
|sector=Infrastructure Sector Core
}}
Data Transport provides facilities to transport data between automated systems, within and over different Data Transport Zones.

===Definition of a Data Transport Zone===
This pattern serves to model Data Transport Zones. A "Zone" in this respect means a logical segment of an organization's networks (either data network or storage network). A Zone has a distinct set of security restrictions, quality attributes and characteristics. Thus, multiple network segments will reside in a ''single'' Zone, as long as these security restrictions, quality attributes and characteristics are similar.

===Pattern components by flow===
Any client or infrastructure facility that needs to use the Data Transport facility is connected by means of the Network Access facility. This facility serves mainly as an interface between the client and the Data Transport facility; any architectural measures applied to this facility thus influence all data going into and out of the network.<br>
Multiple instances of Network Access are connected by an Access Aggregation function. This facility could be thought of as a representation of a whole network segment.<br>
Multiple network segments are linked together by a Distribution function, so that traffic from one segment can reach another segment. However, if a segment is located at a considerable geographical distance from another segment, then an Interconnection facility is needed. When no such geographical distances occur, then the facility is not needed, thus it is optional.<br>
In summary: data can be offered to the network via Network Access, and is then transported from the client to its intended destination using Access Aggregation, possibly Distribution, and  if considerable distance is involved, Interconnection.

===Linking multiple Data Transport Zones===
When multiple Data Transport zones are to be connected, then the facility Distribution is the link between them. There are essentially three ways in which to link Data Transport zones:
* Directly. This is indicated in the graphical overview with an extra flow relation from Distribution directly back to Data Transport;
* Over a longer distance. To traverse the distance between the segments, [[BT.Interconnection|Interconnection]] is again needed. Note that it is possible to encrypt traffic en route from one Data Transport Zone to another using [[BT.Encryption|Encryption]];
* Over an intermediary Pattern "Data Zone Protection". When the security restrictions between the two Data Transport zones differ, then the link between the two zones must enforce the differing restrictions. To this end the zones are linked with the aforementioned Pattern, which can perform that enforcement.

===Linking single users ("VPN" solutions)===
For many different reasons, it may be necessary to offer users outside of a Data Transport Zone access to resources inside it. If the user is not inside a Data Transport Zone that is already connected to the Zone with the resources, then the user must connect to the zone using means like dial-in or VPN tunnelling. Such a solution can be located in this Pattern Type in the two Building Block Types [[BT.Interconnection|Interconnection]] (delivering the transport) and [[BT.Encryption|Encryption]] (ensuring security and privacy) combined with adjacent pattern [[PAT.Authentication+Authorization|Authentication & Authorization]] (providing the necessary controls on the remote users of the facility).

===Security aspects===
Within the Data Transport pattern, there are two natural places where security considerations can be taken into account:
* On the connection between the client and the Data Transport pattern. This means enforcing security at the level of the Network Access facility. If needed, enforcement takes place using an Authorization facility as found in the adjacent pattern [[PAT.Authentication+Authorization|Authentication & Authorization]]. Permissions can be styled in a wide variety of ways – think e.g. of the permissions enforced with current NAC (Network Access Control) solutions.
* On crossing over from one Data Transport pattern to another. This has been mentioned under the section "Linking multiple Data Transport Zones" and "Linking single users".
This pattern itself accommodates security management in the following distinct ways:
# The pattern (naturally) allows for monitoring/logging/alerting. If required, one could link this with Security Management & Auditing for any required standard of reactive security measures;
# The pattern allows for authentication and/or authorization both at the network entrance/exit ([[BT.Access|Network Access]]) and on interlinks (between different Data Transport Zones). This ability is delivered by pattern Authentication & Authorization;
# The pattern allows for many types of extra checks on data transport (between Data Transport Zones) by means of the adjacent [[PAT.Data Zone Protection|Data Zone Protection]] pattern.
{{PAgraphic
|graphic=PAT.Data_Transport.png
|source=Pattern_Types.vsd
|size=500px
|title=Data Transport depiction
}}
{{Pattern Type Composition}}
{{Pattern Type Composition Row
|facility=BT.Access
|choice=must
|reason=Via this function, clients can offer data for transport to other connected clients, and receive data that other clients have sent.
}}
{{Pattern Type Composition Row
|facility=BT.Access Aggregation
|choice=may
|reason=This function turns access to network.
}}
{{Pattern Type Composition Row
|facility=BT.Distribution
|choice=must
|reason=When designing networks, then there almost always will be a need to link multiple logical and/or physical network segments; most often with larger networks. This BBT will handle the routing and forwarding issues that these links present. Note that Distribution can be necessary internal to the logical network that the whole pattern described, externally (in a connection between two variants of the Data Transport pattern, or both.

Conversely, this BBT would ''not'' be needed if a relatively small network segment is created without a need for connectivity to other networks - however this scenario is believed not to occur within most organizations.
}}
{{Pattern Type Composition Row
|facility=BT.Interconnection
|choice=may
|reason=When designing larger networks, then there may be a need to link multiple network segments over relatively large distances. Interconnection is the BBT that can provide this functionality, and it handles the challenges that are associated with networking over these longer distances. Note that this BT also allows for (unencrypted) tunneling between Data Transport Zones.
}}
{{Pattern Type Composition Row
|facility=BT.Name Resolution
|choice=may
|reason=Usually an address scheme is chosen for a logical network (or combination thereof), but a different scheme of names is used by the clients (or the network internally). This facility takes care of the translation from name to address (and optionally from address to name). It is not needed in the rare case that no name schemes are in use.
}}
{{Pattern Type Composition Row
|facility=BT.Connection Handling
|choice=may
|reason=This function supports users or systems connecting with this Data Transport Zone over a different path than a connection with this or an adjacent Data Transport Zone. The most common example of this would be a VPN connection. Note that the VPN solution itself is likely to form a Data Transport Zone separate from the Data Transport Zone that it's providing access to.
}}
{{Pattern Type Composition Row
|facility=BT.Encryption
|choice=may
|reason=It may be necessary to connect Data Transport Zones using untrusted intemediary networks (essentially all networks not under control by the organization). In this case, the tunnel between the Zones must be encrypted using this BT.<br>Also, the combination of Encryption and Interconnection can represent remote-connection facilities like a VPN service/dial-in service. Note however that most often it is required to route the traffic entering and leaving this remote-connection facility through the Data Zone Protection pattern. This is because users and systems connecting to the Data Transport Zone often reside in a different Data Transport Zone, security-wise.<br>
Note that when modeling a remote-connection facility, the Data Transport pattern represents a logical data transport zone that encompasses the remote users and the interlinks to the organization's remote connection facility; this zone is separate from the logical data transport zone that the users are connecting to.
}}
{{Pattern Type Composition Row
|facility=BT.Compression
|choice=may
|reason=Just as with Encryption, it may be necessary to add extra functionality to any Interconnection. Compression in this case can be added to increase capacity on the Interconnection.
}}
{{Table Ending}}
{{Pattern Type Neighbors}}
{{Pattern_Type_Adjacent_PAT_Row
|pattern=PAT.Data Zone Protection
|choice=may
|reason=Usually two logical network segments are described by different Data Transport pattern variants because the security contexts (and thus requirements) for the segments differ. If this is the case, then a connection between these segments needs to make use of this pattern Data Zone Protection, in order to ensure the right security levels in both segments. However if the network segments have the ''same'' security requirements (and differ only in characteristics and/or quality levels), then they can be linked without use of this adjacent pattern.
}}
{{Pattern_Type_Adjacent_PAT_Row
|pattern=PAT.Authentication+Authorization
|choice=may
|reason=If a network section needs security, this facility can be included. In essence it provides (a generic form of) access control, by performing one or more checks on the client that tries to gain access to, or use, the network. Access controls are a form of authorization data, which are stored in an (included) Permission Register.
}}
{{Pattern_Type_Adjacent_PAT_Row
|pattern=PAT.Facilities Deployment
|choice=may
|reason=Clients that want to make use of a Data Transport facility most often need configuration data like a network name and a network address. While these may be thought of as internal to the Access facility, there still is a need for a facility that can provide these configuration data. This facility is (a variant of) Facilities Deployment.<br>Note that there may also (still) be a need for the "usual" Facilities Deployment by IT Operations, e.g. for the deployment of firmware for appliances et cetera, but these needs are for management of the Data Transport pattern rather than the operation of it.
}}
{{Pattern_Type_Adjacent_PAT_Row
|pattern=PAT.Facilities Monitoring
|choice=may
|reason=When a Facilities Deployment pattern is used to offer clients the necessary configuration data (e.g. network address and name), then there also might be a need to monitor the usage of this data. To this end, a monitoring facility can be employed.<br>Note that there may also (still) be a need for the "usual" Facilities Monitoring by IT Operations, e.g. for monitoring availability and utilization of network devices et cetera, but these needs are for management of the Data Transport pattern rather than the operation of it.
}}
{{Table Ending}}
{{PATfooter}}