From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

OECG – Appendix C

1,275 Words. Plan about 8 minute(s) to read this.

While the earlier portion of the appendix discussed the concepts and drivers behind MPLS, the remainder of the appendix focuses on MPLS implementation and application. The first application is that of “frame-mode operation”, otherwise known as unicast destination-based IP routing in an all-router environment. This is called “frame-mode”, because the packets are switches as if they were layer 2 frames. The topics are broken up into discussions of the data plane (where we take for granted that labels have been agreed on by the touers); methods of distributing labels; and label distribution protocol interaction with IGPs and BGP. So to the strains of Verdi’s La Forza Del Destino Overture and Starbuck’s Breakfast Blend decaf brewing, let’s dive in.

Yes, I said decaf. So I like to sleep at night…get over it. ;-)

How does an IP packet make it’s way through an MPLS cloud in the context of frame-mode operations?

  • The ingress Edge-LSR receives a native IP packet. The LSR classifies the packet in a FEC, and then labels the packet appropriate for the FEC. In the case of frame-mode operations, the forward equivalence class (FEC) will be determined by the destination subnet. The classification will happen via a boring route table lookup. And if all that didn’t jive, let me restate it.
    • A packet shows up at the edge of the MPLS cloud.
    • The edge-LSR (the label switch router sitting at the edge of the MPLS cloud), gets that packet and has to forward it into the cloud. Well, this is not a plain IP cloud, where you can do a simple route-table lookup, and shoot the packet out the appropriate outgoing interface. Rather, this is an MPLS cloud. So the router has to take that IP packet and repackage it by sticking the appropriate MPLS label(s) on it.
    • Well, that’s wonderful. But how does the router know what MPLS label to put on the IP packet? He knows because the packet will belong to a specific FEC.
    • Well, that’s grand, too – how does the router know what FEC the packet is a member of? Ah. In the case of frame-mode (unicast routing) operations, the LSR knows what FEC the packet is a member of because of the destination IP of the packet. Different MPLS applications may determine FEC memberships in different ways.
    • So then – the router sees the destination IP, and assigns the appropriate FEC. Based on the FEC, an label is placed onto the outgoing label stack. The packet is then forwarded into the MPLS cloud.
  • The Core-LSR now receives this labeled packet coming inbound from the edge-LSR. Like an MLS switch needs to replace L2 source/destination MACs when forwarding a packet, the core LSR needs to exchange the incoming label (from the previous LSR that forwarded this MPLS packet) for a new outgoing label that corresponds to the same FEC. Once the core LSR has the shiny, new label on the packet, he forwards the packet to the next hop in the MPLS cloud.
  • Eventually, the packet will reach the egress Edge-LSR. At this point, the packet is leaving the MPLS cloud and is going back into normal IP-space. (“Shut down the warp engines, Scotty. Give me one-quarter impluse power.”) So the egress LSR will strip of the label, leaving himself with a regular IP packet. The LSR will then perform a traditional IP forwarding table lookup, and forward the IP packet appropriately.
  • Special note – MPLS operations in a Cisco-world requires CEF. MPLS operations require CEF both for use of the fowarding information base and for label allocation.

MPLS Label Stack Header – the layout, placement and other notables regarding the MPLS label.

  • MPLS labels are sometimes called “shim headers”, since they are tucked into the MPLS packet between the Layer2 and Layer 3 headers.
  • A single MPLS label is 32 bits long. Note that you can have more than one label in a packet, called a label stack.
    • Label – 20 bits (the label itself)
    • Class-of-service/Experimental – 3 bits (you might recall that this is the field used in QoS operations)
    • Bottom-of-stack – 1 bit (used when you have more than one label, creating a label stack; the bottom label in the stack will have this field set to “1”)
    • TTL – 8 bits (used for loop detection, just like the IP header TTL field)
  • A router receiving a packet needs a way to know that there’s an MPLS label to pay attention to. To that end, new protocol types have been defined to tell the router what exactly this packet is that it’s about to process.
    • LAN – ethertype 0x8847 (unicast) and 0x8848 (multicast). Used directly on ethernet media, and included as a part of the SNAP header on other LAN types such as Token Ring and FDDI.
    • Point-to-point links using PPP – an NCP called MPLS Control Protocol (MPLSCP). The PPP protocol field is marked with 0x8281.
    • Frame-relay – packets flowing through a DLCI are maked with a Frame Relay SNAP Network Layer Protocol NLPID, plus a SNAP header with ethertype 0x8847.
    • ATM – packets flowing through an ATM VC get a SNAP encapsulation using ethertypes equal to those in the LAN.

Label Switching in Frame-Mode MPLS – we’ve talked about the concept of forwarding across the MPLS cloud, and also looked at the MPLS label and protocol header changes made to support MPLS labels. Now we’ll look in more detail about the actual forwarding process, or “label switching” process.

  • A core router received a packet from another core router. The packet is identified as an MPLS packet by based on the protocol field.
  • The core router then does a lookup in the Label Forwarding Information Base (LFIB). The LFIB will tell the router something like “You got a packet with a label of 40. Okay, outbound, the label will be 38, and you’re going to forward it out interface X.”
  • When the packet gets to the egress edge, the LFIB will tell the router to “pop” the label, i.e. remove it, and forward it unlabeled.

Actions That Can Be Performed on a Labeled Packet

  • Pop tag – removing a label and forwarding whatever is left. If the removed label had a bottom-of-stack bit of “0”, that means the forwarded packet has one or more labels left in the stack. If the bottom-of-stack bit was “1”, that means that the removed label was the last in the stack, and that the forwarded packet is therefore unlabeled.
  • Swap tag – replace the top label in the stack with another one, i.e. the “tag stack” field in the LFIB is a single label.
  • Push tag – replace the top lable in the stack with a set of labels, i.e. the “tag stack” field in the LFIB is a number of labels.
  • Aggregate – remove the top label in the stack, then perform an L3 lookup of the underlying IP packet. And although this doesn’t make sense to me just at the moment, the book goes on to say that the removed label is presumably the bottom label, otherwise, the datagram is discarded. (Huh?)
  • Untag – remove the top label in the stack, then forward the underlying IP packet to the next-hop as identified in the LFIB. And like with “aggregate” above, the removed label is presumably the bottom label, otherwise, the datagram is discarded. (Huh?)

Label Switching with a Stack

  • Label switching functions the same with a stack as with a single label.
  • The LSR acts on the top label in the stack, and ignores the others.
  • This allows for ingress and egress edge routers to agree on labels for a specific purpose, without the core routers needing to know that information.