Networks Horizon

share

Tuesday, 10 January 2012


Label Distribution Protocol (LDP)

Labels have to be distributed to build and maintain the LSR-databases. This is done by using the Label Distribution Protocol (LDP). This protocol is a kind of protocol known as hard-state protocol. When one FEC is bound to one label and this information is flooded using LDP, that bind stays until a new call tear down the bound.  Then, on the contrary to RSVP, for example, LDP doesn't require refreshing and provide implicit routing.
Some other routing protocol have been advised to use as LDP to implement MPLS networks. Some of them are OSPF, IS-IS  and BGP.  Problem, however, is that neither of these protocols do anything to implement wise traffic engineering practices, because traffic is always redirected to the high priority LSP causing(decided by next hop) and  finally results congestion to one path.
To approach this problem some signalling protocols have been used to create traffic tunnels using explicit routing, allowing this way for better traffic engineering. Some of these protocols are: Constraint Route Label Distribution Protocol (CR-LDP), and Resource Reservation Protocol (RSVP-TE). 

RSVP-TE and CR-LDP give MPLS the possibility to police traffic and control load in a fashion similar as the Integrated Service and Differentiated Service architectures do.

CR-LDP
CR-LDP modifies the original LDP design to allow for traffic specification. This protocol adds new fields to the original LDPprotocol;  these are: Committed Information Rate (CIR), Peak Information Rate (PIR), Committed Burst Size (CBS),Peak Burst Size (PBS) and Excess Burst Size (EBS).

The call setup process for CR-LDP is a simple two-step process:  a request and a map. Because CR-LDP is a hard-state protocol, this means that once the path is established, it will not be broken down until an specific request to do so is received. The protocol is then, more scalable.

LDP uses User Datagram Protocol (UDP) and TCP to transport the protocol data unit (PDU) that carries LDP messages. Each LDP PDU is an LDP header followed by one or more LDP messages. Two routers with an established session are called LDP peers.LDP is used to build and maintain LSP databases that are used to forward traffic through MPLS networks.
LDP peers are two LSRs that use LDP to exchange label information. An LSR might have more than one LDP peer, and it establishes an LDP session with each LDP peer. An LDP session is always bidirectional, which allows both LDP peers to exchange label information. However, using a bidirectional signaling session does not make the label-switched path (LSP) bidirectional. As described, an LSP is unidirectional, and a pseudo-wire consists of two LSPs of the opposite directions. Besides directly connected LSRs, LDP sessions can also be established between non-directly connected LSRs.


LDP Header Format
Version (2 Octets)
PDU Length (2 Octets)
LDP Indentifier(ID) (6 Octets)
LDP messages:
Discovery messages
Session messages
Advertisement messages
Notification messages

Except for discovery messages that use UDP as the underlying transport, LDP messages rely on TCP to ensure reliable and in-order delivery of messages.  LDP uses TCP for communication, which ensures that label messages are delivered reliably and paced out (i.e., flow control) and that distributed labels and state information associated with LSPs need not be refreshed periodically.
LDP relies on the underlying routing information provided by an IGP in order to forward label packets.



Label Space


An LDP label binding is an association between a destination prefix and a label. The label used in a label binding is allocated from a set of possible labels called a label space.


LDP supports two types of label spaces:


Interface-specific=An interface-specific label space uses interface resources for labels. For example, label-controlled ATM (LC-ATM) interfaces use virtual path identifiers/virtual circuit identifiers (VPIs/VCIs) for labels.


Platform-wide=An LDP platform supports a single platform-wide label space for use by interfaces that can share the same labels. For Cisco platforms, all interface types, except LC-ATM, use the platform-wide label space.


LDP Identifier


LDP uses a 6-byte quantity called an LDP Identifier (or LDP ID) to name label spaces. The LDP ID is made up of the following components:


The first four bytes, called the LDP router ID, identify the LSR that owns the label space(LSR/Router ID)


The last two bytes, called the local label space ID, identify the label space within the LSR. For the platform-wide label space, the last two bytes of the LDP ID are always both 0.


So, LDP ID= LPD Router ID + Local label space ID


The LDP ID takes the following form:


<LDP router ID> : <local label space ID>


The following are examples of LPD IDs:


1.1.1.1:0
192.168.0.0:3

TLDP(Targeted LDP)
LDP can be used to distribute the inner label (VC/VPN/service label) and outer label (path label) in MPLS. For inner label distribution, targeted LDP (tLDP) is used. Alternatively, MP-BGP is used in case of IPVPN.
LDP and tLDP discovery runs on UDP port 646 and the session is built on TCP port 646. During the discovery phase hello packets are sent on UDP port 646 to the 'all routers on this subnet' group multicast address (224.0.0.2). However, tLDP unicasts the hello packets to the targeted neighbor's address.



If the LSR is more than one hop from its neighbor, it is nondirectly connected to its neighbor. For these nondirectly connected neighbors, the LSR sends out a targeted Hello message as a UDP packet, but as a unicast message specifically addressed to that LSR. The nondirectly connected LSR responds to the Hello message and the two routers begin to establish an LDP session. This is also called extended discovery.

An MPLS LDP targeted session is a label distribution session between routers that are not directly connected. When you create an MPLS traffic engineering tunnel interface, you need to establish a label distribution session between the tunnel headend and the tailend routers. You establish nondirectly connected MPLS LDP sessions by enabling the transmission of targeted Hello messages.

Targeted LDP sessions are different because during the discovery phase hellos are unicast to the LDP peer rather than using multicast. A consequence of this is that tLDP can be set up between non-directly connected peers whereas non-targeted LDP peers must be on the same subnet. tLDP may still be used between connected peers if desired.



The mpls ldp neighbor targeted command can improve label convergence time for directly connected neighbor LSRs when the link(s) directly connecting them are down. When the links between the neighbor LSRs are up, both the link and targeted Hellos maintain the LDP session. If the links between the neighbor LSRs go down, the targeted Hellos maintain the session, allowing the LSRs to retain labels learned from each other. When a link directly connecting the LSRs comes back up, the LSRs can immediately reinstall labels for forwarding use without having to reestablish their LDP session and exchange labels.


he default behavior of an LSR is to ignore requests from other LSRs that send targeted Hello messages. You can configure an LSR to respond to requests for targeted Hello messages by issuing the "mpls ldp discovery targeted-hello accept" command.


The exchange of targeted Hello messages between two nondirectly connected neighbors can occur in several ways, including the following:



  1. Router 1 sends targeted Hello messages carrying a response request to Router 2. Router 2 sends targeted Hello messages in response if its configuration permits. In this situation, Router 1 is considered to be active and Router 2 is considered to be passive.
  2. Router 1 and Router 2 both send targeted Hello messages to each other. Both routers are considered to be active. Both, one, or neither router can also be passive, if they have been configured to respond to requests for targeted Hello messages from each other.


LDP Process inicialization
LDP peer which has the highest loopback id starts the Label Distribution Protocol initialization process by sending common session parameter(Address message and label mapping message which are sub part of label distribution protocol.)
Address message: Address message is only containing the directly connected interface ip address of Router2 which are 10.1.1.2 and  2.2.2.2.
Label Message: containing the information about route, label and address family.
Address family means whether it is ipv4 route or vpnv4 route.
For Example:

lo1.1.1.1                               lo2.2.2.2
||                                           ||
Router1<<<<10.1.1.0>>>>>Router2
In this example Router2 will initiate the LDP session due to its loopback IP(highest).
First It will send information about 10.1.1.0 route by including label say 15 which will be used for PHP. Similarly, Router2 will send a label say 16 to Router1 for its loopback address 1.1.1.1. Thus, label 16 will become a local label in the forwarding table for Router2.
Once this is done then Router1 will initiate a label mapping process by sending the label and other information to Router2.

Session establishment begins with each LSR advertising a periodic Hello message containing the LSR ID and Label Space ID. When an LSR sees a Hello message from a peer LSR, it keeps track of that peer (i.e., an adjacency). Hello messages are encapsulated in UDP and are only used for initial neighbor discovery. The peer with the highest LSR ID becomes active; the other becomes passive. The active LSR initiates a TCP session, which is a three-way handshake establishing the TCP session.

Once a TCP session is established, the active LSR sends an initialization message, which contains the parameters for the LDP session. Relevant information in this message includes the LDP version, label distribution method, timer values, VPI/VCI ranges for label-controlled ATM, DLCI ranges for label-controlled frame relay, etc. This information is then acknowledged by the passive LSR, which then responds with its own initialization message. This message is also acknowledged by the active LSR.

Any error or incompatibility resulting from the initialization process will cause the session to fail and the TCP session to be torn down. Once initialization is complete, KeepAlive messages are sent to confirm the session is still active, even when no real data is being sent.

Label Distribution
When any LSR detects a new FEC (i.e., a new entry in the routing table or BGP next hop), it assigns a label to the FEC and sends a label mapping message telling its upstream neighbor LSRs to use the label to forward traffic to the FEC.
An upstream LSR might receive many labels to use for a particular FEC from potential downstream LSRs. With liberal label retention, all these labels will be retained; however, only one—the label from the LSR identified as the next hop by the routing protocol—is used to push or swap on a packet.

The label used between each LSR is a local issue. The ultimate path defined by the resulting LSP is unidirectional and defined by the shortest path according to the IGP used by the LSRs. LDP supports forwarding along normally routed paths as determined by destination-based routing protocols, such as RIP, EIGRP, OSPF, and IS-IS. This forwarding is sometimes called MPLS hop-by-hop forwarding.
The full set of LDP-defined messages follows.
Notification
Hello
Initialization
Keep Alive
Address
Address Withdraw
Label Mapping
Label Request
Label Abort Request
Label Withdraw
Label Release
Draft enhancements also propose additional messages to facilitate management and to find out which LSRs carry an LSP.
Query
Query-Reply
Partial Query-Reply







No comments:

Post a Comment