Higher levels protocols support

DEPARTMENT OF COMMUNICATION NETWORKS

Bubentsova L.V., Korchynskyi V.V.

The analysis of multiprotocol traffic routes of Frame Relay network

METHODICAL INSTRUCTIONS

TO LABORATORY WORK № 6

FOR STUDENTS OF ALL FORMS OF STUDYING

IN «TELECOMMUNICATIONS»

APPROVED

By methodical council

Of Academy of Telecommunications

Protocol №

Odessa 2012

1 Purpose of work

1.1 Get acquainted with the general principles of analysis of the encapsulated traffic in data transmission networks.

1.2 To carry out analysis of the basic procedures of higher levels protocols support by Frame Relay protocol.

2 Key positions

Higher levels protocols support

To support higher levels protocols with Frame Relay protocol two main procedures are needed: multi-protocol encapsulation and traffic fragmentation. Let’s consider these two procedures with respect to the basic types of protocols of global data networks (WAN) and to the analysis of interaction processes of LAN networks via WAN.

2.1.1 Multi-protocol encapsulation. LAN networks interaction via Frame Relay network

Terminal equipment of users, such as host computers, during the interaction of LAN networks through the Frame Relay network can receive data from multiple virtual connections. In this case, an important task, which is solved by the multiprotocol encapsulation procedure, is to identify the type of sending/receiving traffic from the LAN. Frame Relay network provides transmission of two basic types of traffic: directional (packets from the routers - routed traffic) and bridge (packets from the bridges - bridge traffic). Format of messages related to a multiprotocol encapsulation is shown in Fig. 2.1.

Fig. 2.1. Frame structure of a multiprotocol encapsulation

As it can be seen from the figure, the information field of the transmission frame of encapsulated traffic includes:

• control field Q.922, which total length is 1 octet;

• an additional field (Pad), supplementing the control field to two octets and having a length of 1 octet with a value of 00;

• network layer protocol identifier NLPID (Network Layer Protocol ID), which provides identification of the type of encapsulation protocol (see below);

• higher level protocol information.

For the encapsulation procedure the following types of protocols, described in standard ISO / IEC TR 9577 with the corresponding values ​ ​ of NLPID, can be used:

• Protocol ITU-T in accordance with rec. Q.933 (NLPID = 08 in hexadecimal representation);

• Subnetwork Access Protocol (Subnetwork Access Protocol - SNA, SNAP) (NLPID = 80);

• ISO network layer protocol without orientation on connection (ISO Connectionless Network Protocol-CLNP) (NLPID = 80);

• Internet Protocol (Internet Protocol - IP).

During using the Q.933 protocol for encapsulation in the information field structure includes the protocol identifier of the second and the third level, two octets each. The identifier values ​ ​ correspond to the value of the identifier of LLC information element. During using of SNAP protocol for encapsulation, information field includes an additional SNAP header. The header consists of two parts:

- Identifier of traffic type OUI (Organizationally Unique Identifier) with the length of ​ ​ three octets, which determines the type of transmitting traffic (routed or bridge);

- User data protocol identifier PID (Protocol Identifier).

In the case of traffic transfer from routers (Routed Packets, OUI = 00 00 00) Ethertype message is being sent in the PID, which is part of the standard Ethernet frame. In the case of transfer traffic from the bridges (Bridged Packets) different values ​ ​ of the PID identifier for different local networks protocols (from Ethernet to FDDI) are used (see Fig. 2.1).

Fig. 2.2. Structure of the Frame Relay frame with

an encapsulation frame LAN / Ethernet IEEE 802.3

Procedures for encapsulation of IP and ISO CLNP protocols use a standard format of an encapsulating frame with no additional messages in the information field. As an example, Fig. 2.3 shows the encapsulation of IP datagrams into the Frame Relay frame.

with the encapsulated IP datagram

Examples of an encapsulated traffic analysis are given in Appendix 8.

2.1.2 Х.25/Х.75 protocol encapsulation

Frame Relay network can execute functions of transport medium for packet commutation networks based on X.25 protocol. In that case Frame Relay and X.25 protocols must be fully compatible, i.e. encapsulation and decapsulation procedure should save user information, as well as the structure of the protocol. Thus, we are talking about converting of X.25 protocol to the Frame Relay protocol, and vice versa. Since this procedure is significantly different from the procedures of LAN traffic encapsulation, it stands out in a separate class, called the interaction functions or IWF (Intel-working Functions). Schematically, the IWF procedure shown in Fig. 2.4

Fig. 2.4. Scheme of Frame Relay и Х.25 protocols interaction

X.25 protocols stack contains two levels: LAPB (Link Layer Protocol) and PLP (network layer protocol). On the network node, where there is support and X.25, and Frame Relay, X.25 encapsulation procedure is provided in the Frame Relay IWF (Figure 2.5). Herewith, network level information (PLP) is transmitted to a Frame Relay network transparently, without recognition and decoding, and recovery of the message structure is provided on the remote X.25 DTE, supporting the function of IWF. In the process of encapsulating the X.25 packet in the Frame Relay frame the placing of the address, control and information fields in the LAPB Frame Relay frame format is being provided. Then the new address of connection via DLCI network is being added and calculation of the new FCS value is being provided. The reverse process of decapsulation is performed on the remote DTE with the functions of IWF.

Fig. 2.5. Х.25 packets encapsulation to the Frame Relay frames