|
||
Individuelle Entwicklung und Beratung für Telekommunikation, Transport und Logistik |
|
||||||||||||
| Aktuelles |
| 03.03.2009 AstiTel im neuen Look |
| 05.09.2008 Fixed Mobile Convergence (FMC) ist die Zukunft |
|
|
 |
| RSVP-TE Patch for NS2
| |
|
| |
| IDEO Laboratories has developed a patch for the RSVP-TE protocol in NS2. The RSVP-TE patch includes mns version 2 (MPLS Implementation for NS2).
(the RSVP-TE patch is no longer available and has been integrated in Hierarchical MPLS Patch for NS2) Request summary: Useful resources and links: | |
Article: Short Introduction to RSVP-TE (René Böringer) RSVP-TE has capabilities similar to those of CR-LDP. The general process of label distribution is also comparable. Both, RSVP-TE and CR-LDP request a label with a downstream message. A second message delivers the label upstream. However, there are also big differences. In contrast to CR-LDR, RSVP-TE belongs to the group of soft state protocols. ”Soft state” means that to hold the path permanently over the time, it is necessary to transmit update messages periodically. These update messages reset an expiry timer and synchronize the status on the LSRs. If the timer expires, the state changes to passive, which causes a deletion of the reservation state. The respective device indicates a problem to the end points of the LSP. To avoid the change to passive, RSVP-TE transmits PATH or RESV messages to update the reservation and to reset the timer. It should also be mentioned, that RSVP-TE uses neither UDP nor TCP. It works on IP and it has to handle the loss of messages, which is one of the reasons to use a soft state mechanism. This mechanism also allows automatic adaptation to changes of the routing tree. RSVP-TE only uses downstream-on-demand mode. In RSVP-TE, the message requesting the label and carrying the traffic parameter is called the PATH message. This message is sent downstream to the egress node of the respective LSP. To route the RSVP-TE messages and to find the next hop, RSVP-TE uses the flexibility of the MPLS control plane, meaning that regular or enhanced routing protocols can be used. Thus, in the case of a regular routing process, RSVP-TE messages take the same path as IP packets would take. However, it is also possible to use an explicit route, which can differ from the regularly shortest path. If the packet reaches the egress node of the LSP, this device generates an RESV (reservation) message and sends it to the next node upstream. This message contains, among others, the label allocated by the node with respect to the requested FEC (Forwarding Equivalence Class). Each RSVP-TE-capable node stores information about PATH messages in the Path State Block (PSB). The PSB also contains the previous hop and the address of the sender node it received the PATH message from. The address is used as the destination address of the RESV message, which is reverse directed. This process ensures that both messages take the same path through the network, but in different directions. After a node has received a valid RESV message it creates an additional Reservation State Block (RSB) and stores some information about the RESV message. Altogether, the nodes use four state blocks. The Traffic Control State Block (TCSB) maintains the reservation indexed by a session, meaning an ingress-egress node pair, and an outgoing interface. The Blockade State Block (BSB) completes the state block list. It is responsible for maintaining rejected requests by distributing the reruns by means of a random generator. This procedure prevents the interference between big and small reservation requests. The interference is caused by request or reservation aggregations. However, the detailed mechanism is out of the scope of this article. RSVP-TE messages should be understood as containers for different objects. Prime fields of the header are the length field containing the aggregated size of the message inclusive the objects, and the Message Type field, which identifies the type of the message. For example, a PATH message is indicated by the value 1 and the RESV message carries the value 2. Type values from 1 up to 7 have been defined since the standardization of RSVP [RFC, 2205]. However, a lot of other proposals (like the RSVP-TE or HELLO extensions [RFC, 3209]) add message types for new messages. | |
| Do you have any questions?
Please contact IDEO Laboratories! |
Druckansicht
