Previous

Content

Next 

4.2.- LDP Operation  

FECs
An FEC identifies the set of IP packets which may be mapped to one LSP. Each FEC is specified as a set of one or more elements. These elements are:
  1. Address Prefix: an address prefix of any length from 0 to a full address, inclusive.
     
  2. Host Address: a full host address.

Note: a full address' address prefix has different effect that the same full host address.
One address matches an address prefix if and only if that address begins with that prefix. One packet matches a particular LSP if and only if that LSP has an Address Prefix FEC element which matches the packet's destination address. This Address Prefix FEC element is known as the "matching prefix".
For mapping a packet to an LSP the following rules apply:
  1. If there is exactly one LSP which has a Host Address FEC element identical to the packet's destination address, the packet must be mapped to this LSP.
     
  2. If there are multiple LSPs having a Host Address FEC element identical to the packet's destination address, the packet must be mapped to one of these LSPs. Selecting one of them is beyond the scope of this document.
     
  3. If a packet matches exactly one LSP, the packet must be mapped to this LSP.
     
  4. If a packet matches multiple LSPs, the packet must be mapped to the LSP whose matching is the longest. If none of the matching is the longest, the packet must be mapped to the LSP whose matching prefix is longer than the other.
     
  5. If it is known that a packet must traverse a particular egress router, and there is an LSP which has an Address Prefix FEC element which is an address of that router, then the packet must be mapped to that LSP. The procedure for obtaining this knowledge is beyond the scope of this document.
Some consequences of these rules are:
  1. A packet may be mapped to one LSP having an Address Prefix FEC element which is the address of the packet's egress router ONLY if there is no LSP matching the packet's destination address.
     
  2. If a packet matches two LSP, one having a Host Address FEC element and one having an Address Prefix FEC element, the packet must be mapped to the former.
     
  3. If a packet does not match a particular Host Address FEC element, it may not be mapped to the corresponding LSP, even if the element identifies the packet's egress router.
Label Spaces
 
There are two types of label spaces:
 
  1. Per-interface label space: incoming labels are interface-specific. This only makes sense when the LSP peers are "directly connected" over an interface and the label is only going to be used for traffic between those interfaces.
     
  2. Per-platform label space: incoming labels are platform-wide.
LDP Identifiers
 
An LDP identifier is a six octects quantity used to identify an LSR label space. First four octets identify the LSR and must be a globally unique value, such as the 32-bit router Id. Last two octet identify a specific label space within the LSR. These are always zero for platform-wide label spaces. An LSP identifier is represented as:
 

<LSR Id> : <label space id>
 
Note that an LSR that manages and advertises multiple label spaces uses a different LDP identifier for each such label space.
 
LDP Sessions
 
   

 
LDP sessions exist between LSRs to support label exchange between them. When more that one label space is advertised, a separate LDP session should be used for each label space. TCP is used as a reliable transport protocol for sessions. When multiple LDP sessions are required between two LSRs there will be one TCP session for each LDP session.
LDP Sessions between non-directly connected LSRs
LDP sessions between not directly connected LSR are required for "traffic engineering" applications using explicit LSPs.
When an LSR named LSRa needs to open a directly LSP tunnel with an LSR named LSRb through one or more intermediate LSRs (LSR1, ..., LSRn), an LDP session between LSRa and LSRb would enable LSRb to label switch traffic arriving on this LSP tunnel and provides LSRb means to advertise labels to LSRa for this purpose.
In this case LSRa would apply two labels to traffic it forwards on the LSP tunnel to LSRb. First it adds the label learned via its LDP session with LSRb (replacing label on top for labeled packets or pushing a new label for unlabeled packets), next it pushes the label for the LSP learned from LSR1 onto the label stack.
LDP Discovery
LDP Discovery is a mechanism that enables an LSR to discover potential LDP peers. There are two variants. The "basic discovery mechanism" to discover directly connected neighbors and an "extended discovery mechanism" to discover not directly connected neighbors.
Basic Discovery Mechanism
To engage in this mechanism, an LSR periodically sends LDP Link Hello messages as UDP packets addresses to the well-known LDP discovery port for the "all routers on this subnet" group multicast address. The messages carry the LDP Identifier for the label space the LSR intends to use for the interface being used and possibly additional information.
Receipt of an LDP Link Hello message on an interface identifies a "Hello adjacency" with a potential LDP peer reachable at the link layer on that interface.
Extended Discovery Mechanism
To engage in this mechanism, an LSR periodically sends LDP Targeted Hello messages as UDP packets addressed to the well known LDP discovery port to an specific address. The messages carry the LDP Identifier for the label space the LSR intends to use and possibly additional information.
How extended and basic discovery mechanisms differ?
  1. A targeted Hello (for extended discovery) is sent to a specific address rather than to "all routers" multicast address for the outgoing interface.
     
  2. Basic Discovery is symmetric, while Extended Discovery is asymmetric.
When an LSR initiates Extended Discovery with another targeted LSR, this decides whether to respond to or ignore the Targeted Hellos. When it chooses to respond, it does so by periodically sending Targeted Hellos to the initiating LSR. Receipt of these Hellos identifies a "Hello adjacency" with a potential LDP peer reachable at the network layer.
LDP Session Establishment
The following procedures describe establishment of an LDP session between LSRs LSR1 and LSR2 from LSR1's point of view. The previous exchange of Hellos specifies label space LSR1:a for LSR1 and LSR2:b for LSR2.
Session establishment is a two step process:
  1. Step 1: Transport connection establishment
     
     
    1. Each LSR end will use as source address the address they used before to send Hellos. These addresses are advertised in the Hellos either explicitly by including each in an optional Transport Address TLV, or implicitly by omiting the TLV and using the address as the Hello source address. Let's call A1 the LSR1's address and A2 the LSR2's address.
       
    2. One of the LSRs will play the active role; the other the pasive role. If A1>A2, LSR1 plays the active role; otherwise it is passive.
       
    3. If LSR1 is active, it attempts to establish an LDP TCP connection by connecting to the well-known LDP port at address A2. If LSR1 is passive, it waits for LSR2 to establish the connection.
       
    4. Each LSR MUST advertise the same transport address in all Hellos that advertise the same label space.
    		  
  2. Step 2: Session initialization
     
      After the connection is established, if LSR1 is active, it initiates negotiation of session parameters by sending an initialization message to LSR2. The parameters negociated include LDP protocol version, label distribution method, timer values, VPI/VCI ranges for ATM, DLCI ranges for FR, etc. Successful negotiation completes establishment of an LDP session between LSR1 and LSR2.

    The initialization message carries both the LDP identifier for the sender's label space and the LDP identifier for the receiver's label space.

    The process is as follows:
     
     
    1. When LSR1 plays the passive (receiver) role:
       
       
      1. It attempts first to match the Initialization Message's LDP identifier with a Hello adjacency. If there is a matching Hello adjacency, this specifies the local label space for the session.
         
      2. Next, it checks whether session parameters proposed in the message are acceptable. If they are, it replies with an Initialization message of its own to propose the parameters it wishes to use and a KeepAlive message to signal acceptance of LSR2's parameters. If the parameters are not acceptable, it responds by sending a Session Rejected/Parameters Error Notification message and closing the TCP connection.
         
      3. If LSR1 cannot find a matching Hello adjacency it sends a Session Rejected/No Hello Error Notification message and close the TCP connection.
         
      4. If LSR1 receives a KeepAlive in response to its Initialization message, the session is operational from LSR1's point of view.
         
      5. If LSR1 receives an Error Notification message, LSR2 has rejected its proposed session and it closes the TCP connection.
      		  
    2. When LSR1 plays the active role:
       
       
      1. If it receives an Error Notification message, LSR2 has rejected its proposed session and it closes the TCP connection.
         
      2. If it receives an Initialization message, it checks whether the session parameters are acceptable. If so, it replies with a KeepAlive message. If not, it sends a Session Rejected/Parameter Error Notification message and close the connection.
         
      3. If it receives a KeepAlive message, LSR2 has accepted its proposed session parameters.
         
      4. When it has received both, an acceptable Initialization message and a KeepAlive message, the session is operational from LSR1's point of view.
      		  
    		 
    		 
Next figure represents the LDP session negotiation as a state transition diagram:

Maintaining Hello Adjacencies
 
An LDP session with a peer has one or more Hello adjacencies. It has multiple Hello adjacencies when a pair of LSRs is connected by multiple links that share the same label space; for example, multiple PPP links between a pair of routers.
 
LDP includes mechanisms to monitor the necessity of an LDP session and its Hello adjacencies. Regular receipt of LDP Discovery Hellos indicate a peer's intent to use the label space identified by the Hello. A hold timer is maintained with each Hello adjacency which is restarted each time a Hello is received that matches the adjacency. If the timer expires without receipt of a matching Hello from the peer, LDP concludes that the peer no longer wishes to label switch using that label space for that link or that the peer has failed. Then, LDP deletes the Hello adjacency. When the last Hello adjacency for a LDP session is deleted, the LSR terminates the LDP session.
 
Maintaining LDP Sessions
 
LDP includes mechanisms to monitor the integrity of the LDP session by the use of LDP PDUs on the connection. Each LSR maintains a KeepAlive timer for each peer session which it resets whenever an LDP PDU is received from a session peer. If the KeepAlive timer expires without receipt of an LDP PDU from the peer, the LSR concludes that the transport connection is bad or that the peer has failed, terminating the LDP session by closing the connection.
 
After an LDP session has been established, an LSR must arrange that its peer receive an LDP PDU from it at least every KeepAlive time period to ensure the peer restarts the session KeepAlive timer. The LSR may send any protocol message to meet this requirement. If there is no other information to communicate to its peer, it sends a KeepAlive message.
 
 
 
 
 
 
 
   

 
 

 
Previous

Content

Next