Table of Contents

Frame Relay

General description

Description of frames

Legend:

LMI signaling
Definitions

Subscriber side (FR-CE):
Network side (FR-TE):

Notes:
Quality of service (QOS)
Access rate: Corresponds to the rate of the physical line.
Examples:
Overrun of CIR or Bc :
Congestion management
Congestion management on FR-CE interface
Principle of flow control

NETWORK CONGESTED

Congestion management at FR-TE interface
Management of COSs (Class Of Service)

Threshold management:

Network architecture principle
Configuration of an attached DLCI
Management of COS and QOS fields
Location of QOS configuration
Control rules
Behavior associated with DLCI FRAV
Behavior associated with a DLCI FRI
Backup of a PVC by another PVC
Frame Relay and ISDN

Closing of channels B
Emergency shutdown
Shutdown on inactivity
FR network access backup (case A)
Class 1, rec 1
Class 12
Class 32
Class 22
Class 30
Class 9
Class 32
Class 22
Class 30
Class 12
Class 9

Backup of PVC (case B)

Examples PVC backup and backup shutdown
Class 1, rec 1
Class 12
Class 32
Class 30
Class 22
Class 9

Configuration of frame relay lines, type transit (FRSW) and connection VCX100

Principle:
Configuration of a HDLC or frame relay subscriber (FRA) line

Configuration of PVCs multiplexed on an FRTE interface

C1R1
C12R4 \xde line 4
C17R0
C8R0

Example of configuration of C17 of machine 8000 20

C17R0
FastPADmp/mpr Configuration
Encapsulation examples
First example:
Second example:
Third example:
Fourth example:
Fifth example:
Sixth example:
Seventh example:

Frame Relay

Frame Relay

General description

Frame relay (FR) is a frame mode transfer service for long distance communication WAN (Wide Area Network).

The frame relay is part of the fast frame switching technologies.

It multiplexes data at level 2 (ISO layer modeling link layer) without resuming transmission on errors.

To do this, it is different from the X.25 protocol and brings to the benefit of applications progress made with data transmission networks making level 2 error detection processing and transmission recovery on detected errors pointless.

It is simplified with respect to the X.25 protocol; the frame relay protocol offers shorter switch crossing times and faster bit rates.

The service is based on the modified LAP-D (LAP-D : Link Access Procedure on D-channel) frame structure, designated as LAP-F (defined by IUT-T recommendation Q.922).

Like X.25, the frame relay offers services in the connected mode.

The existence of a logical end to end location requires the prior permanent connection (PVC : Permanent Virtual Connection) with associated signaling (LMI or Local Management Interface, defined in IUT-T recommendation Q.933 Appendix A and standard ANSI T1.617 Appendix D).

The frame relay technology applies to WAN networks and various interworking standards with all the protocols that exist make this a multiprotocol transport service ideal for establishing intersite WANs (interworking with X.25, SNA, Apple Talk, IP, IPX, DECNET).

The performance of the frame relay also makes it possible to transport voice and images, whether correlated or not, with data originating from LANs.

Description of frames

There are two types of frames:

• Information frames,

• Signaling frames.

Legend:

DLCI = Data Link Connection Identifier Destination identifier address field

DE = Discard Eligibility bit Marks a frame as eligible for deletion in case of congestion

BECN = Backward Explicit Congestion Notification bit Transmission upstream of congestion difficulty

FECN = Forward Explicit Congestion Notification bit Transmission downstream of congestion problem detection

C/R = Command/Response indication bit This bit is not used at frame relay level. It is used at higher level protocols.

msb = Most Significant Byte

lsb = Least Significant Byte

LMI signaling

LMI signaling can be of three types:

Three major interfaces have been defined by the Frame Relay Forum.

UNI (User to Network Interface)

NNI (Network to Network Interface) (not supported by V12.2).

NUI (Network to User Interface).

The subscriber LMI (LMI UNI) regularly transmits status inquiry messages and the network LMI (LMI NUI) answers with status report messages.

LMI UNI signaling enables subscribers to find out about the PVC status of the network, thus inhibiting the use of an unavailable PVC and supplies procedures for detecting and modifying the following events:

• deletion of a PVC,

• addition of a PVC,

• availability of a configured PVC,

• unavailability of a configured PVC,

• error due LMI message sequencing.

Two standard protocols are used for the local management interface:

• ANSI T1.617D

• CCITT Q.933A.

Definitions

FR-TE = Network access

FR-CE = Subscriber access

Supported protocols: FR-CE and FR-TE interfaces can be transparent or manage encapsulation corresponding to the higher transported level protocol.

Subscriber side (FR-CE):

FRA (or FRAV) : FR subscriber connecting to an X.25 network.

Network side (FR-TE):

FRSNA : Transport of SNA flow as per RFC 1490

FRIP : Transport of LAN adaptation protocol as per RFC 1490.

FRT : No processing performed

FRI : Reliable transport on frame relay

FRSW : Specific case of FRI where relay operation is simplified. This interface is used more particularly for connection of voice boards.

FRAV: Automatic recognition of transported protocol type and selection of one of the above modes.

Notes:

• On FR Switch (FRSW), the DLCI couple associated with a PVC must belong to the same module. This interface carries out simple relaying.

• On FR Switch (FRSW), the speed must be configured in such a way that the sum of the incoming rates equals the sum of the outgoing rates. The congestion (FECN, BECN) is not managed but the notification of these bits is transported.

Quality of service (QOS)

The traffic profile associated with a Frame Relay connection is defined by a set of parameters.

Access rate: Corresponds to the rate of the physical line.

CIR (Committed Information Rate) Corresponds to the maximum average rate per connection (PVC) for a period T.

Bc (Committed burst) Maximum duration a connection may use to transmit one or several frames consecutively.

Be (Extended Burst) Additional tolerance on the value of Bc.

Examples:

CIR = 0 : The network does not guarantee data transfer.

Overrun of CIR or Bc :

Positioning of the DE bit of the frames which may lead to elimination of frames on the following nodes in case of congestion.

Congestion management

Congestion management is based on the control of the bit rate received from the user to the network. Management is shared between end equipment and network nodes, as follows:

FR-CE interface

• Rate check by DLCI depending on required QOS,

• Congestion management by DLCI depending on requested QOS,

• Line congestion management (local congestion).

FR-TE interface

• Congestion management by line

Congestion management on FR-CE interface

Stringent checking of the rate received from the user is carried out in the access equipment. This check is performed by DLCI. The possible rate checking strategies are:

S1 = Control: "traffic policing (discard but don't delay)" Standardized management of CIR. The received frame transit time is privileged. In case of congestion, access frames are discarded.

S3 = Smoothing: "traffic shaping (delay but don't discard )" Optimized congestion management, limits frame loss. Outside congestion, traffic is smoothed on Bc+Be to minimize frame loss risks. On network congestion indication, FRAD (access equipment) privileges transit time by discarding excess frames (> Bc).

S4 = Permanent smoothing: "traffic shaping (delay and discard only if no more memory)" Optimized congestion management to minimize frame loss. The traffic is always smoothed. Outside of congestion, it is smoothed on Bc+Be, as in previous case. On network congestion indication, the FRAD continues to smooth but on Bc.

Table 13-1 summarizes the strategies and location of the flow control.

Figure 13-3:
Example

---

Note The control strategy (S1) has no impact on the transit time. Conversely, the smoothing strategies (S3 and S4) increase this transit time.

---

Principle of flow control

There are two cases of flow control (CIR):

• Network not congested. The terminal equipment does not receive the congestion bit.

• Network congested. The terminal equipment receives the congestion bits BECN=1 and DE=0.

Network Not Congested

If the network is not congested: As long as the amount of information received is below the Bc credit, frame switching will take place transparently in real time. When the amount of information received without a bit DE set to 1 exceeds the Bc credit and is less than the Bc+Be credit, the frame is switched in real time with discard priority information (bit DE set).

For the control strategy (S1):

When the authorized Be credit is exceeded, all the frames with bit DE = 1 are discarded. defined. When the amount of information received exceeds the Bc+Be credit, all the received frames are discarded.

For strategies S3 and S4 : defined. When the amount of information received exceeds the Bc+Be credit, received frame switching is suspended. Frame switching is resumed as soon as the rate drops between Bc+Be.

R = frame "discarded"

S = frame "switched" in real time

SDE = frame "switched" in real time. The DE bit is set to 1

SLBe = frame transmitted with smoothing on Bc+Be

NETWORK CONGESTED

On reception of a set BECN,

• If the traffic is less than Bc, switching is in real time

• If the traffic is greater than Bc,

For strategies 1 and 3: All the received frames are discarded.

For strategy 4 : The traffic at CIR is reduced and received frame switching is suspended. It is resumed as soon as the rate drops below Bc. If the network is still congested in spite of smoothing (more than 50% received frames containing BECN bit during smoothing time interval), traffic is reduced with a drop to 1/8th of the current CIR up to the minimum CIR. If the congestion decreases (less than 50% frames received containing bit BECN during the smoothing time interval), the traffic is smoothed to 9/8th of the current CIR up to the configured CIR.

The network is considered to be no longer congested when all the frames received from the network no longer have a BECN bit for a given time interval (ª 200 ms by default).

SLBc = frame transmitted with smoothing on Bc

Congestion management at FR-TE interface

Congestion control in an FR network takes place generally on trunk lines by managing the filling rate of the frames in the transmission queues.

When the congestion thresholds of these queues are reached, the defense mechanisms are implemented that are graduated according to the COS (Class Of Service, see below). A first defense level consists in setting the FECN and BECN bits for the congested DLCIs.

Management in this way relieves congestion for the user by reducing the flow of data to be switched in the network. It is aimed at establishing a stable slaving loop between user and network.

To offer a slaving loop to all types of traffic, including unidirectional traffic like file transfers, the distant end equipment receiving the FECN frame notified by the network may return spontaneously to the transmitter a specific slaving frame containing the BECN bit = 1 and bit DE=0.

Slaving frames are generated and processed at the FRTE interface of the end equipment as a function of a configuration parameter (par 73).

Management of COSs (Class Of Service)

Each FR connection belongs to one of the following flow types:

• UBR flow (non-FR user protocol).

• VBR flow (FR data user protocol).

• VBR-TR flow (FR voice user protocol).

To offer a fair share of the physical line passband between UBR, VBR and VBR-TR users, 2 transmission queues are implemented per trunk line (1 queue per COS).

Threshold management:

Priority FA (VBR-TR) : a safeguard threshold limited to 512 elements. In practice, this FA only contains n elements (a few dozens). This number n corresponds to the voice frames awaiting transmission i.e., at most, the number of n connections multiplexed on the physical line.

Non-priority FA (VBR/UBR) : 4 thresholds are defined, threshold1, threshold2, threshold3 and threshold4.

• Threshold 1 is not available in the FastPADmp line and is the VBR flow selective congestion threshold. Congestion notification is sent in both traffic directions (FECN and BECN) for connections responsible for congestion (new received frames having bit DE).

• Threshold 2 is the overall congestion threshold for the VBR/UBR flow. Beyond this threshold, all the new frames are marked by the congestion bit (FECN and BECN).

• Threshold 3 is the selective discard threshold for the VBR/UBR flow. Beyond this threshold, the new frames marked DE are discarded.

• Threshold 4 is the total reject threshold. All the new frames are discarded.

Network architecture principle

A Frame Relay network is a way of interconnecting FR users as well as users dialoguing with any protocols.

On access, FR users are connected to the network solely by PVC FRs whereas Legacy protocol users are connected to the network with PVCs or SVCs (e.g. X25). Any data transfer on a PVC FR is only possible once a connection has been established.

In the case of a PVC connection (FR, SDLC, LAN) to a PVC FR, connection is internal to the equipment (between input and output). This connection is established at the initiative of one of the calling ends. The calling end must indicate the address of the other connection end (the called end). Each connection end is associated with an address that can be deduced from the configuration (implicit) or indicated specifically as a configuration (explicit). It is advisable for the calling end to be the line connected to the subscriber (FR_CE type), with the other end on the network line (FR_TE type).

Example : Simple switching of transparent FRAV frame

Case of PVC-PVC connection attached to FR

To connect between DLCI1 and DLCI2, the address of DLC12 is associated with DLCI1. DLCI1 is the calling end and DLCI2 is the called end.

Figure 13-4:
Example

The information needed for configuring a DLCI is:

• physical line number,

• DLCI number,

• associated COS,

• transport protocol,

• distant DLCI number.

Each attached DLCI is associated with a virtual line (VL) number (used by routing).

Figure 13-5: Example

Configuration of an attached DLCI

The attached DLCI type is configured in class 30 and the DCL2 is configured in class 32.

The attached DLCIs can be configured at the user or network end as follows:

C32R0 : physical_line, (empty=FF), DLCI, [cos/priority]

R1 : [num_lv], [establishing_mode], (empty=FF), rec_c30

R2 : [CIR], [Bc], [Be], [CIR_min], [strategy]

R3 : [distant_address]

• physical_line is the FR line number;

• DLCI is one of the DLCIs of the LV (virtual lines);

• cos/priority is the retained service class

• [num_lv] is a virtual line LV number included in one of the two arrays 65-124, 160-239 or FF (empty) if this number is not destined to appear in the routing (class 9). It will then be attributed dynamically;

• rec_c30 is the index in C30 of a recurrence whose profile designates the type of virtual line. The FRAV is characterized by the profile 83;

• [establishing_mode] specifies the behavior associated with the DLCI. This field is only interpreted for the FRAV virtual lines. Its value must be included between 0 and 7. A DLCI of the "FRIP" type has a value 6 and a DLCI of the "FRT" type has a value 4;

• [CIR], [Bc], [Be], [CIR_min] and [strategy] must be filled in consistently with respect to the field value [cos], as is detailed in the chapter below;

• [distant_address] is the address of the local correspondent or of the distant correspondent associated with the DLCI. This address is meaningful for the FRAV DLCIs liable to make a call or to check the address of a caller (establishing_mode
  
  4 and 6). It generally has a meaning for the LV FRI (profiles 86 to 89) for which it indicates the direction of the distant node (multiplexing of calls to the same DLCI in the FR network).

Management of COS and QOS fields

Location of QOS configuration

The principle here again is that of positioning the QOS of a DLCI (CIR, strategy etc.) on the user end. The exceptions are when the user is a Protocol P that is not FR (X25, FRAD, ...) and wishes to go out over a public FR network (DTE) or when the DLCI is of the FRI type). In this case, the QOS is configured on the network end.

Control rules

The interpretation of the configured values of CIR, CIR_min, Bc, Be and strategy is connected to the value assigned to the COS (Class Of Service) field.

* COS VBR-TR (1)

The other CIR, CIR_min, Bc,Be, strategy parameters are not significant. However, if these parameters are configured, the values must belong to the authorized range. Other wise, the DLCI is not initialized.

* cos VBR (0)

If the CIR is not configured, the DLCI will be activated without congestion management.

If the values of the CIR,CIR min,Bc,Be parameters are not included between 1 and 47, the DLCI will not be taken into consideration (EVR (significant event) config error). Depending on the CIR, Bc must be in a range of values. These values are described in Table 13-4. If the Bc is outside the range, it will be set to the value closet to the authorized range. Therefore, we have Bc < range => Bc= Bc min, Bc > range => Bc=Bc max. The CIR min must be less than the CIR, otherwise, CIR min = CIR.

When the CIR_min, Bc, Be, strategy parameters are absent, they are deduced from the rules: CIR_min=Bc=CIR; Be=2 * CIR. The default strategy is checking except as concerns the protocol FRI, for which the strategy is set during smoothing.

* cos UBR (2)

If the CIR is not configured, it is assimilated to a null CIR. All the other CIR values will be refused (EVR (significant event) configuration error). The CIR min and Bc parameters will not be significant. If Be is not configured then it will be at Be= U% line. The default strategy is that of checking except for the FRI protocol for which the strategy is forced on smoothing.

* cos not configured

By default, cos equals the value VBR.

Behavior associated with DLCI FRAV

The establishing mode of an FRAV (C32R1) station can take on different values which determine a more or less complex behavior in association with the DLCI :

• calling type (value 0);

• called type (value 1);

• mixed type (value 2);

• datagram type (value 3);

• called without caller check type (value 4 - FRT);

• datagram type managing NULL-Encapsulation (value 5);

• called type dynamically managing RFC1356 (value 6 - FRIP);

• the datagram type dynamically managing the RFC1490 (value 7);

* calling type (value 0)

• If the LMI is not configured, the equipment will transmit a call to the distant end as soon as the virtual line comes into service,

• If the LMI is configured:

  LMI UNI: the equipment waits for the Full Status Report with DLCI active to transmit the call,

  LMI NUI: The equipment waits for the line to switch to the available state, i.e. N393 correct exchanges.

* called type (value 1)

As soon as the virtual line is switched on (or the DLCI becomes available if the LMI is configured on the FR line) the station stands by to receive a call from the distant end and checks the caller address.

* mixed type (value 2)

Same behavior as for the calling type but enabling call collisions that is "recovers" by means of a random value call-back time-out.

* datagram type (value 3)

On reception of the first datagram after the virtual line is switched on (or the DLCI becomes available if the LMI is configured on the FR line), a call is emitted to the distant end. The first datagram received and the others that arrive during the setting up of the support CV are stored in an internal queue capable of holding up to datagrams. Beyond that, the datagrams are trashed and a loss EVR (significant event) is generated.

If a call is received from the distant end before the first datagram is received, it is processed in the same way as on the mixed type stations.

This mode can be used when the FR connection passes through a switched network. This can be a packet switching network (X25) or a circuit switching one (ISDN). This mode is capable of liberating the resources of this type of network in the absence of traffic.

Figure 13-6: Example

In this mode, the equipment will always indicate that it is in service for this DLCI on LMI polling.

* called without caller check type (value 4)

Type defined for TRANSPAC behaving like the called type except for the check of the caller address check which is not carried out.

It should be noted that a DLCI FRAV of this type offers the same functionality as the DLCI of an LV FRT.

* called type dynamically managing RFC1356 (value 6 - FRIP);

On reception of a call, the User Call Data (DAU) is analyzed. If it contains a valid RFC1356, encapsulation/decapsulation of the corresponding RFC1490 will b e implemented on all the datagrams.

If the DAU does not contain an RFC1356, the datagrams will be managed transparently.

Note that a DLCI of this type offers the same functionality as the DLCI of a virtual line LV FRIP.

* datagram type managing NULL-Encapsulation (value 5)

If the support CV has not already been established when the first datagram is received, it will be analyzed to check that it conforms to RFC1490 (byte 03). The emitted call DAU is then set to 00 (NULL encapsulation) and the null encapsulation is applied to all the datagrams.

If the datagram is not compliant with RFC1490 it will be managed transparently (empty DAU).

If a call is received before the first datagram is received, management will be as in the case of a "called with RFC" situation.

* datagram type dynamically managing RFC1490 (value 7)

If the support CV has not already been established when the first datagram is received, it will be analyzed to identify its RFC1490. The emitted call DAU then contains the corresponding RFC1356 and the appropriate encapsulation /decapsulation is applied to all the datagrams. If the datagram is not compliant with RFC1490 it will be managed transparently. If a call is received before the first datagram, management will be the same as for the "called with RFC".

---

Note The releasing of a PVC because of traffic absence is governed by the expiration of two inactivity time-outs: Ta followed by Tb. Ta can be configured in class 30 on profile 83 and thus by DLCI or block of DLCIs. Tb can be configured by line and therefore is valid for all the DLCIs. In the datagram mode, Ta is ignored and Tb is set to 1 if it is null.

---

Behavior associated with a DLCI FRI

For the connections based on DLCIs with a protocol in the SVC mode with multiplexing (in particular X25), there is no internal connection. Data transfer on this type of PVC takes place after the setup of an end to end connection between subscribers ( CV X25 for instance). However, this type of DLCI can be compared to a DLCI of the called type. If routing is on the physical line, it will be necessary to associate it with a called party address for this DLCI. This address must contain all the subscribers that can be connected through this PVC.

Example of X25 connection to a Frame Relay access:

Case where the virtual line is not assigned to the DLCI.

In the node Z0 configuration, the DLCI used for reaching subscribers to node Z1, will be referenced with address DNICZ1. The calls will first be routed over the physical line. Locally with respect to the line, the DLCI is chosen by comparison between the received called address and the address associated with the DLCI by configuration

Figure 13-7: Example

Class 9

Z1 -> line2

Z2 -> line2

Figure 13-8:
Example of PVC-attached PVC:

* FR_CE end (user)

C32R0 / 0 : 1,,901,0 cos VBR (0) on the DLCI 901 of line 1
R1 / 0 : ,,,1 LV of dynamic number described in C30R1 (Pr 83)
R2 / 0 : 6,,,,1 CIR called party = 6 (9600 bit/s); strategy = control
R3 / 0 : 900000020902 address to call to reach network DLCI
(sub-address = 0902 = DLCI output)

• profil
  
  e LV

C30R1 : 0,83 FRAV profile (without deltas)

• routing class 9 to subscriber: subscriber 02 -> line02

* FR_TE end (network)

C32R0 / 1 : 2,,902 DLCI 902 of line 2
R1 / 1 : ,,,1 LV of dynamic number described in C30R1
R2 / 1 : DLCI of called type without check by default
R3 / 1 : QOS expressed at user end (default values =FF)

Backup of a PVC by another PVC

The backup configuration can be obtained with or without the use of the notion of a virtual line.

Example of backup without the use of a virtual line.

In this case, the DLCI3 must be identified as a backup of DLCI2. To do so, DLCI3 is declared to be of the called type without checking and using as associated address: DNICZOLine2DLCI2 .

Figure 13-9:
Example of Back-Up Without the Use of a Virtual Line
Table 13-5: Backup of a PVC by Another PVC

Class 32	DLCI1 DLCI2
rec 0, parameter i : line1, ,DLCI1,priority	rec 0, parameter j : Line2 , ,DLCI2,priority
rec1, : ,0(calling), ,ind30n	rec1, : , 4, ,ind30m
rec2	rec2
rec3 : DNICZOLine2 DLCI2	rec3 :

DLCI3 backup

rec 0, parameter k : line2, ,DLCI3,priority

rec1, : ,4 (called without check), ,ind30i

rec2

rec3 : DNICZOLine2 DLCI2

Frame Relay and ISDN

The ISDN accesses support the PVC Frame Relay on channels B. ISDN can be used as a backup or as direct access to for the FR access points except for switch connections for PVC-PVC. The DLCI activated on channels B will depend on the ISDN address of the distant end. In the definition of the PVC FR, it is therefore necessary to associate an ISDN address with them through a class 22 index. On the establishing of a channel B. all the DLCIs with an associated ISDN corresponding to the ISDN address of the distant equipment will be activated.

Access to a DLCI on channels B, cannot be accomplished via the virtual line concept. Routing will be solely on channel D or in conjunction with the overflow backup function (GDL).

The behavior of the LMI on ISDN is optimized to shorted the DLCI availability detection time. The last polling is performed after one second. The following are carried out in accordance with T391. It is highly advisable to use the RAPID mode to detect the availability of the LMI DCLIs.

---

Note If it is incorrect, the line will only become available after N393 correct exchanges.

---

The backup service is offered for cases A and B.

Figure 13-10:
Back-Up Service is Offered for Cases A and B

Closing of channels B

Emergency shutdown

An emergency shutdown is possible using GDL when the line or the comes back into service. In the case of a PVC emergency shutdown, it is necessary to assign a virtual line to each PVC to be backed-up (see the example below).

Shutdown on inactivity

There are two channel B cutoff modes. Either cutoff on 0 CV, or cutoff due to traffic absence. The choice of behavior is made in class 12 associated with channel D (P60 or P76), but cutoff is still effective in the case of a backup or when the backed up subscribers are of the "datagram" type in that the necessary internal connection between the subscriber and the Frame Relay output is only requested on data reception. In addition, in the event of LMI being used, the polling frequency must be at least twice the inactivity surveillance period.

FR network access backup (case A)

Backup is on line or when the PVC is out of service. In both cases, all the DLCIs provided for on the ISDN are set up systematically.

If the backed-up PVC has the same properties when it is backed up on ISDN (same DLCI number and same protocol), a single DLCI declaration will suffice. Otherwise it will be necessary to configure the DLCI of the normal line and the backup DLCI on ISDN.

Examples case of connection to an FR network offering a backup service on ISDN

1/ One DLCI for the normal line and one for the backup line.

Declaration of DLCI2 on line2, backup by ISDN with the address NUMRNIS. The ISDN access is located on line3. The backup on ISDN uses the same DLCI number and the same properties (FRAV- transparent).

Figure 13-11:
Example

Class 1, rec 1

parameter line2 : 19 (line type = FR)

parameter line0 : 14 (line type = channel D)

parameter line1 : 15 (line type = channel B)

Class 12

rec line 2 : Profiles 84 or 85 (FRTE/FRCE)

rec line 3: Profile 47 (ISDN)

Class 32

rec 0, parameter i : line2,ind22,DLCI2,cos

rec1, : , , ,ind30i

rec2

rec3

Class 22

rec0, parameter ind22

rec1, parameter ind22 : NUMRNIS

rec2, parameter ind22: 70(incoming and outgoing call), ind30j , 19 (line type =FR)

Class 30

rec ind30i: profile 83 (FRAV)

rec ind30j: Profiles 84 or 85 (FRTE/FRCE)

Class 9

AB = line2 -> 4 (1+nbackup),2,0,line2,line0

2/ Two different DLCIs for the normal line and for the backup line DLCI 2 is backed up by DLCI3 on the ISDN access. Under these conditions two DLCIs must be defined. With respect to the previous example, The following configuration elements are changed:

Figure 13-12:
Configuration

Class 32

DLCI2: no reference to ISDN

rec 0, parameter i : line2, ,DLCI2,priority

rec1, : , , ,ind30i

rec2

rec3

DLCI0: line number not to be specified. However, DLCI0 must be identified as backup of DLCI2, hence the associated address of recurrence 3..

rec 0, parameter j : ,ind22,DLCI0, priority

rec1, : ,01(called type) , ,ind30i

rec2 rec3 : DNICZOLine2DLCI2

Class 22

rec0, parameter 22,

rec1, parameter ind22 : NUMRNIS

rec2, parameter ind 22: 70 (incoming and outgoing call), ind30j , 19 (line type =FR)

Class 30

rec ind30i: profile 83 (FRAV)

rec ind30j: Profiles 84 or 85 (FRTE/FRCE)

3) Emergency line shutdown

The following elements must be added to the previous examples:

Class 12

rec line2 P129 : ind22 P130 : 1 (emergency shutdown)

Class 9

AB= line2 -> 4(1+nbackup),3,0,line2,49 (GDL),line0

Backup of PVC (case B)

Examples PVC backup and backup shutdown

DLCI 2 and 0 of line 2 are backed up by ISDN. The backing up of DLCI2 uses the ISDN1 address and the backup of DLCI3 uses the ISDN2 address. To shut down the backup, assign a virtual line to each of these DLCIs. The DCLIs on the backed up line must be configured with shutdown of the backup and the DLCIs on ISDN without shutdown of the backup. It is necessary to declare the DLCIs on the backed up line and on the backup line because they do not have exactly the same properties.

Figure 13-13:
Example

Class 1, rec 1

parameter line2 : 19 (line type = FR)

parameter line0 : 14 (line type = channel D)

parameter line1 : 15 (line type = channel B)

Class 12

rec line 2 : Profiles 84 or 85 (FRTE/FRCE)

rec line 3: Profile 47 (ISDN)

Class 32

Table 13-6: DLCI on line 2

rec 0, parameter i : line2,,DLCI2,cos ec1, : LP1, , ,ind30i rec3 : DNICZ1 DLCI on line3 (ISDN) rec 0, parameter k: ,ind22k,DLCI2,prio ec1 : , , ,ind30k rec3 : DNICZ1	rrec 0 parameter j : line2,,DLCI3,cos ec1 :LV2 , , ,ind30j rec3 : DNICZ2 rec 0 parameter l : ,ind22l,DLCI3,prio rec1, : , , ,ind30k rec3 : DNICZ2

Class 30

(protocol on DLCIs)

rec ind30i Par 0 =86 (profile fri) Par 129= ind22k Par 130= 1 (backup off)

recind30j Par 0= 86 (profil fri) Par 129= ind22l Par 130= 1 (backup off)

recind30k Par 0= 86 (profile fri)

Class 22

(correspondence X25/RNIS,RTC)

rec0 Par ind22k DNICZ1 Par ind22l DNICZ2

rec1 Par ind22k RNIS1 Par ind22l RNIS2

rec2 Par ind22k 70,ind30k,19 Par ind22l 70,ind30k,19

Class 9

(routing) Z1 -> 4,3,0,LP1,49 (gdl), line0 (rnis)

Configuration of frame relay lines, type transit (FRSW) and connection VCX100

The following diagram gives the steps in the configuration process of a pair of transit frame relay types using the standard profiles.

Many additional parameters can be configured according to specific needs of the user. Details of the parameters are described in chapter 8.

The two lines to be configured must be on the same module.

• Use of VCX100 with FastPADmp/mpr

  FR connections reserved for voice must be of the VBR_TR type (Class 32). So as not to perturb the data, it is recommended that the size of frames should be limited.

  The recommended size for multiplex data transfer with voice is indicated in Table 13-7 according to the speed of the line. The longest non-priority lines can be destroyed.

Reminders:

• It is necessary to correctly update Parameter 28 in Class 12 on the type 19 frame relay line whatever the type of line (DCE or DTE). Otherwise, all the frames may be destroyed if the flow does not have priority.

• Network lines at a rate of 48 kbit/s are recommended for the use of VCX100

• Whatever the speed of the network line, the bandwidth used by the priority flow (VCX100) must be <30% of the total bandwidth.

Table 13-7: Table

Speed	Max Packet size in bytes
600 bit/s
1200 bit/s
2400 bit/s
9600 bit/s
14,4 kbit.s
19,2 kbit.s
38,4 kbit.s
48 kbit.s	128
56 kbit.s	128
64 kbit.s	128
72 kbit.s	256
128 kbit.s	512
144 kbit.s	512
256 kbit.s	1024
512 kbit.s	2048
1 Mbit.s	4096
2 Mbit.s	4096

Principle:

Absence of negotiation

Packet size

Parameter 61 = 0 class 30

Packet size

Parameters 62 and 63 class 30

This table is dimensioned for 32 byte voice frames every 20 ms with one voice channel.

Figure 13-14:
Configuration

Configuration of a HDLC or frame relay subscriber (FRA) line

The following diagram gives the steps in the configuration process of an HDLC or frame relay subscriber interface using the standard profiles.

Additional parameters can be configured according to specific needs of the user.

Details of the parameters are described in chapter 8.

Figure 13-15:
Configuration

Figure 13-16:
Line x HDLC or Frame Relay Subscriber (FRA)

Configuration of PVCs multiplexed on an FRTE interface

As these PVCs have no implicit physical output port, at least one frame relay line in class 1, recurrence 1 must be configured "19" (frame relay) enabling the routing tables to be configured in class 32.

The frame relay physical lines have an 84 profile (FR_TE) or 85 profile (FR_CE) defined in class 12.

In class 30, the connection parameters of each PLL are defined by means of profiles (see available profiles).

Figure 13-17:
Configuration
Figure 13-18:
Diagram

• Z01 - FastPADmp/mpr

  Lines 1 and 2 of any protocol are multiplexed on line 3. The two protocols are encapsulated in X.25 by means of the FRI function (virtual lines are to be chosen between 160 and 239).

• Z02 - FastPADmp/mpr

  On line 4, the two protocols P1 and P2 are received with two different DLCI numbers.

  For protocol P1, the DLCI number is declared as "connection", enabling the frame relay to return the frames in the upper layers (FRI).

  For protocol P2 the DLCI has been configured transit, enabling a fast passage of the frames through ZO1 for transmission on line 6.

• ZO3 - FastPADmp/mpr

  The DLCIs are of the connection type to enable the frames to be unpacked by the next software layers (FRI).

Figure 13-19:
Configuration
Figure 13-20:
Configuration
Figure 13-21:
Configuration

Example of FNA/FRA Configuration

Figure 13-22:
Example

C1R1

P4 = 21

line 4 = FRA

C12R4 \xde line 4

P0 = 83

FRA profile

P1 = 90,2

2 DLCIs (101 and 88)

P2 = 91,10

rest of description in C17R0 row 10

P3 = 92,2

LMI of NUI (Network to user) type and still of network type

C17R0

Figure 13-23:
C17R0

This local (AB SA) is used to format the address of the called in the call packet as follows:

Figure 13-24: Diagram

---

Note It is possible to choose to configure only a local (AB) in C17 with all the restrictions that this implies. The calling address in the call-request packet then has the following form:

---

Figure 13-25:
Diagram

C8R0

Figure 13-26:
C8R0

Example of configuration of C17 of machine 8000 20

C17R0

Figure 13-27:
C17R0
Figure 13-28: FRSNA example : Configuration of an SNA flow transport network on Frame Relay.

FastPADmp/mpr Configuration

1. Line L1: (See SNA/SDLC configuration in chapter 3.5.1).

2. Line L2: C1R1L2 = 19 frame relay

C1R12R2 = Profile 84 or 85

C32R0 po = 2,,1,

C32R1 po = 160,,,0

C30R0 = Profile 120

Encapsulation examples

First example:

Frame relay subscriber using FRI for encapsulation.

Figure 13-29:
Frame Relay Subscriber using FRI for Encapsulation

Figure 13-30: Encapsulation proposed on FR line: number of overhead bytes in parentheses.

FR (2)

Frame (2)

Packet (3)

SEP (FRA)

DATA

CRC

The SEP field of the multiframe protocol is negotiated between FRA. It is thus optional.

Second example:

Any subscriber using FRI for encapsulation.

Figure 13-31:
Any Subscriber using FRI for Encapsulation

Figure 13-32: Encapsulation proposed on FR line:

FR (2)

Frame (2)

Packet (3)

DATA

CRC

REMARKS

• 1 - In these two examples, the X.25 VC encapsulated in FR is established end to end between two network elements via the FRA protocol.

• 2 - In the following cases, the internal VC is established locally on each machine between the subscriber protocol (FRA, "P", SDLC, S.25, IP) and the protocol offered on the network interface (FRSNA, FRIP, FRT).

Third example:

Frame relay subscriber using FRT.

Figure 13-33:
Frame Relay Subscriber using FRT

Figure 13-34: Encapsulation proposed on FR line:

FR (2)

SEP (FRA)

DATA

CRC

Fourth example:

Any subscriber using FRT

Figure 13-35:
Any Subscriber using FRT

Figure 13-36: Encapsulation proposed on FR line:

FR (2)

DATA

CRC

Fifth example:

SDLC subscriber using FRSNA

Figure 13-37: SDLC Subscriber Using FRSNA

Figure 13-38: Encapsulation proposed on FR line:

FR (2)

LLC2

QLLC

DATA

CRC

Sixth example:

X.25 subscriber using FRSNA (MPSI)

Figure 13-39: X.25 Subscriber using FRSNA (MPSI)

Figure 13-40: Encapsulation proposed on FR line:

FR (2)

LLC2

QLLC

DATA

CRC

Seventh example:

LAN subscriber using FRIP.

Figure 13-41: LAN Subscriber Using FRIP

Figure 13-42: Encapsulation proposed on FR line:

FR (2)

RFC1490

DATA

CRC

REMARKS

• 1 - The FRI, FRSNA, FRIP and FRT protocols are represented by logic lines. As there may be several types of multiplexed protocols on a physical line, routing must be via the PVC ([65, 124] and [160, 239]) initialized in Class 32 Recurrence 1.

• 2 - ZO (DNIC ZO AB) to PVC of normal/backup line output. The supporting VC (internal or external) is established by means of the routing tables (C9...). The end of the PVC allows the remote node to be identified by means of the associated ZO number. It is thus recommended that calls be routed by configuring the ZO of the remote equipment.

Figure 13-43: Example
.

Example of routing table for PVC linking switch ZO = 00 with ZO = 01.

Routing table of switch 00:

• C9 R2 Pi = 01 (ZO 01 known).

• C9 R3 Pi = PLLv (PLL No. V to reach 01).

Routing table of switch 01:

• C9 R2 Pj = 00 (ZO 00 known).

• C9 R3 Pj = PLLv (No. V to reach 00).

When several PLLs use different protocols, it is recommended that these internal VCs be routed by using different ZOs (one ZO per PVC) or routing at the level of the AB.

Posted: Thu Jan 25 14:01:51 PST 2001
All contents are Copyright © 1992--2001 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.

---