Forwarding Labeled Packets.
Label Operations.
The possible label operations are swap,push, and pop.
By looking at the top label of the received labeled packet and the corresponding entry in the LFIB, the LSR knows how to forward the packet. The LSR determines what label operation needs to be performed ,and what the next hop is to which the packet needs to be forwarded.
IP Lookup Versus Label Lookup
When a router receives an IP packet, the lookup done is an IP lookup. In Cisco IOS, this means that the packet is looked up in the CEF table. When a router receives a labeled packet, the lookup is done in the LFIB of the router. The router knows that it receives a labeled packet or an IP packet
by looking at the protocol field in the Layer 2 header.
If an ingress LSR receives an IP packet and forwards it as labeled, it is called the IP-to-Label forwarding case.
If an LSR receives a labeled packet, it can strip off the labels and forward it as an IP packet, or it can forward it as a labeled packet. The first case referred to as the label-to-IP forwarding case; the second is referred to as the label-to-label forwarding case.
In Cisco IOS, CEF switching is the only IP switching mode that you can use to label packets. Other IP switching modes , such as fast switching, cannot be used, because the fast switching cache does not hold information on labels.
To see all the labels that change on an already labeled packet, you must use the show mpls forwarding-table [network {mask|lenght}] [detail] command.
If the detail keyword is specified, you can see all the labels that change in the label stack. Without the detail keyword, you see only the pushed label.
When you perform an aggregation (or summarization) on an LSR, it advertises a specific label for the aggregated prefix, but the outgoing label in the LFIB shows "Aggregate". Because this LSR is aggregating a range prefixes, it cannot forward an incoming labeled packet by label-swapping the top label. The outgoing label entry showing "Aggregate" means that the aggregating LSR needs to remove the label of the incoming packet and must do an IP lookup to determine the more specific prefix to use for forwarding this IP packet.
You know now how the labeled packet is forwarded to a specific next hop after a label operation. The CEF adjacency table, however , determines the outgoing data link encapsulation. The adjacency table provides the necessary Layer 2 information to forward the packet to the next-hop LSR.
Label Operations Recap:
- Pop: The top label is removed. The packet is forwarded with the remaining label stack or as an unlabeled packet.
- Swap: The top label is removed and replaced with a new label.
- Push: The top label is replaced with a new label (swapped), and one or more labels are added (pushed) on top of the swapped label.
- Untagged/No label: The stack is removed, and the packet is forwarded unlabeled.
- Aggregate: The label stack is removed, and an IP lookup is done on the IP packet.
Load Balancing Labeled Packets.
If multiple equal-cost paths exist for an IPv4 prefix, the Cisco IOS can load-balance labeled packets.
If labeled packets are load-balanced, they can have the same outgoing labels, but they can also be different. The outgoing labels are the same if the two links are between a pair of routers and both links belong to the platform label space. If multiple next-hop LSRs exist, the outgoing label for each path is usually different, because the next-hop LSRs assign labels independently.
If a prefix is reachable via a mix of labeled and unlabeled (IP) paths, Cisco IOS does not consider the unlabeled paths for load-balancing labeled packets.That is because in some cases, the traffic going over the unlabeled path does not reach its destination. In the case of plain IPv4-over-MPLS (MPLS running on an IPv4 network), the packets reach the destination even if they become unlabeled.
At the place where the packets become unlabeled, an IP lookup has to occur. Because the network is running IPv4 everywhere, it should be able to deliver the packet to its destination without a label.However, in some scenarios, as with MPLS VPN or Any Transport over MPLS (AToM) , a packet that becomes unlabeled in the MPLS network at a certain link does not make it to its final destination.
In MPLS VPN, the MPLS payload is an IPv4 packet, but the P routers do not normally have the VPN routing tables, so they cannot route the packet to its destination.
In the case of AToM, the MPLS payload is a Layer 2 frame; therefore, if the packet loses its label stack on a P router, the P router does not have the Layer 2 forwarding tables present to forward the frame further. This is why in an MPLS network labeled packets are not load-balanced over IP and a Labeled path.
Unknown Label.
It is possible for something to go wrong in the MPLS network and the LSR to start receiving labeled packets with a top label that the lSR does not find in its LFIB. The LSR can theoretically try two things: strip off the labels and try to forward the packet, or drop the packet. The Cisco LSR drops the packet.
Reserved Labels
Labels 0 through 15 are reserved labels. An LSR cannot use them in the normal case for forwarding packets.
Label 0 is the explicit NULL label, whereas label 3 is the implicit NULL label. Label 1 is the router alert label, whereas label 14 is the OAM alert label. The other reserved labels between 0 and 15 have not been assigned yet.
Implicit NULL label.
The implicit NULL label is the label that has a value of 3. An egress LSR assigns the implicit NULL label to a FEC if it does not want to assign a label to that FEC, thus requesting the upstream LSR to perform a pop operation.
In the case of a plain IPv4-over-MPLS network, such as an IPv4 network in which LDP distributes labels between the LSRs, the egress LSR Running Cisco IOS assigns the implicit NULL label to its connected and summarized prefixes.The benefit of this is that if the egress LSR were to assign a label for these FECs, it would receive the packets with one label on top of it. It would then have to do two lookups. First, it would have to look up the label in the LFIB, just to figure out that the label needs to be removed; then it would have to perform an IP lookup. THese are two lookups, and the first is unnecessary.
The solution for this double lookup is to have the egress LSR signal the last but one (or penultimate) LSR in the label switched path (LSP) to send the packet without a label. The egress LSR signals the penultimate LSR to use implicit NULL by not sending a regular label, but by sending the special label with value 3. The result is that the egress LSR receives an IP packet and only needs to perform an IP lookup to be able to forward the packet. This enhances the performance on the egress LSR.
The use of implicit NULL at the end of an LSP is called penultimate hop popping (PHP).
The LFIB entry for the LSP on the PHP router shows a "Pop Label" as the ooutgoing label.
Explicit NULL label.
The use of implicit NULL has one downside: The packet is forwarded with one label less than it was received by the penultimate LSR or unlabeled if it was received with only one label.Besides the label value, the label also holds the Experimental (EXP) bits. When a label is removed, the EXP bits are also removed. Because EXP bits are exclusively used for QoS, the QoS part of the packet is lost when the top label is removed.
The explicit NULL label is the solution to this problem, because the egress LSR signals the IPv4 explicit NULL label (value 0) to the penultimate hop router. the egress LSR then recives labeled packets with a label of value 0 as the top label. The LSR cannot forward the packet by looking up the value 0 in the LFIB because it can be assigned to multiple FECs. The LSR just removes the explicit NULL label. After the LSR removes the explicit NULL label, another lookup has to occur, but the advantage is that the router can derive the QoS information of the recieved packet by looking at the EXP bits of the explicit NULL label.
You can copy the EXP bits value to the precedence or DiffServ bits when performing PHP and this preserve the QoS information. Or, if the label stack has multiple labels and the top label is popped off, you can copy the EXP bits value to the EXP fiield of the new top label.
Router Alert Label.
The router Alert label is the one with value 1. This label can be present anywhere in the label stack except at the bottom. When the router alert label is the top label, it alerts the LSR that the packet needs a closer look. Therefore, the packet is not forwarded in hardware, but it is looked at by a software proccess.
OAM Alert label
The label with value 14 is the Operational and Maintenance (OAM) Alert label as described by the ITU-T Recommendation Y.1711 and RFC 3429. OAM is basically used for failure detection, localization, and performance monitoring. This label differentiates OAM packets from normal user data packets. Cisco IOS does not use label 14. It does performs MPLS OAM, but not by using label 14.
Unreserved Labels
Except for the reserved labels of O through 15, you can use all the label values for normal packet forwarding.
In Cisco IOS, the default range is 16 through 100,000.
You can change the label range with the mpls label range min max command.
TTL Behaviour of Labeled Packets.
With the introduction of MPLS, labels are added to IP packets. this calls for a mechanism in which the TTL is propagated from the IP header into the label stack and vice versa.
TTL behavior in the Case of IP-to-Label or Label-to-IP.
When an IP packet enters the MPLS cloud such as on the ingress LSR the IP TTL value is copied (after being decremented by 1) to the MPLS TTL values of pushed label.At the egress LSR, the label is removed , and the IP header is exposed again. The IP TTL value is copied from the MPLS TTL value in the recieved top label after decrementing it by 1.
In Cisco IOS, however, a safeguard guards against possible routing loops by not copying the MPLS TTL to the IP TTL if the MPLS TTL is greater than the IP TTL of the received labeled packet.
TTL behavior in the Case of Label-to-Label.
- If the operation that is performed on the labeled packet is a swap, the TTL of incoming label -1 is copied to the swapped label.
- If the operation that is performed on the labeled packet is to push one or more labels, the received MPLS TTL of the top label -1 is copied to the swapped label and all pushed labels.
- If the operation is pop, the TTL of the incoming label -1 is copied to the newly exposed label unless that value is greater than the TTL of the newly exposed label, in which case the copy does not happen.
The intermeidate LSR does not change the TTL field in underlying labels or the TTL field in the IP header. An LSR only looks at or only changes the top label in the label stack of a packet.
TTL Expiration
When a labeled packet is received with a TTL of 1, the receiving LSR drops the packet and sends an ICMP message "time exceeded" (type 11, code 0) to the originator of the IP packet. However, the ICMP message is not immediately sent back to the originator of the packet because an interim LSR might not have an IP path toward the source of the packet. The ICMP message is forwarded along the LSP the original packet was following.
The reason for this forwarding of the ICMP message along the LSP that the original packet with the expiring TTL was following is that in some cases the LSR that is generating the ICMP message has no knowledge of how to reach the originator of the original packet.
It is important the the p router (LSR) where the TTL expires notes what the MPLS payload is. The P router checks whether the payload is an IPv4 (or IPv6) packet. If it is, it can generate the ICMP "time exceeded message and forward it along the LSP. However, if the payload is not an IPv4 (IPv6) packet, the P router cannot generate the ICMP message. Therefore, the P router drops the packet in all cases, exept if it is an IPv4(IPv6) packet. A case in which the LSR drops a packet with the TTL expiring is AToM.
MPLS MTU.
Data links in MPLS networks have a specific MTU, but for labeled packets. Take the case of an IPv4 network implementing MPLS. All IPv4 packets have on or more labels. This does imply that the labeled pakcets are slightly bigger than the IP packets, because for every label, four bytes are added to the packet. So, if n is the number of labels, n*4 bytes are added to the size of the packet when the packet is labeled.
MPLS MTU Command.
The interface MTU command in Cisco IOS specifies how big a Layer 3 packet can be without having to fragment it when sending it on a data link.
Cisco IOS has the mpls mtu command that lets you specify how big a labeled packet can be on a data link. If , for example, you know that all packets that are sent on the link have a maximum of two labels and the MTU is 1500 bytes, you can set the MPLS MTU to 1508 (1500 + 2*4). Thus, all labeled packets of size 1508 bytes (labels included) can be sent on the link without fragmenting them. The default MTU value of a link equals the MTU value.
Giant and Baby Giant Frames.
When a packet becomes labeled, the size increases slightly. If the IP packet was already at the maximum size possible for a certain data link (FUll MTU), it becomes too big to be sent on that data link becuse of the added labels. Therefore, the frame at Layer 2 becomes a giant frame. Because the frame is only slightly bigger than the maximum allowed, it is called a baby giant frame.
MPLS Maximum Receive Unit.
Maximum receive unit (MRU) is a parameter that Cisco IOS uses. It informs the LSR how big a received labeled packet of a certain FEC can be that can still be forwarded out of this LSR without fragmenting it.This value is actually a value per FEC (or prefix) and not just per interface. The reason for this is that labels can be added to or removed from a packet on an LSR.
The label operation plays a role in determining the MRU. Because the label operation is determined per FEC or prefix, the MRU can change per FEC or prefix.
Fragmentation of MPLS packets.
If an LSR receives a labeled packet that is too big to be sent out on a data link, the packet should be fragmented. This is similar to fragmenting an IP packet. If a labeled packet is received and the LSR notices that the outgoing MTU is not big enough for this packet, the LSR strips off the label stack, fragments the IP packet,puts the label stack (after the pop,swap,or push operation) onto all fragments, and forwards the fragments. Only if the IP header has the Don`t Fragment (DF) bit set does the LSR not fragment the IP packet, but it drops the packet and returns an ICMP error message "Fragmentation needed and do not fragment bit set" (ICMP type 3, code 4). to the originator of the IP packet.
Path MTU Discovery
A Method to avoid Fragmentation , which most modern IP hosts perform automatically. In That case, the IP packets sent out have the "Don`t Fragment" (DF) bit set. When a packet encounters a router that cannot forward the packet without fragmenting it, the router notices tha the DF bit is set, drops the packet, and sends an ICMP error message (ICMP type 3, code 4) to the originator of the IP packet. THe originator of the IP packet then lowers the size of the packet and retransmits the packet. if a problem still exists, the host can lower the size of the paket again. This continues until no ICMP message is received for the IP packet. The size of the last IP packet successfully sent is then used as maximum packet size for all subsequent IP traffic between the specifics source and destination; hence, it is the MTU of the path.
No comments:
Post a Comment