MPLS using LDP and ATM VC Switching
Extracted elements (30)
A shim header is required even for single-label packets transmitted on LC-ATM interfaces because without it there would be no way to determine whether additional label stack entries are present. While two VCs per FEC or a priori knowledge could eliminate the overhead, these techniques have no practical utility.
Downstream-on-demand label distribution was selected for ATM-LSRs because multipoint-to-point VCs are generally not supported, making it impossible for a non-VC-merge ATM switch to receive packets on multiple incoming VCIs and forward them on a single outgoing VCI. Each upstream request therefore requires a unique incoming label.
The LDPV path vector mechanism detects loops more quickly than the hop count mechanism but at a higher cost in overhead. If LDPV is not enabled, loops are still detected via the MAXHOP hop count mechanism, albeit more slowly. By only sending path vectors when hop count increases, unnecessary overhead is avoided when no loop is present.
A single device may behave as an ATM-LSR with respect to certain interface pairs and as a frame-based LSR with respect to others (e.g., an ATM switch with an Ethernet interface). The two functions may be considered coresident in a single box.
An ATM switch may coexist with the ATM Forum/ITU control component (UNI, PNNI) alongside the label switching control component (ships in the night). The two control components operate independently, sharing only information such as the partitioning of the VPI/VCI space.
A non-VC-merge ATM-LSR configured for LDPV MUST include a path vector object in requests it sends to its next hop: either propagating and extending the received path vector, or creating one containing only its own address if no path vector was received.
A VC-merge-capable ATM-LSR configured for LDPV MUST include a path vector in upstream binding responses when informing neighbors of an increased hop count, it is not the LSP egress, and it supports VC-merge. An LSR SHOULD NOT store path vectors once the corresponding object has been transmitted.
A VC-merge-capable ATM-LSR MUST issue a new binding every time it receives a request from upstream, since there may be switches upstream which do not support VC-merge. However, it only needs to issue a downstream binding request if it does not already have a label binding for the appropriate route.
A VPI/VCI value whose VCI part is in the range 0-32 inclusive MUST NOT be used as the encoding of a label. The default VPI/VCI for the non-MPLS connection is VPI 0, VCI 32 on direct connections.
An ATM-LSR or Edge LSR that receives multiple binding requests for the same FEC from the same ATM-LSR MUST generate a new binding for each request (assuming adequate resources), retain any existing bindings, and MUST also generate a new binding request toward the next hop for each received request.
An ATM-LSR SHOULD use split-horizon when satisfying binding requests: if the LSR making a request for a particular FEC is, according to this ATM-LSR, the next hop for that FEC, it should not return a binding for that route.
Downstream-on-demand label distribution MUST be used by ATM-LSRs that do not support VC-merge. ATM-LSRs that do support VC-merge MAY also use this technique.
Every ATM-LSR MUST implement, as a configurable option, the Loop Detection via Path Vectors (LDPV) procedure. If an LSR receives a label binding request whose path vector object contains its own address, it MUST act as it would if the hop count exceeded MAXHOP.
If a hop count has been associated with the label binding used for forwarding, the outgoing TTL is set to the larger of 0 or the difference between the incoming TTL and the hop count. If no hop count is associated, the outgoing TTL is set to the larger of 0 or one less than the incoming TTL.
If TTL adjustment causes the outgoing TTL to become zero, the packet MUST NOT be transmitted as a labeled packet using the specified label. The packet may be treated as having expired (possibly generating an ICMP message) or forwarded as an unlabeled packet with TTL decremented by one over a non-MPLS connection.
If two LDP peers are connected via an LC-ATM interface, a non-MPLS connection capable of carrying unlabeled IP packets MUST be available. This connection MUST use the LLC/SNAP encapsulation of RFC 2684 and is used to carry LDP packets between the two peers.
Labeled packets MUST be transmitted using the null encapsulation defined in Section 6.1 of RFC 2684 on LC-ATM interfaces.
The hop count field in a label binding request that an ATM-LSR sends to the next hop MUST be set to one more than the hop count it received from the upstream LSR. If the resulting hop count exceeds MAXHOP, the request MUST NOT be sent to the next hop, and the ATM-LSR MUST notify the upstream neighbor that its binding request cannot be satisfied.
When a LSR loses its LDP session with another LSR, any binding information learned via that connection MUST be discarded. For bindings created as a result of requests from the peer, the LSR MAY destroy these bindings and deallocate associated labels.
When a routing calculation causes an ATM-LSR to change the next hop for a FEC, it MUST notify the former next hop via LDP that the label binding associated with the FEC is no longer needed. When an ATM-LSR destroys a binding, it MUST notify the next hop for the FEC that the binding is no longer needed.
When a VC-merge-capable ATM-LSR sends a label binding upstream, the hop count from the downstream binding MUST be incremented by 1 and transmitted upstream. A hop count of 0 MUST be passed upstream unchanged, and if the hop count is already at MAXHOP, the ATM-LSR MUST NOT pass a binding upstream but instead MUST send an error upstream.
When two LSRs are connected via an ATM Virtual Path, the VPI field is not available to MPLS, and the label MUST be encoded entirely within the VCI field.
A label switching controlled ATM (LC-ATM) interface is an ATM interface controlled by the label switching control component. Packets received on such an interface are treated as labeled, with the top label inferred from the VCI field or the combined VPI/VCI fields, as negotiated via LDP.
An ATM-LSR is a Label Switching Router with LC-ATM interfaces that forwards cells between those interfaces using labels carried in the VCI or VPI/VCI field, without reassembling cells into frames before forwarding.
MAXHOP is a maximum hop count value with a default of 255 that may be configured to a different value. It is used in all ATM-LSR label distribution to detect and break forwarding loops when the optional LDPV procedure is not in use.
VC-merge is the process by which a switch receives cells on several incoming VCIs and transmits them on a single outgoing VCI without causing cells of different AAL5 PDUs to become interleaved. Most ATM switches do not support this capability.
The encapsulation and procedures specified in this document do not interfere with the application of authentication and/or encryption to network layer packets (e.g., IPsec applied to IP datagrams). Security considerations applicable to the label distribution mechanism are discussed in the LDP specification (RFC 3036).
The procedures described in this document do not protect against the alteration (accidental or malicious) of MPLS labels, which could cause misforwarding. Additionally, a receiving LSR has no mechanism to authenticate the transmitting LSR.
The packet's outgoing TTL and CoS are carried in the TTL and CoS fields respectively of the top stack entry in the shim header. Even a single-entry label stack requires a 4-byte single-entry shim to be present.
When a labeled packet is transmitted on an LC-ATM interface with VPI/VCI interpreted as the top label, the packet MUST also contain a shim header with n entries if the label stack has n entries. The actual top label value is encoded in the VPI/VCI field; the top shim entry is a placeholder whose label MUST be set to 0 on transmission and MUST be ignored on reception.