RFC 3035

MPLS using LDP and ATM VC Switching

📅 published January 2001, from ietf

MPLS using LDP and ATM VC Switching 🦋

Okay bestie, this is RFC 3035 💖, titled MPLS using LDP and ATM VC Switching ✨. It's a Standards Track document 🎀 dated January 2001 🌸, from the Network Working Group, so it's an official Internet standard, not just an opinion piece.

The authors are B. Davie, J. Lawrence, K. McCloghrie, E. Rosen and G. Swallow, all from Cisco Systems, Inc. 💅, plus Y. Rekhter from Juniper Networks 🧚 and P. Doolan from Ennovate Networks, Inc. 🫶. The header doesn't say it obsoletes or updates any other RFC, so it's standing on its own 👑.

   1      Introduction  ...........................................   2
   2      Specification of Requirements  ..........................   3
   3      Definitions  ............................................   3
   4      Special Characteristics of ATM Switches  ................   4
   5      Label Switching Control Component for ATM  ..............   5
   6      Hybrid Switches (Ships in the Night)  ...................   5
   7      Use of  VPI/VCIs  .......................................   5
   7.1    Direct Connections  .....................................   6
   7.2    Connections via an ATM VP  ..............................   7
   7.3    Connections via an ATM SVC  .............................   7
   8      Label Distribution and Maintenance Procedures  ..........   7
   8.1    Edge LSR Behavior  ......................................   8
   8.2    Conventional ATM Switches (non-VC-merge)  ...............   9
   8.3    VC-merge-capable ATM Switches  ..........................  11
   9      Encapsulation  ..........................................  12
   10     TTL Manipulation  .......................................  13
   11     Optional Loop Detection: Distributing Path Vectors  .....  15
   11.1   When to Send Path Vectors Downstream  ...................  15
   11.2   When to Send Path Vectors Upstream  .....................  16
   12     Security Considerations  ................................  17
   13     Intellectual Property Considerations  ...................  17
   14     References  .............................................  18
   15     Acknowledgments  ........................................  18
   16     Authors' Addresses  .....................................  18
   17     Full Copyright Statement  ...............................  20

Status of This Memo 📜

This document specifies an Internet standards track protocol for the Internet community 🌈, and it asks for discussion and suggestions for improvements 💬. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) ⭐. Distribution of this memo is unlimited 🎉.

Copyright (C) The Internet Society (2001). All Rights Reserved. 🔒

Abstract 🍓

So the Multiprotocol Label Switching (MPLS) Architecture [1] talks about how Asynchronous Transfer Mode (ATM) switches can act as Label Switching Routers 🧚. These ATM switches run regular network layer routing algorithms (like Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (IS-IS), etc.), and they forward data based on what those algorithms figure out 🗺️. No ATM-specific routing or addressing is needed, which is honestly iconic 💅. ATM switches used this way are called ATM-LSRs (Label Switching Routers) ✨.

This document extends and clarifies the relevant parts of [1] and [2]. It goes into much more detail on how labels get distributed to or from ATM-LSRs 📦, when those labels stand for Forwarding Equivalence Classes (FECs, see [1]) whose routes get picked hop by hop by network layer routing algorithms 🦋.

This document also specifies the MPLS encapsulation used when sending labeled packets to or from ATM-LSRs, and in that way it's a companion document to [3] 🎀.

1. Introduction 🌸

The MPLS Architecture [1] covers how ATM switches can be used as Label Switching Routers 💖. The ATM switches run network layer routing algorithms (like OSPF, IS-IS, etc.), and their data forwarding is based on what those algorithms produce 🧠. No ATM-specific routing or addressing is needed, and ATM switches used this way are known as ATM-LSRs ✨.

This document extends and clarifies the relevant parts of [1] and [2]. It goes deeper on the procedures for distributing labels to or from ATM-LSRs, when those labels stand for Forwarding Equivalence Classes (FECs, see [1]) whose routes are chosen hop by hop by network layer routing algorithms 🗺️. The label distribution technique described here is called "downstream-on-demand" in [1] 🍓. This technique MUST be used by ATM-LSRs that are not capable of "VC merge" (defined in section 3) 🚨, and it is OPTIONAL for ATM-LSRs that are capable of VC merge 🫶.

This document does NOT specify the label distribution techniques to be used in the following cases 🙈:

  • the routes are explicitly chosen before label distribution begins, instead of being chosen on a hop-by-hop basis as label distribution proceeds,
  • the routes are intended to diverge in any way from the routes chosen by the conventional hop-by-hop routing at any time,
  • the labels represent FECs that consist of multicast packets,
  • the LSRs use "VP merge".

Further statements made in this document about ATM-LSR label distribution do not necessarily apply in these cases 💀.

This document also specifies the MPLS encapsulation used when sending labeled packets to or from ATM-LSRs, and in that way it's a companion document to [3] 🎀. The specified encapsulation is to be used for multicast or explicitly routed labeled packets as well 🌈.

This document uses terminology from [1] 📚.

2. Specification of Requirements 📝

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 💅✨.

3. Definitions 🧚

A Label Switching Router (LSR) is a device that implements the label switching control and forwarding components described in [1] 🔥.

A label switching controlled ATM (LC-ATM) interface is an ATM interface controlled by the label switching control component 🎀. When a packet comes through one of these interfaces, it gets treated as a labeled packet 🏷️. The packet's top label is inferred either from the contents of the VCI field or from the combined contents of the VPI and VCI fields 🔍. Any two LDP peers connected via an LC-ATM interface will use LDP negotiations to figure out which of these cases applies to that interface 🤝.

An ATM-LSR is an LSR with a bunch of LC-ATM interfaces that forwards cells between those interfaces 🦋. It uses labels carried in the VCI or VPI/VCI field, and it does this without reassembling the cells into frames first 🫧.

A frame-based LSR is an LSR that forwards complete frames between its interfaces 📦. Note that such an LSR may have zero, one or more LC-ATM interfaces 🌸.

Sometimes a single box acts as an ATM-LSR for certain pairs of interfaces but as a frame-based LSR for other pairs 🙃. For example, an ATM switch with an Ethernet interface may function as an ATM-LSR when it forwards cells between its LC-ATM interfaces, but it may function as a frame-based LSR when it forwards frames from its Ethernet interface to one of its LC-ATM interfaces 🎭. In cases like these, you can think of the two functions (ATM-LSR and frame-based LSR) as living together, coresident, in a single box 🏠.

An LC-ATM interface is meant to connect two ATM-LSRs, or to connect an ATM-LSR to a frame-based LSR 🔗. Using an LC-ATM interface to connect two frame-based LSRs is not considered in this document 🚫.

An ATM-LSR domain is a set of ATM-LSRs that are mutually interconnected by LC-ATM interfaces 🕸️.

The Edge Set of an ATM-LSR domain is the set of frame-based LSRs that are connected to members of the domain by LC-ATM interfaces 🌐. A frame-based LSR that is a member of the Edge Set of an ATM-LSR domain may be called an Edge LSR 👑.

VC-merge is the process where a switch receives cells on several incoming VCIs and transmits them on a single outgoing VCI, without causing the cells of different AAL5 PDUs to get interleaved 🧩.

4. Special Characteristics of ATM Switches 🔧

The MPLS architecture allows a lot of flexibility in LSR implementation 🌈, but an ATM-LSR is limited by the capabilities of its (possibly pre-existing) hardware and by restrictions on things like cell format, which are imposed by ATM standards 🧱. Because of these constraints, some special procedures are required for ATM-LSRs 🎀.

Some of the key features of ATM switches that affect how they behave as LSRs are 👀:

  • the label swapping function is performed on fields (the VCI and/or VPI) in the cell header, and this dictates the size and placement of the label(s) in a packet 🏷️,
  • multipoint-to-point and multipoint-to-multipoint VCs are generally not supported, which means most switches cannot support 'VC-merge' as defined above 😭,
  • there is generally no capability to perform a 'TTL-decrement' function like the one performed on IP headers in routers 🙅‍♀️.

This document describes ways of applying label switching to ATM switches that work within these constraints 💖.

5. Label Switching Control Component for ATM 🎛️

To support label switching, an ATM switch MUST implement the control component of label switching ✅. This consists primarily of label allocation, distribution, and maintenance procedures 🗂️. Label binding information is communicated by several mechanisms, most notably the Label Distribution Protocol (LDP) [2] 📡. This document imposes certain requirements on the LDP 📋.

This document considers only the case where the label switching control component uses information learned directly from network layer routing protocols 🧭. It's presupposed that the switch participates as a peer in these protocols (e.g., OSPF, IS-IS) 🤝.

In some cases, LSRs use other protocols (e.g., RSVP, PIM, BGP) to distribute label bindings 🍬. In those cases, an ATM-LSR would need to participate in these protocols too. However, these are not explicitly considered in this document 🙈.

Support of label switching on an ATM switch does NOT require the switch to support the ATM control component defined by the ITU and ATM Forum (e.g., UNI, PNNI) 🙌. An ATM-LSR may optionally respond to OAM cells 🫧.

6. Hybrid Switches (Ships in the Night) 🌙

The existence of the label switching control component on an ATM switch does not rule out supporting the ATM control component defined by the ITU and ATM Forum on that same switch and the same interfaces 🤹. The two control components, label switching and the ITU/ATM Forum defined one, would operate independently 🚢🌃.

How such a device operates is beyond the scope of this document 🙃. However, only a small amount of information needs to be consistent between the two control components, such as the portions of the VPI/VCI space that are available to each component 🎟️✨.

7. Use of VPI/VCIs ✨

okay so label switching works by attaching labels to Forwarding Equivalence Classes (FECs) and then using the label value to forward packets, including figuring out what the replacement label should be 🦋 see [1] for the full tea. In an ATM-LSR, the label lives in the VPI/VCI field. But when two ATM-LSRs are connected through an ATM "Virtual Path", it lives in the VCI field instead 🌸

Labeled packets MUST be sent using the null encapsulation, the one from Section 6.1 of RFC 2684 [5] 💅

Also, if two LDP peers are linked over an LC-ATM interface, there MUST be a non-MPLS connection that can carry unlabelled IP packets 🫶 That connection is for carrying LDP packets between the two peers. It MAY also be used (but doesn't have to be) for other unlabeled stuff, like OSPF packets. The LLC/SNAP encapsulation from RFC 2684 [5] MUST be used on that non-MPLS connection.

It SHOULD be possible to configure an LC-ATM interface with extra VPI/VCIs for carrying control info or unlabelled packets 🎀 When you do that, the VCI values MUST NOT be in the 0-32 range. Those can use the null encapsulation (Section 6.1 of RFC 2684 [5]) or the LLC/SNAP encapsulation (Section 5.1 of RFC 2684 [5]).

7.1. Direct Connections 💖

Two LSRs are "directly connected" over an LC-ATM interface if every cell one LSR sends out that interface reaches the other one, and there are no ATM switches between them 🧚

When two LSRs are directly connected via an LC-ATM interface, they jointly control how VPIs/VCIs get allocated on the link between them. They can agree to use the VPI/VCI field to encode a single label ✨

The default VPI/VCI for the non-MPLS connection is VPI 0, VCI 32. You can configure other values, as long as both parties know the configured value 💜

A VPI/VCI whose VCI part is in the range 0-32 inclusive MUST NOT be used as the encoding of a label. That's a hard no 🙈

Apart from those reserved values, the VPI/VCI values used in the two directions of the link MAY be treated as independent spaces 🌈

The allowable VCI ranges get communicated through LDP 📣

7.2. Connections via an ATM VP 🦋

Sometimes it's useful to treat two LSRs as adjacent (in some LSP) across an LC-ATM interface, even though the connection between them goes through an ATM "cloud" via an ATM Virtual Path 🌸 In this case the VPI field isn't available to MPLS, so the label MUST be encoded entirely within the VCI field. Main character energy for the VCI 🫶

Here, the default VCI for the non-MPLS connection between the LSRs is 32. You can configure other values, as long as both parties know the configured value. The VPI gets set to whatever is needed to make use of the Virtual Path 💅

A VPI/VCI whose VCI part is in the range 0-32 inclusive MUST NOT be used as the encoding of a label. Same rule, still iconic 💀

Other than those reserved values, the VPI/VCI values used in the two directions of the link MAY be treated as independent spaces ✨

The allowable VPI/VCI ranges get communicated through LDP. If more than one VPI is used for label switching, the allowable VCI range can be different for each VPI, and each range gets communicated through LDP too 🎀

7.3. Connections via an ATM SVC 🌙

Sometimes it may be useful to treat two LSRs as adjacent (in some LSP) across an LC-ATM interface, even though the connection between them goes through an ATM "cloud" via a set of ATM Switched Virtual Circuits 🫠

This document doesn't specify how to handle that case. You can find those procedures in [4] 📖 They let a VCID get assigned to each such VC, and they say how LDP can be used to bind a VCID to a FEC 🧚 The top label of a received packet would then be inferred (via a one-to-one mapping) from the virtual circuit the packet arrived on. There wouldn't be a default VPI or VCI value for the non-MPLS connection, so no default to fall back on 🙃

8. Label Distribution and Maintenance Procedures 🍓

This document covers "downstream-on-demand" label distribution (see [1]) as used by ATM-LSRs 💖 These label distribution procedures MUST be used by ATM-LSRs that don't support VC-merge, and they MAY also be used by ATM-LSRs that do support VC-merge. The procedures are a little different in the two cases, so we'll go through both scenarios one at a time 👑 First up is the behavior of members of the Edge Set of an ATM-LSR domain. These "Edge LSRs" aren't ATM-LSRs themselves, and they behave the same whether or not the domain has VC-merge capable LSRs in it ✨

8.1. Edge LSR Behavior 🌸

Picture a member of the Edge Set of an ATM-LSR domain. Say that, after its routing calculations, it picks an ATM-LSR as the next hop for a certain FEC, and that next hop is reachable via an LC-ATM interface 🦋 The Edge LSR uses LDP to request a label binding for that FEC from the next hop. The hop count field in that request is set to 1 (but check out the next paragraph, because it's not always 1 😭). Once the Edge LSR gets the label binding information, it can use MPLS forwarding procedures to send packets in the specified FEC, using the specified label as an outgoing label. (Or it can use the VPI/VCI that corresponds to the specified VCID as the outgoing label, if the VCID technique of [4] is being used.) 💅

Note: if the Edge LSR's previous hop is using downstream-on-demand label distribution to request a label from the Edge LSR for a particular FEC, and the Edge LSR isn't merging the LSP from that previous hop with any other LSP, and the request from the previous hop has a hop count of h, then the hop count in the request the Edge LSR issues should not be set to 1. It should be set to h+1 instead 🫶

The binding the Edge LSR receives may include a hop count, which is the number of hops a packet will take to cross the ATM-LSR domain when using that label 🌈 If the binding has a hop count, the ATM-LSR SHOULD adjust a data packet's TTL by that amount before sending the packet. Either way, it MUST adjust a data packet's TTL by at least one before transmitting it 💀 The procedures for doing that (for IP packets) are in section 10. The procedures for encapsulating the packets are in section 9 🎀

When a member of the Edge Set of the ATM-LSR domain gets a label binding request from an ATM-LSR, it allocates a label and sends back (via LDP) a binding containing that label to the peer that made the request. It sets the hop count in the binding to 1 ✨

When a routing calculation makes an Edge LSR change the next hop for a particular FEC, and the former next hop was in the ATM-LSR domain, the Edge LSR SHOULD notify that former next hop (via LDP) that the label binding for the FEC isn't needed anymore 🧹

8.2. Conventional ATM Switches (non-VC-merge) ✨

okay bestie, so when an ATM-LSR gets a label binding request (via LDP) for a certain FEC from a peer that's connected over an LC-ATM interface, it does three things 🫶

  • it allocates a label,
  • it requests (via LDP) a label binding from the next hop for that FEC;
  • it returns (via LDP) a binding containing the allocated incoming label back to the peer that originated the request.

For this procedure we define a maximum hop count value MAXHOP 🔥 MAXHOP has a default value of 255, but it can be configured to a different value. 🎀

The hop count field in the request the ATM-LSR sends to the next hop LSR MUST be set to one more than the hop count field in the request it got from the upstream LSR 💅 If the resulting hop count goes over MAXHOP, the request MUST NOT be sent to the next hop, and the ATM-LSR MUST notify the upstream neighbor that its binding request can't be satisfied 💀

Otherwise, once the ATM-LSR gets the binding from the next hop, it starts using that label 🦋

The ATM-LSR MAY choose to wait for the request to be satisfied from downstream before returning the binding upstream. This is a form of "ordered control" (as defined in [1] and [2]), specifically "ingress-initiated ordered control" 👑 In this case, as long as the ATM-LSR receives a hop count from downstream that's greater than 0 and less than MAXHOP, it MUST increment the hop count it received from downstream and MUST include the result in the binding it returns upstream ✨ However, if the hop count goes over MAXHOP, a label binding MUST NOT be passed upstream. Rather, the upstream LDP peer MUST be informed that the requested label binding can't be satisfied 🙈 If the hop count received from downstream is 0, the hop count passed upstream should also be 0. This indicates that the actual hop count is unknown 🌸

Alternatively, the ATM-LSR MAY return the binding upstream without waiting for a binding from downstream ("independent" control, as defined in [1] and [2]) 🧚 In this case, it specifies a hop count of 0 in the binding, which means the true hop count is unknown. The correct value for hop count will be returned later, as described below 💜

Note that an ATM-LSR, or a member of the edge set of an ATM-LSR domain, may get multiple binding requests for the same FEC from the same ATM-LSR 👀 It MUST generate a new binding for each request (assuming it has adequate resources to do so), and retain any existing binding(s). For each request received, an ATM-LSR MUST also generate a new binding request toward the next hop for the FEC 🫶

When a routing calculation causes an ATM-LSR to change the next hop for a FEC, the ATM-LSR MUST notify the former next hop (via LDP) that the label binding associated with the FEC is no longer needed 🍓

When a LSR gets a notification that a particular label binding is no longer needed, the LSR MAY deallocate the label associated with the binding, and destroy the binding. In the case where an ATM-LSR gets that notification and destroys the binding, it MUST notify the next hop for the FEC that the label binding is no longer needed 🌈 If a LSR does not destroy the binding, it may re-use the binding only if it receives a request for the same FEC with the same hop count as the request that originally caused the binding to be created. Main character energy, but make it precise 💅

When a route changes, the label bindings are re-established from the point where the route diverges from the previous route. LSRs upstream of that point are (with one exception, noted below) oblivious to the change 🦋

Whenever a LSR changes its next hop for a particular FEC, if the new next hop is reachable via an LC-ATM interface, then for each label it has bound to that FEC and distributed upstream, it MUST request a new label binding from the new next hop ✨

When an ATM-LSR receives a label binding for a particular FEC from a downstream neighbor, it may already have given a corresponding label binding for this FEC to an upstream neighbor. That can happen either because it's using independent control, or because the new binding from downstream is the result of a routing change 😭 In this case, unless the hop count is 0, it MUST extract the hop count from the new binding and increment it by one. If the new hop count is different from what was previously conveyed to the upstream neighbor (including the case where the upstream neighbor was given the value 'unknown'), the ATM-LSR MUST notify the upstream neighbor of the change. Each ATM-LSR in turn MUST increment the hop count and pass it upstream until it reaches the ingress Edge LSR 🚀 If at any point the value of the hop count equals MAXHOP, the ATM-LSR SHOULD withdraw the binding from the upstream neighbor. A hop count of 0 MUST be passed upstream unchanged 🫠

Whenever an ATM-LSR originates a label binding request to its next hop LSR because it got a label binding request from another (upstream) LSR, and the request to the next hop LSR is not satisfied, the ATM-LSR SHOULD destroy the binding it created in response to the received request, and notify the requester (via LDP) 🧸

If an ATM-LSR receives a binding request containing a hop count that exceeds MAXHOP, it MUST not establish a binding, and it MUST return an error to the requester 🚫

When a LSR determines that it has lost its LDP session with another LSR, these actions are taken. Any binding information learned via that connection MUST be discarded. For any label bindings that were created because the LSR got label binding requests from the peer, the LSR MAY destroy those bindings (and deallocate the labels associated with those bindings) 🥀

An ATM-LSR SHOULD use 'split-horizon' when it satisfies binding requests from its neighbors. That means if it receives a request for a binding to a particular FEC, and the LSR making that request is, according to this ATM-LSR, the next hop for that FEC, it should not return a binding for that route 🪞

It is expected that non-merging ATM-LSRs would generally use "conservative label retention mode" [1]. ✨

8.3. VC-merge-capable ATM Switches 🌟

Relatively minor changes are needed to accommodate ATM-LSRs that support VC-merge 💖 The main difference is that a VC-merge-capable ATM-LSR only needs one outgoing label per FEC, even if it gets multiple requests for label bindings to that FEC from upstream neighbors 🫧

When a VC-merge-capable ATM-LSR receives a binding request from an upstream LSR for a certain FEC, and it doesn't already have an outgoing label binding for that FEC (or an outstanding request for such a label binding), it MUST issue a bind request to its next hop, just like it would if it weren't merge-capable 🎀 If, however, it already has an outgoing label binding for that FEC, it doesn't need to issue a downstream binding request. Instead, it may simply allocate an incoming label and return that label in a binding to the upstream requester. When packets with that label as the top label are received from the requester, the top label value gets replaced with the existing outgoing label value that corresponds to the same FEC 🧚

If the ATM-LSR doesn't have an outgoing label binding for the FEC, but does have an outstanding request for one, it doesn't need to issue another request 🌈

When sending a label binding upstream, the hop count associated with the corresponding binding from downstream MUST be incremented by 1, and the result transmitted upstream as the hop count associated with the new binding. There are two exceptions though 🙃 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. Instead, it MUST send an error upstream 💀

Note that, just like conventional ATM-LSRs and members of the edge set of the ATM-LSR domain, 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 that don't support VC-merge 🫶 However, it only needs to issue a corresponding binding request downstream if it doesn't already have a label binding for the appropriate route 🍓

When a change in the routing table of a VC-merge-capable ATM-LSR causes it to select a new next hop for one of its FECs, it MAY optionally release the binding for that route from the former next hop. If it doesn't already have a corresponding binding for the new next hop, it has to request one. (Choosing between conservative and liberal label retention mode [1] is an implementation option 🧠)

If a new binding is obtained that contains a hop count different from the one received in the old binding, then the ATM-LSR has to take the new hop count, increment it by one, and notify any upstream neighbors that have label bindings for this FEC of the new value. Just like with conventional ATM-LSRs, this lets the new hop count propagate back towards the ingress of the ATM-LSR domain 🔁 If at any point the hop count goes over MAXHOP, then the label bindings for this route have to be withdrawn from all upstream neighbors that were previously given a binding. This makes sure any loops caused by routing transients get detected and broken 🔥

9. Encapsulation ✨

okay so this section only really affects the Edge LSRs of the ATM-LSR domain 💅 the ATM-LSRs themselves don't change the encapsulation in any way, not even a little 🫶

Labeled packets MUST be sent using the null encapsulation of Section 6.1 of RFC 2684 [5] 🎀

ngl there are exceptions (we'll get to them), but when a labeled packet goes out on an LC-ATM interface and the VPI/VCI (or VCID) is being read as the top label in the label stack, the packet MUST also carry a "shim header" [3] 🦋

If the packet has a label stack with n entries, it MUST carry a shim with n entries. The actual value of the top label lives in the VPI/VCI field. The label value of the top entry in the shim (which is just a "placeholder" entry) MUST be set to 0 when it's sent, and MUST be ignored when it's received. The packet's outgoing TTL and its CoS get carried in the TTL and CoS fields of the top stack entry in the shim 🌸

Note that if a packet has a label stack with only one entry, it still needs a single-entry shim (4 bytes), even though the actual label value is encoded in the VPI/VCI field. This is how we make sure the packet always has a shim 🧚 Otherwise there'd be no way to tell whether it had one or not, aka no way to know whether there are additional label stack entries. wild, right? 😭

The only ways to get rid of this extra overhead are:

  • through apriori knowledge that packets only have a single label (e.g., maybe the network only supports one level of label)
  • by using two VCs per FEC, one for packets that have only a single label, and one for packets that have more than one label

The second technique would need some way of signalling via LDP that the VC is carrying only packets with a single label and is not carrying a shim. When you're supporting VC merge, you'd also have to be careful not to merge a VC where the shim is not used into a VC where it is used, or vice versa 👀

Both of these techniques are allowed, but honestly it's doubtful they have any practical utility 💀 Also, if the shim header isn't present, the outgoing TTL gets carried in the TTL field of the network layer header 💖

10. TTL Manipulation

Same energy as before: this section only affects the Edge LSRs of the ATM-LSR domain. The ATM-LSRs themselves don't modify the TTL in any way 🌈

Here's how the TTL adjustment works ✨ If a packet reached the Edge LSR as an unlabeled packet, the "incoming TTL" comes from the IP header. (Procedures for other network layer protocols are for further study 🧐) If a packet reached the Edge LSR as a labeled packet, using the encapsulation specified in [3], then the "incoming TTL" comes from the entry at the top of the label stack.

If a hop count has been associated with the label binding that's used when the packet gets forwarded, the "outgoing TTL" is set to the larger of (a) 0 or (b) the difference between the incoming TTL and the hop count. If there's no hop count associated with the label binding used for forwarding, the "outgoing TTL" is set to the larger of (a) 0 or (b) one less than the incoming TTL 🍓

If this makes the outgoing TTL zero, the packet MUST NOT be sent as a labeled packet using the specified label. There are two ways the packet can be handled:

  • it may be treated as having expired; this may cause an ICMP message to be sent;
  • the packet may be forwarded as an unlabeled packet, with a TTL that is 1 less than the incoming TTL; such forwarding would need to be done over a non-MPLS connection.

Of course, if the incoming TTL is 1, only the first of those two options applies 🙈

If the packet is forwarded as a labeled packet, the outgoing TTL gets carried as specified in section 9.

When an Edge LSR receives a labeled packet over an LC-ATM interface, it gets the incoming TTL from the top label stack entry of the generic encapsulation. If that encapsulation isn't present, it takes it from the IP header instead 🫶

If the packet's next hop is an ATM-LSR, the outgoing TTL is formed using the procedures in this section. Otherwise, the outgoing TTL is formed using the procedures described in [3] 💅

Also, the procedures in this section are only meant to apply to unicast packets 🦋

11. Optional Loop Detection: Distributing Path Vectors 🌈

Every ATM-LSR MUST implement this, as a configurable option, the following procedure for detecting forwarding loops. We call it the LDPV (Loop Detection via Path Vectors) procedure. It doesn't stop forwarding loops from forming, but it does make sure any loops get detected. If this option is off, loops are detected by the hop count mechanism we covered earlier. If this option is on, loops get detected faster, but it costs more in overhead ✨

11.1. When to Send Path Vectors Downstream

Picture this: an LSR R sends a request for a label binding, for a particular LSP, to its next hop. If R doesn't support VC-merging, and R is configured to use the LDPV procedure, then:

  • If R is sending the request because it's an ingress node for that LSP, or because it has acquired a new next hop, then R MUST include a path vector object with the request, and the path vector object MUST contain only R's own address 🎀
  • If R is sending the request because it received a request from an upstream LSR, then:
    • if the received request has a path vector object, R MUST add its own address to the received path vector object, and MUST pass the resulting path vector object to its next hop along with the label binding request;
    • if the received request doesn't have a path vector object, R MUST include a path vector object with the request it sends, and the path vector object MUST contain only R's own address 🧚

An LSR that supports VC-merge SHOULD NOT include a path vector object in the requests it sends to its next hop 💜

If an LSR gets a label binding request whose path vector object contains the address of the node itself, the LSR concludes that the label binding requests have traveled in a loop 😱 It MUST act as it would in the case where the hop count exceeds MAXHOP (see section 8.2).

This procedure catches the case where request messages loop through a sequence of non-merging ATM-LSRs 🔥

11.2. When to Send Path Vectors Upstream

As specified in section 8, there are situations where an LSR R has to tell its upstream neighbors, via a label binding response message, about a change in hop count for a particular LSP. If all of the following conditions hold:

  • R is configured for the LDPV procedure,
  • R supports VC-merge,
  • R is not the egress for that LSP, and
  • R is not informing its neighbors of a decrease in the hop count,

then R MUST include a path vector object in the response message 🌸

If the change in hop count happened because R was told by its next hop, S, about a change in hop count, and the message from S to R included a path vector object, then (if the above conditions hold) R MUST add itself to that object and pass the result upstream. Otherwise, if the above conditions hold, R MUST create a new object with only its own address 💖

If R is configured for the LDPV procedure and supports VC merge, then it MAY include a path vector object in any label binding response message it sends upstream. Specifically, any time R gets a label binding response from its next hop and that response contains a path vector, R MAY (if configured for the LDPV procedure) send a response to its upstream neighbors containing the path vector object formed by adding its own address to the received path vector 🦋

If R doesn't support VC merge, it SHOULD NOT send a path vector object upstream 🙅‍♀️

If an LSR gets a message from its next hop with a path vector object containing its own address, then the LSR MUST act as it would if it had received a message with a hop count equal to MAXHOP 😭

LSRs configured for the LDPV procedure SHOULD NOT store a path vector once the corresponding path vector object has been sent 💅

Note that if the ATM-LSR domain is made up entirely of non-merging ATM-LSRs, path vectors never need to be sent upstream, since any loops will be caught by the path vectors traveling downstream 🌈

And by not sending path vectors unless the hop count goes up, you avoid sending them in tons of situations where there's no loop 🙌 The tradeoff is that in some loop situations, it may take longer to detect the loop 🥲

12. Security Considerations

The encapsulation and procedures in this document don't interfere in any way with applying authentication and/or encryption to network layer packets (like applying IPSEC to IP datagrams) 🔐

Heads up though: the procedures in this document do NOT protect against alteration of MPLS labels, whether it's accidental or malicious. That kind of alteration could cause misforwarding 🚨

The procedures in this document also do not let a receiving LSR authenticate the transmitting LSR 😬

For a discussion of the security considerations for the label distribution mechanism, check out [2] 👑

13. Intellectual Property Considerations

The IETF has been notified of intellectual property rights claimed for some or all of the specification in this document. For more information, consult the online list of claimed rights 📜

The IETF takes no position on the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on whether any license under such rights might or might not be available. It also doesn't say it has tried to identify any such rights. Info on the IETF's procedures for rights in standards-track and standards-related documentation can be found in BCP-11. Copies of rights claims made available for publication, any assurances of licenses to be made available, or the results of an attempt to get a general license or permission for implementers or users to use such proprietary rights can be obtained from the IETF Secretariat 💼

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to practice this standard. Send that info to the IETF Executive Director 💌

14. References 📚

okay so here's the bibliography, bestie 🧚 every doc this RFC leans on, all lined up:

  • [1] Rosen, E., Viswanathan, A. and R. Callon "Multi-Protocol Label Switching Architecture", RFC 3031, January 2001.
  • [2] Andersson L., Doolan P., Feldman N., Fredette A. and R. Thomas, "LDP Specification", RFC 3036, January 2001.
  • [3] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow, G., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
  • [4] Nagami, K., Demizu N., Esaki H. and P. Doolan, "VCID Notification over ATM Link for LDP", RFC 3038, January 2001.
  • [5] Grossman, D., Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999.

15. Acknowledgments 🫶

the people who helped make this happen are literally the realest 😭 Significant contributions came from Anthony Alles, Fred Baker, Dino Farinacci, Guy Fedorkow, Arthur Lin, Morgan Littlewood and Dan Tappan. We also thank Alex Conta for his comments 💖

16. Authors' Addresses 🌸

here's who wrote it and where you can find them 💅

Bruce Davie
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824

EMail: bsd@cisco.com


Paul Doolan
Ennovate Networks Inc.
60 Codman Hill Rd
Boxborough, MA 01719

EMail: pdoolan@ennovatenetworks.com
Jeremy Lawrence
Cisco Systems, Inc.
99 Walker St.
North Sydney, NSW, Australia

EMail: jlawrenc@cisco.com


Keith McCloghrie
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA, 95134

EMail: kzm@cisco.com


Yakov Rekhter
Juniper Networks
1194 N. Mathilda Avenue
Sunnyvale, CA 94089

EMail: yakov@juniper.net


Eric Rosen
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824

EMail: erosen@cisco.com


George Swallow
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824

EMail: swallow@cisco.com

last but not least, the legal stuff 🎀 it's not the most exciting read, but it's important, so here it is in full:

Copyright (C) The Internet Society (2001). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🍓

Funding for the RFC Editor function is currently provided by the Internet Society. Thank you to them, and thank you for sticking with me through all five parts, bestie 🦋✨

📦 where this page comes from