180 likes | 508 Views
The Transport Layer (L4). Provides an end-to-end, reliable transport service between l4 entities Reliable - error-free, in-sequence, no loss or duplication Typically connection-oriented can be connectionless depends on needs of application. ISO Transport Layer.
E N D
The Transport Layer (L4) • Provides an end-to-end, reliable transport service between l4 entities • Reliable - error-free, in-sequence, no loss or duplication • Typically connection-oriented • can be connectionless • depends on needs of application
ISO Transport Layer • ISO classify subnets as type A, B and C • (reliable to unreliable) • Define 5 different Layer 4 protocols to operate over these 3 types • Class 4 protocols (TP4) is defined to operate over an unreliable network • TP4 functionality almost identical to TCP
Connection oriented service • typical 3 phase connection • establish connection • data transfer • terminate connection • T-Connect, T-Data, T-Disconnect services, with service primitives • .request • .indication • .response • .confirm
Parameters associated with primitives, e.g. • Addressing • Quality of Service parameters • Addresses are T-SAP identifiers • (Sockets in TCP/IP terminology) • Can be well known addresses • Can be ‘discovered’ at connection set-up time • T-Connect can then be directed to appropriates • address, T-SAP identifier (socket)
Quality of service is negotiated. • Source specifies requirements • network and destination agree or modify these. • Typical QoS parameters • throughput, end-to-end delay, error rate, etc • Connection requests can be denied by local or remote L4 entity
L4 has very similar functionality to L2 (link layer), but • L2 operates (typically) across a link • L4 operates end-to-end (across a network)
Main issues are:- • Connection establishment and termination. • Error and flow control • Buffering and multiplexing.
The problems arising from these issues are:- • how to guarantee ordered delivery of PDUs to the users • how to ensure that only legitimate connections are established • how to ensure that connections are broken down in a proper manner • how to ensure that connections are terminated correctly • how to separate acknowledgements from flow control, i.e. • Tell source everything has arrived OK • send / don’t send any more (yet)
Ordered delivery • relies on every (data) TPDU being numbered • SREJ typically used at L4 for error recovery, this impacts on • number of TPDUs which can be ‘in transit’ • remember connection is across a network • connection distance is long • potential inefficient use of channel capacity • need long sequence numbers • buffering at destination
Long connection distance can cause other problems • if connectionless layer 3 in operation • TPDUs can take different routes • therefore can get delayed (lost) • Can’t therefore allow same sequence numbers to be reused between different connections • else a delayed TPDU, from a terminated call, could arrive and be accepted • Initial Sequence Numbers defined at connection establishment
Connection establishment phase - three-way handshake • CR(Connection Request) sent by source, with proposed start sequence no • CR(ISN = x) • CC (Connect Confirm) sent by destination, with ack of x, and their own start sequence no • CC(ISN=y, ack=x) • Source acks CC • ACK(seq = x, ack=y) • Only valid connections will be established
Connection Termination • Three way handshake also used to ensure all TPDUs have arrived before connection terminated • TPDUs are DR and DC, e.g. • DR(last sent = a, ack =b) • DC(last sent = b + 2, ack = a) • Ack(last sent = a, ack = b+2) • Connection will remain opern until final Ack is received
Error Control • Typical ARQ, but with sequence numbers constraints outlined above • clearly includes acks, retransmissions, etc, as appropriate • Can also use checksum on data
Flow Control • Flow Control is a more difficult problem • SREJ typically used for error recovery • essential if error control is across the network • essential if connectionless network (L3) under L4 • Need to buffer out of sequence frames • Need large buffers at destination, to buffer out of sequence TPDUs
Hence, Ack cannot be misinterpreted as meaning • ‘I have acked another 2 TPDUs’ • ‘So, you can send 2 more TPDUs’ • Ack means TPDUs have arrived correctly • Permission to transmit more data must be signalled separately • this is a flow control issue
Mechanics of separate Acks and Flow Control • Acks (and certain other TPDUs) have a separate CR(credit field) • e.g. (AK=n, CR=m) • Acking upto TPDU n, permission to send m TPDUs (after n) • Flow control is achieved by adjusting value of m • m may be zero • Timers used (as for L2) to ensure deadlock doesn’t occur
Multiplexing • Upwards and Downwards multiplexing allowed • Upwards Multiplexing • Several transport connections using one layer 3 connection • Multiple calls to the same destination • Downwards Multiplexing • One L4 connection spread over multiple L3 connections • Necessary if L3 connect slow, and high data rate to transmit • One-to-one multiplexing more common
Summary - L4 Functionality • To insulate application (upper layers from subnet (lower 3 layers) • End-to-end (connection oriented) service • Ordered delivery of TPDUs • Issues and sequence number selection and sequence number length • Ensuring only valid connections accepted • Need for 3 way hand shake • Ensuring connections terminated correctly