o All LSRs receive this HELLO message on the UDP port. Thus, at some point in time, an LSR will know all other LSRs with which it is directly connected.
o When an LSR learns the address of another LSR using this mechanism, it establishes a TCP connection to that LSR.
o An LDP session is then established between the two LSRs. An LDP session is bidirectional, meaning that each LSR at both ends of the connection can request and send label bindings.
Maybe you are interested!
-
Procedure for Applying Law in Criminal Investigation Cases -
Provisions of Criminal Procedure Law on Depositing Money or Valuable Assets as Security -
Administrative procedure reform in the Customs sector today - 9 -
Costing Procedure Using Sequential Transfer Method -
Temporary Emergency Measures Under Vietnamese Civil Procedure Law
Figure 2- 11 Neighbor LSR Discovery Procedure
In case the LSRs are not directly connected in a subnet, an additional mechanism is used as follows:
The LSR periodically sends HELLO messages to a known UDP port at the IP address specified during configuration. The receiver of this message can reply with another HELLO message transmitted one-way back to the sending LSR and LDP sessions are established as above.
This case is often applied when there is a labeled LSP for traffic control between 2 LSRs and it requires sending labeled packets through that LSP.
Reliable Transport Protocol
The decision to use TCP to transport LDP messages is a matter of consideration. Reliability is essential: if label bindings or label binding requests are transmitted unreliably, traffic will not be switched by label. Another important issue is the order in which messages are delivered. So is it reliable to use TCP to transport LDP, and should this transport functionality be built into LDP itself?
Building reliability assurance functions in LDP does not necessarily require implementing all the functions of TCP in LDP, but only needs to stop at the most necessary functions, for example, the congestion control function is considered unnecessary in LDP... However, developing more reliability assurance functions in LDP also has many issues to consider, for example, timers for acknowledged and unacknowledged messages. In the case of using TCP, only 1 TCP timer is needed for the entire LDP session.
Designing a reliable transport protocol is a difficult problem. There have been many attempts to improve TCP to increase the reliability of the transport protocol. However, the problem is still unclear and TCP is still used for LDP transport.
LDP Newsletters
There are four basic types of newsletters:
o Initialization Message
o KeepAlive Newsletter
o Label Mapping Newsletter
o Release Newsletter
Label Withdrawal Newsletter
Request message
Request Abort message.
o Initialization message format
Messages of this type are sent at the beginning of an LDP session between two LSRs.
to exchange parameters, options for the session. These parameters include:
- Label allocation mode
- Timer values
- The range of labels used in the channel between the two LSRs.
Both LSRs can send Initialization messages and the receiving LSR will reply with KeepAlive if the parameters are accepted. If any parameter is not accepted the LSR replies with an error message and the session ends.
o KeepAlive newsletter format
KeepAlive messages are sent periodically when no messages are sent to ensure that each LDP component knows that the other LDP component is functioning properly. If no KeepAlive message or some other LDP message appears for a certain period of time, the LSR determines that the other party or the connection is down and the LDP session is terminated.
o Label Mapping message format
Label Mapping messages are used to advertise the association between a FEC (Address Prefix) and a label. The Label Withdrawal message does the reverse: it is used to remove the association that was just established. This message is used when a change in the LSR configuration causes the label forwarding of packets in that FEC to be suspended.
o Label Release Message Format
This message is used by an LSR when it receives a label that it no longer needs. This typically happens when the releasing LSR finds that the next-hop node for that FEC is not the LSR advertising that label/FEC binding.
In forward labeling on-demand mode of operation, the LSR requests a label from its forward neighbor using a Label Request message. If the Label Request message needs to be discarded before it can be accepted (because the next node in the requesting FEC has changed), the requesting LSR rejects the request with a Label Request Abort message.
Label distribution modes
We have seen some operating modes in label distribution such as: no forward request, forward request, commanded or independent LSP control, advanced or conservative maintenance. These modes are negotiated by LSRs during LDP session initiation.
When an LSR operates in conservative retention mode, it will only hold the Label/FEC values it needs at the moment. Other transitions are released. The opposite is true in advanced retention mode. The LSR holds all the transitions it is informed of even if some are not in use at the moment. The operation of this mode is as follows:
o LSR1 sends a label binding on some FEC to one of its neighboring LSRs (LSR 2) for that FEC.
o LSR2 finds that LSR1 is not currently the next node for that FEC and it cannot use this binding for forwarding purposes at the moment, but it still saves this binding.
o At some point in the future, if a routing change occurs and LSR 1 becomes the next node of LSR2 for that FEC, LSR2 updates its routing table accordingly and can forward labeled packets to LSR1 on its new route. This is done automatically without the need for LDP signaling or new label distribution.
The biggest advantage of the advanced retention mode is the ability to react faster to routing changes. The biggest disadvantage is the waste of memory and labels. This is especially important and has a great impact on devices that store routing tables in hardware such as ATM – LSR. Usually, the conservative retention mode of labels is used in ATM – LSR.
2.3.2 Resource Reservation Protocol
Having reviewed the main components of the integrated services architecture, this section will focus on the RSVP signaling protocol, which plays a very important role in MPLS. RSVP is the protocol that allows applications to communicate QoS requirements to the network, and the network will respond with success or failure messages. RSVP must carry the following information:
o Classification information, by which traffic flows with specific QoS requirements can be distinguished in the network. This information includes the sending and receiving IP addresses and UDP port numbers.
o Traffic flow specifications and QoS requirements, in TSpec and RSpec format, including required services (guaranteed or load controlled)
Obviously, RSVP must carry this information from the servers to all the switches and routers along the path from sender to receiver, so all these network components must participate in ensuring the QoS requirements of the application.
RSVP carries information in two basic message types: PATH and RESV. PATH messages transmitted from the sender to one or more receivers contain TSpec and classification information provided by the sender. One reason for this is
The reason for allowing multiple receivers is that RSVP is designed to support multicasting. A PATH message is always sent to an address called the session address , which can be either a unicast or a multicast address. We usually think of a session as representing a single application, identified by a destination address and a destination port number that are specific to the application. In the following we will see that there is no reason to think of a session in such a limited way.
When the receiver receives the PATH message, it can send a RESV message back to the sender. The RESV session acknowledgement message contains information about the reserved port number and RSpec confirming the QoS level requested by the receiver. It also includes some information about which senders are allowed to use the allocated resources. Figure 2-12 shows the sequence of messages exchanged between the sender and receiver. Note here that the reserved ports are simplex. If full-duplex reserved ports are needed (for example, for traditional voice), additional messages must be sent in the opposite direction. Note also that the messages are received and forwarded by all routers along the communication path, so resource allocation can be performed at all necessary network nodes.
Once reserved ports are set up, routers between the sender and receiver determine which reserved port packets belong to which port by examining five fields in the IP header and the transport protocol: destination address, destination port number, protocol number (e.g. UDP), source address, and source port. We call the set of packets identified in this way a reserved flow . Packets in a reserved flow are often throttled (to ensure that the flow does not generate more traffic than advertised in the TSpec) and queued to meet QoS requirements. For example, one way to achieve guaranteed service is to use weighted queues (WFQ), where each different reserved port is considered a flow with respect to the queues, and the weight is
is assigned to each flow according to the service rate requested in its RSpec.
For unicast flows, RSVP is quite simple. It becomes more complicated in multicast environments, because there can be many entities that reserve ports for a single session, and different entities may require different levels of QoS. MPLS is currently focused on the unicast applications of RSVP, we will not go into the multicast aspects of RSVP.
The final point to note about RSVP is that it is a “soft state” protocol. The distinguishing feature of soft state protocols is that the state automatically expires after a period of time unless it is periodically refreshed. This means that RSVP periodically sends out PATH and RESV messages to refresh port reservations. If they are not sent within a specified period of time, the port reservations are automatically discarded.
Figure 2- 12 Signaling procedure in RSVP
MPLS supports RSVP
In this section we focus only on the role of RSVP in MPLS networks in terms of QoS support.
The primary goal of adding RSVP support to MPLS is to allow LSRs to rely on label classification rather than IP headers to identify packets belonging to dedicated port flows. In other words, it is necessary to create and distribute between flows and labels for
RSVP dedicated ports flow as another special case of FEC.
It becomes quite easy to associate labels with reserved flows in RSVP, at least for unicast. We define a new RSVP object as a LABEL object carried in the RSVP RESV message. When an LSR wants to send a RESV message for a new RSVP flow, the LSR allocates a label from the free label pool, at an entry in its LFIB with the entry label set to the allocated label, and sends a RESV message containing this label in the LABEL object. Note that the RESV messages from the receiver to the sender are in the form of forward label allocations.
Upon receiving a RESV message containing a LABEL object, an LSR sets up its LFIB with this label as the egress label. It then allocates a label to use as the ingress label and inserts it into the RESV message before sending it. Clearly, as RESV messages propagate up the upstream LSR, an LSP is established along the path. Also note that, since labels are provided in RESV messages, each LSR can easily associate QoS resources appropriate to the LSP. Figure 2-13 illustrates this exchange. In this case, we assume that hosts do not participate in label distribution. LSR R3 allocates label 5 to this reserved port and advertises it to R2. R2 allocates label 9 also to this reserved port and advertises it to R1. Now there is an LSP for the reserved flow from R1 to R3. When packets corresponding to this reserved port (e.g. packets sent from H1 to H2 with appropriate source and destination port numbers and appropriate transport protocol numbers) arrive at R1, R1 distinguishes it using IP header and transport layer information to create appropriate QoS for the reserved port such as characteristics and queuing of packets in the egress queue. In other words, it performs the functions of a service integration router using RSVP. Furthermore, R1 injects the label header into