In MPLS networks, a PE router is usually the entry point to the MPLS backbone, that’s also where the customers are connected. Incoming data from the customer facing interface are usually IP packets (in case of L3VPN), and layer-2 frames (in case of EVPN/L2VPN).
Regardless of the type of data a PE receives from the CE, this type of data has to be encapsulated by adding a Service Label generated and advertised by BGP to other PE neighbors. Additionally, a Segment-ID (SID) also known as Transport Label is added on top of the Packet for the purpose of packet forwarding in the MPLS backbone network. Packet forwarding in MPLS is different as it is purely based on the labels attached to the packets traversing the backbone network. Once a packet is labeled at the ingress point (PE), the end-to-end MPLS path is pretty much pre-defined, because core routers (P) only do label forwarding based on the incoming label without the need for an IP-lookup, that’s the beauty of label forwarding, isn’t it.
A label-stack plays a crucial role in MPLS networks, specifically for network devices that participate in label forwarding. As the name implies, a label-stack consists of one or more labels on it, regulated in a first-in-last-out fashion. That means any label sitting on top of the stack is the one to be processed first before moving to the next label down the stack. See the following picture.
If one wants to specify the end-to-end path explicitly, a label-stack is created by the network device, and instructions (labels) are pushed into it. If you have a large network, say thousands of MPLS / SR devices, at some point, you might run into label-stack limitations on particular router platforms (a known issue by network engineers and architects). To overcome this limitation, you might want to consider using a Segment Routing Binding-SID.
The Binding-SID (B-SID) is an SR segment that is associated with a specific service or function within the network. When a packet is sent through the network, the Binding-SID is used to identify the service or function (SR Policy) that the packet should be directed. It is used in conjunction with other SR segments, such as Prefix-SIDs and Node-SIDs, to create a path that directs traffic through the network. When a packet is received by a router with a B-SID as the top label, the node POPs (removes) it, and installs the related labels (SIDs) associated to that B-SID. A key benefit of the Binding-SID is its ability to support network services that span multiple domains or administrative boundaries, meaning that even in very large networks, you won’t be limited by the Label Stack of some of routing platforms. Remember, in an SP environment with thousands of core/edge nodes, you might specify and explicit path traversing 20 nodes as an example, now, this might not be possible with every network platform, as they might be limited to a max of e.g 10 Labels in the stack. With Binding-SID you can shorten the Label-Stack at the source router (R1) as can be seen from the picture below. R2 in this case, strips-off the B-SID and pushes a set of labels which correspond to that B-SID. This way, R1 could have been an older router which cannot support more than 5 labels, instead it uses the B-SID 3051 of R2. On the other side, R2 knows that any packet with a Top Label ‘3051’ must be POPed (removed) and a new set of transport labels (SIDs) must be imposed.
There are several other technical details to consider when implementing Binding-SID in an SR network. By default, the Binding-SID is dynamically allocated, which means that a SR-TE enabled network device automatically assigns a unique identifier to each Binding-SID. Of course, this means only when a SR-Policy is configured on the device. It is also possible to explicitly specify a Binding-SID, and I believe this is necessary in order to have properly planned SR-TE architecture. This can be useful in scenarios where the network operator needs to control the assignment of identifiers or wants to ensure that a particular identifier is used.
In some cases, you can also allocate Binding-SIDs to RSVP-TE tunnels, but why would you use RSVP-TE in the first place.
B-SID is also useful for isolating irregularities between different network domains. That means any link or node failure in a domain might re-advertise a different SID (label); however, the source PE which uses a B-SID of another domain, doesn’t have to react to that change, as the B-SID stays the same for the source PE, it’s only the ABR which advertises that B-SID the one that needs to perform the necessary changes in terms of refreshing the label-stack mapped to that specific B-SID.
Categories: General Networking
Leave a Reply