At the heart of frame relay are permanent virtual circuits (PVCs) and data link connection identifiers (DLCIs).
You can think of a PVC as a virtual tunnel which links two points together, through which data passes and exits. They are logical, in that the data that crosses the PVC can take any route across the network, but to the end devices they go straight from one point to another. In addition, multiple PVCs can share the same physical media which allows you to have multiple PVCs terminate at the one physical interface.
The diagram below shows a number of PVCs used to connect R1 to R2, and R2 to R3. If R1 wishes to send data to R2, it will send it down the PVC that connects them together. Notice however that there is no PVC between R1 and R3 - this means that R1 must first send its data to R2 to be forwarded to R3, if R3 is the destination.
How does a device identify these PVCs? By using DLCIs. A DLCI is simply a number that represents the PVC, and is best thought of as a 'gateway' or next hop. Unlike Ethernet which has a source and destination address that is included in the header, frame relay devices send data to a DLCI because it can only exit at the other end of the PVC.
Going back to the diagram above, you will notice that if R1 wants to send data to R2, it sends it down the PVC identified by the DLCI 102 (think gateway). When it sends it, there is no source or destination as such in the header, because DLCI 102 only goes to one place. The header only has one DLCI value in it - 102. When it gets to the frame relay cloud, this number is removed and the cloud nows that you want to send this to R2 because that is where the PVC terminates.
When the frame pops out of the frame relay network and is on the last leg to R2, the DLCI is set to 201, because this identifies where it has come from. There is no need for a destination because R2 is the ONLY place it can go. If R2 wants to reply, it sends the data to DLCI 201 (think gateway), and it pops out at R1 as DLCI 102.
This brings us to an important point - DLCIs are only significant on the link between the routers and the frame relay cloud. As soon as the frame hits the cloud, the DLCI is stripped and the data sent onto the destination. In fact, the frame relay cloud may not even run frame relay and instead use something else such as ATM. With this in mind, we could have the DLCI at R1->R2 set to 102, and the DLCI for R2->R1 set to 102 also - it makes no difference to frame relay. The only time they cant be the same is at the same endpoint. For example the DLCI for R2->R1 and the DLCI for R2->R3 could NOT both be 102 because how would the cloud know whether you want to send stuff to R1 or R3?