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
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:
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:
- 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.
- 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