Use of Label Switching on Frame Relay Networks Specification
Extracted elements (28)
Both ordered and independent label distribution control modes are left as implementation or configuration choices, since each has advantages and disadvantages. In ordered control the FR-LSR waits for a downstream mapping before returning one upstream, propagating accurate hop counts; in independent control a binding is returned immediately using an 'unknown' hop count that is corrected later.
Frame Relay null encapsulation is used so that labels implicitly encode the network protocol type; no explicit protocol identifier field is carried in the label stack for Frame Relay encapsulated frames. This differs from generic MPLS shim header encapsulation which carries an explicit label value.
Frame Relay switches generally cannot perform TTL-decrement as IP routers do, making FR-LSR segments 'non-TTL segments.' To preserve end-to-end TTL semantics, the hop count of the non-TTL segment is propagated via LDP so that the ingress (unicast) or egress (multicast) FR-LSR can perform a bulk TTL decrement covering all hops in the segment.
In the absence of LDP or RSVP participation to set VC parameters, the default VC parameters should be zero CIR so that input policing sets the DE bit on incoming frames but no frames are dropped. This emulates a best-effort IP router as the default behavior for MPLS-controlled Frame Relay circuits.
A hybrid Frame Relay switch (Ships in the Night) can simultaneously run both the MPLS label switching control component and the ITU/Frame Relay Forum control component on the same switch and interfaces. The two control components operate independently; only the partition of DLCI space between them needs to be coordinated.
VC merging (label conservation) may be restricted when Frame Relay fragmentation is in use, because fragments of distinct frames must not be interleaved on the outgoing DLCI. Merging is only safe if the fragmenting FR-LSR guarantees in-sequence, non-interleaved transmission of all fragments of a given frame.
A FR-LSR that supports VC merging MUST ensure that fragmented frames arriving from distinct incoming DLCIs are not interleaved on the outgoing DLCI, as indicated by the Frame Relay Merge TLV in LDP.
FR-LSRs SHOULD operate on loop-free FR-LSPs or LSP Frame Relay segments. Therefore, FR-LSRs SHOULD use loop detection and MAY use loop prevention mechanisms as described in the MPLS architecture and LDP specifications.
The allowable ranges of DLCIs, the size of DLCIs (10 or 23 bits), and support for VC merging MUST be communicated through LDP messages between FR-LSR peers.
The downstream-on-demand label allocation and maintenance mechanism MUST be used by FR-LSRs that do not support VC merging; it MAY also be used by FR-LSRs that do support VC merging.
To support label switching, a Frame Relay switch MUST implement the label switching control component, consisting primarily of label allocation and maintenance procedures. The switch MUST also participate as a peer in network layer routing protocols (e.g., OSPF, IS-IS) since the control component uses routing information directly.
When an ingress FR-LSR determines that decrementing the MPLS TTL by the non-TTL segment hop count would expire the packet before it reaches the egress, the FR-LSR MUST NOT label switch the packet; instead it MUST treat the packet as expired and return an ICMP error or forward it as an unlabeled IP packet with appropriate TTL. If the incoming TTL is 1, only ICMP return applies.
When an LSR loses its LDP session with another LSR, it MUST discard any binding information learned via that connection. Label bindings created as a result of requests from the peer may be destroyed and their labels deallocated.
When sending a label binding upstream, the hop count associated with the corresponding downstream binding MUST be incremented by 1 before being transmitted upstream. If the resulting hop count exceeds the maximum value, the FR-LSR MUST NOT pass the binding upstream and MUST send an error upstream instead.
A core FR-LSR performs label switching by looking up the incoming DLCI in its DLCI Information Base and replacing it with the corresponding output DLCI, then forwarding on the outgoing interface — identical in mechanism to conventional Frame Relay VC switching. EXP, S, and TTL fields in the top label stack entry remain significant; the label value itself is carried in the DLCI.
A homogeneous LSP uses the same label stack encoding on every hop. A heterogeneous LSP uses different encodings on different hops (e.g., Frame Relay DLCI on one segment, Generic MPLS shim on another); each boundary LSR must decode the incoming encoding, operate on the label stack, and re-encode for the outgoing interface.
An egress FR-LSR pops the label stack. If the popped label is the last, the network layer protocol must be inferred from the label value (since null encapsulation carries no explicit protocol field). If it is not the last label, the previous top-level MPLS TTL is propagated to the new top entry.
An ingress FR-LSR pushes the MPLS label stack and sets TTL from the network layer TTL. For unicast, MPLS TTL SHOULD be decremented by the number of hops of the Frame Relay (non-TTL) segment; for multicast, TTL SHOULD be decremented by 1. The top label is passed to the Frame Relay data link driver as the output DLCI.
An LC-FR (label switching controlled Frame Relay) interface is a Frame Relay interface controlled by the label switching control component where packets carry labels in the DLCI field. A FR-LSR is an LSR with one or more LC-FR interfaces that forwards frames between such interfaces using DLCI-carried labels.
Edge LSR behavior: an edge LSR sends an LDP request to the downstream FR-LSR for a label binding; upon receiving the LDP mapping (which may include a hop count object), it stores the label as outgoing in the LIB and may begin MPLS forwarding. When it receives an LDP request from a FR-LSR, it is acting as egress: it allocates a label and returns a mapping with hop count set to 1.
The output TTL is computed as: output TTL = input TTL − D(ie, fe, oe), where D equals 0 for all-Frame-Relay encapsulation, 1 when forwarding or output encapsulation is Generic MPLS with Generic MPLS output, and 'number of hops of the LSP segment' when transitioning from a non-TTL segment to Frame Relay or IP output. A separate table applies for multicast.
Label distribution can be secured by applying authentication or encryption to the underlying protocol carrying label information (i.e., LDP). MPLS encapsulation itself has no effect on authenticated or encrypted network layer packets — such IP packets pass through unchanged.
The MPLS protocol has no mechanisms of its own to protect against misdirection of packets or impersonation of an LSR, whether by accident or malicious intent. Altering a label in the DLCI field or any field in the label stack affects forwarding of the frame.
The 2-octet Q.922 address encodes a 10-bit DLCI across two bytes with specific bit positions for DLCI high and low order bits, with bits 1-0 of octet 0 set to 0 and bit 0 of octet 1 set to 1 (EA bit). The 4-octet form encodes a 23-bit DLCI across four bytes, with bit 0 of the last octet set to 1.
The 'Frame Relay Label' LDP TLV is a 32-bit object containing: a Reserved field, a 2-bit Len field (0=10-bit, 2=23-bit DLCI), and a 23-bit DLCI value right-justified with preceding bits set to zero. It carries a specific Frame Relay label value in LDP label binding messages.
The 'Frame Relay Label Range' LDP TLV is a 64-bit object containing: a Reserved field, a 2-bit Len field (0=10-bit DLCI, 2=23-bit DLCI), a 23-bit Minimum DLCI, a Reserved field, and a 23-bit Maximum DLCI. It communicates the supported DLCI range and size from one FR-LSR to its LDP peer.
The 'Frame Relay Merge' LDP TLV is an 8-bit object with a 1-bit Merge field (0=merge not supported, 1=merge supported) and 7 reserved bits. It advertises VC merging capability between LDP peers.
The top MPLS label on a Frame Relay interface is carried in the DLCI field of the Q.922 data link header. The DLCI is encoded in canonical bit order and may be 10 bits (2-octet header) or 23 bits (4-octet header). Remaining label stack entries and EXP/S/TTL fields follow in a generic MPLS encapsulation immediately after the Q.922 address.