The Laboratory of Computer Communication and Networking Resilient Packet Ring (RPR)

Project Team: Submitted by:Fraiman Gelfer Kremerov Instructor:Sela Supervisor:Dabran Reuven

Project Goal:  Develop a simulator of a Resilient Packet Ring, in order to simulate BIR behavior under given conditions. The chosen language of the project implementation is Java!

Background:  The permanently increasing volume of data, passing via large circuit-based networks, poses a challenge to the limited capacity of the existing structures.

Background:  The difficulties prevent from creating new and improved services, and increase the cost over adding capacity to such networks communications.  Many consider the packet-based technology to be the best alternative for scaling large networks to stand up to those requirements.

Background (cont.):  Based on the above said, the best solution to the described problem is Resilient Packet Ring technology.  There are two main features it provides: efficient support for ring topology and fast recovery from fiber cuts and link failures.  It also offers data efficiency, simplicity, cost advantages, and solves problems such as fairness and congestion control that have not been addressed yet by other technologies.

Background (cont.):  SRP (or RPR) uses a bidirectional dual counter- rotating ring topology. The rings are referred to as "inner ring" and "outer ring", as shown in the picture:

Background (cont.):  Both rings transfer data and SRP protocol packets concurrently, which provides the protocol with bandwidth-efficiency, along with the fact that packets are being tossed out by the receiver, and not by the sender.  Control packets handle topology discovery and protection switching.  Usage Packets handle bandwidth control.

Simulator Modules: The simulator consists of three main modules: 1.Graphic user interface. 2.Controller. 3.SRP simulator.

Graphic User Interface:  This module is in charge of basic user interface for configuring and monitoring the SRP ring, in order to simulate topology changes such as ring wrap.  Accepts input parameters given by the user, and transfers it to the SRP simulator via the controller.  In charge of presenting the user with a graphic simulation of the SRP and its activities.  Presents the user with a variety of opportunities to influence the activities described above.

The SRP Simulator:  The heart of the system, simulates the activity of the SRP.  Consists of nodes, the number of which is chosen by the user, which combine to a circuit-like network, implementing the SRP protocol on level 2 – the MAC layer.  Each node has the ability to send packages to any other node in the network. The packages are created by a Poisson derived package-maker, which is a component of each node.

The SRP Simulator (cont.):  Upon package creation, the node strives to send it to the designated receiver.  Each node forwards packages which weren’t addressed to it personally.  The user has strong influence on the network structure: he has the ability to choose the number of nodes, cause node failure or "corrupt" a communication fiber; also, the user can repair these damages. He can choose a mode for the simulation, which allows him to follow the relevant information conveniently. He may set or reset the fairness.

The SRP Simulator (cont.): The user is presented with the following abilities: Setting the number of stations Disabling a chosen node Disabling a chosen wire Also, the user is presented with the following: Enabling a chosen node Enabling a chosen wire Adding a node to the system Setting the mode of the simulation Disabling/Enabling fairness

The SRP Simulator (cont.):

The Controller:  In charge of communications between the graphic interface and the SRP simulation module.  In charge of translating the data inserted by the user via the graphic interface, to commands which will be given to the SRP simulation module.  Presents the graphic interface with information regarding the flowing events on the simulation, based on which the graphic interface is activated.

Protocols and Algorithms: Our simulation’s protocols and algorithms, each monitoring a different problematic area of the RPR: 1)SRP-Fairness Algorithm (fa). 2)Topology Discovery. 3)Intelligent protection switching.

SRP-fa: Our system implements the Fairness Algorithm according to its description in the White Paper. Each node, in a determined period of time, sends a Usage Packet into the Ring. The usage packets have 2 main goals: 1) To perform the keep alive function. 2) To propagate allowed usage information to upstream nodes.

SRP-fa (cont.):  The propagation of allowed usage is performed when the node receives the Usage Packet.  If the down stream node was congested, it will specify in the Usage Packet the allowed usage that the received node could propagate to the Ring and still keep out from over congesting the Ring.

SRP-fa (cont.):  When receiving the Packet of a congested node, the node reduces its “allowed usage” parameters, and transits it to the upstream node, which will do the same.  When a congested node receiving the Packet, it transits upstream the minimum between its own “allowed usage” and the one he got from the down stream nodes.  The result of this procedure when the system stabilizes, is that the usage transmitted into the Ring is according to the pre-defined “allowed usage” parameters.

SRP-fa (cont.): A detailed description of the SRP-fa algorithm: 1. There are 3 counters for each node: 1.1 my_usage – amount of packages sourced by the node on the Ring 1.2 forward_rate – amount of packages forwarded to the Ring from sources other than the host 1.3 allowed_usage – the current allowed maximum transit and transmit usage for the node and a threshold: 1.4 max_usage – the overall maximum usage for the node (predetermined).

SRP-fa (cont.): 2. A node can send host packets if my_usage_ok = true. 2.1 The condition is: if (my_usage<allowed_usage)&& (forward_rate>=my_usage(if transit buffer not empty))&&(my_usage<max_usage) then my_usage_ok = true 3. The condition for the congestion: transit buffer depth crossed a congestion threshold (tb_low_depth>(TB_LOW_THRESHOLD/2)) - TB_LOW_THRESHOLD – transit buffer depth at which no host packets can be sent. -tb_low_depth – the transit buffer depth

SRP-fa (cont.): 4. When a node sees congestion: 4.1 it advertizes to the upper node its lp_my_usage value (which is its “my_usage” value after being low pass filtered) 5. When a node receives a non-null usage information: 5.1 If the node is “congested”: if the receiving node is the one who sent the usage – the usage information is discarded else, it - sets its “allowed usage” to the received value. - propagates to the upstream node: min{lp_my_usage, usage info}

SRP-fa (cont.): 5.2 If the node isn’t “congested”: if (forward_rate>=allowed_usage) then: the node will send the received usage value to the upstream node else // forward_rate SPATIAL REUSE OPPORTUNITY! then: the node will send upstream a null(=max) usage value. Meaning, that it is able to receive more packages from upstream and there is no need from them to throttle their traffic.

SRP-fa (cont.): 6. Definitions: 6.1 Decay_Interval – predefined value. States an interval of time in which the following actions are performed 6.2 AGECOEFF – Aging coeff for my_usage and forward_rate (usually = 4) 6.3 MAX_LINE_RATE = AGECOEFF*Decay_Interval 6.4 Lp_Allowed = Low pass filter for allowed_usage auto_increment

SRP-fa (cont.): 6.5 The following is performed every Decay_interval: “congested” parameter is calculated (according to paragraph #3) my_usage is decremented by: min{allowed_usage/AGECOEFF, my_usage/AGECOEFF} (see parag. 1.1, 1.3, 6.2) forward_rate is decremented by: (forward_rate/AGECOEFF) (see parag. 1.2, 6.2) lp_my_usage is calculated (according to a predefined low pass filter function) lp_forward_rate is calculated (according to a predefined low pass filter function)

SRP-fa (cont.): allowed_usage is updated as follows: if (last received usage != null)(means there is a signal of congestion downstream, traffic must be throttled): allowed_usage = last received usage else (means last received usage = null, there is no congestion downstream -> SPATIAL REUSE!!) allowed_usage = allowed_usage + ((MAX_LINE_RATE-Allowed_usage)/Lp_allowed) (see parag 1.3,6.1,6.2,6.3,6.4)

IPS:  The SRP structure as a bidirectional ring, provides the self-healing capabilities after different kinds of failures.  The IPS protocol is responsible for monitoring and controlling the healing process. To prevent packets loss during the period from the failure until the system’s recovery, IPS protocol uses the bidirectional ring structure and performs a ring- wrap, as soon as the failure is discovered.

IPS (cont.): Definition: Ring-Wrap: loop-back of traffic by the nodes adjacent to the failure.  As soon as the fault clears, the nodes that were wrapped due to this failure are unwrapped, and the system goes back to its normal functionality.

IPS (cont.): Important notes:  The IPS protocol is independent of the topology knowledge about the ring’s current state. The monitoring is done by signal processing and propagation. The signaling is done through sending certain IPS packets.  IPS packets are never wrapped.

IPS (cont.): IPS packet structure: IPS packet is mainly propagating the following information: 1) Originator address. 2) IPS request type – the nodes are propagating their request to the neighbors. The IPS requests that are relevant to our simulation: Forced Switch (FS) – in case of node addition to the ring. Signal Fail (SF) – when node discovers signal failure from one of it’s neighbors, it concludes that there is a fault in the ring somewhere between them. Wait To Restore (WTR) – when a node realizes, that the failure clears and it enters the WTR state and waits for a certain period. No Request (IDLE).

IPS (cont.): 3) Path Indicator – there are two path types: Short (SHORT_PATH) – the package sent to the adjacent neighbor on the ring that provides the access to the neighbor by one hop-count (in normal- functioning state). Long (LONG_PATH) – the package sent to the adjacent neighbor on the reversed ring from the one used in the short- path. 4) Status – indicates the state in which the initiating node situated. TRAFFIC_WRAPPED – the node is rerouting the received traffic. IDLE – the node is in normal-functioning state.

IPS (cont.): The states of IPS protocol The IPS protocol is allocating for each node one of the following states: Idle state – in this state the node is functioning normally, and ready to perform the protection switches (e.g. to wrap). The node is periodically sends IPS packets with an IDLE request to both rings. Pass-through state – in this state the node is not wrapped, but it’s forwarding the wrapped traffic. The node stops sending IDLE IPS packages in the direction to which the forwarding is done. Wrapped state – in this state wrap is present in the node.

IPS (cont.): A few examples of the IPS Protocol functioning:  Node failure and recovery.  Link failure and recovery.

IPS (cont.): The failure: node failure  All nodes functioning normally, they are in IDLE IPS state.  Node 4 detects a signal fail on the inner ring and becomes TRAFFIC_WRAPPED. Performs the traffic rerouting from the failed link. Sends the packets: SHORT_PATH, packet with request SF and IPS state TRAFFIC_WRAPPED on the outer ring. LONG_PATH, packet with request SF and IPS state TRAFFIC_WRAPPED on the inner ring.  Node 6 detects a signal fail on the outer ring and becomes TRAFFIC_WRAPPED. Performs the traffic rerouting from the failed link. Sends the packets: SHORT_PATH, packet with request SF and IPS state TRAFFIC_WRAPPED on the inner ring. LONG_PATH, sends packet with request SF and IPS state TRAFFIC_WRAPPED on the outer ring.  Other nodes receive the LONG_PATH SF requests, enter the pass-through mode.  The system reaches a stable state.

IPS (cont.): Node Recovery  Node 5 recovers, sending IDLE IPS (on both rings).  Node 4 discovers that the failure clears (inner ring), and it sets the WTR timer (to make sure that the failure is actually cleared). Sends packets: Outer ring, SHORT_PATH, packet with request WTR and IPS state TRAFFIC_WRAPPED. Inner ring, LONG_PATH, packet with the same parameters.  Node 6 discovers that the failure clears (inner ring), and it sets the WTR timer (to make sure that the failure is actually cleared). Sends packets: Inner ring, SHORT_PATH, packet with request WTR and IPS state TRAFFIC_WRAPPED. Outer ring, LONG_PATH, packet with the same parameters.  All the other nodes keep forwarding the traffic.  When the WTR timer times out on node 1, it unwraps, and transitions to state IDLE. Start sending IDLE IPS packets on both rings.  When the WTR timer times out on node 3, it unwraps, and transitions to state IDLE. Start sending IDLE IPS packets on both rings.  Upon receiving IDLE IPS packet, all the other nodes enters the IDLE state.  SYSTEM RECOVERED!

IPS (cont.): The failure: link failure  The nodes 7 and 8 are functioning normally, they are in IDLE IPS state..  Node 8 detects a signal fail (outer ring) and becomes TRAFFIC_WRAPPED. Performs the traffic rerouting from the failed link. Sends the packets: SHORT_PATH, sends packet with request SF and IPS state TRAFFIC_WRAPPED on the inner ring. LONG_PATH, sends packet with request SF and IPS state TRAFFIC_WRAPPED on the outer ring.  Node 7 receives a packet with SF request from node 8 on the inner ring (short-path request), becomes TRAFFIC_WRAPPED and performs traffic re- routing from the outer ring. Sends packets: SHORT_PATH, sends packet with IDLE request and IPS state TRAFFIC_WRAPPED on the outer ring (this message will probably won’t reach node 8, because of the failure). LONG_PATH, sends packet with SF request and IPS state TRAFFIC_WRAPPED on the inner ring.  All the other nodes receive the LONG_PATH SF requests, and enter the pass- through mode.  The system reaches a stable state.

IPS (cont.): Link Recovery  Node 8 discovers that the failure clears (outer ring), and it sets the WTR timer (to make sure that the failure is actually cleared). Sends packets: Inner ring, SHORT_PATH, packet with request WTR and IPS state TRAFFIC_WRAPPED. Outer ring, LONG_PATH, packet with the same parameters.  Node 7 receives the packet with the WTR request from node 8 on the inner ring (short path), and starting to wait to restore. Sends packets: Outer ring, SHORT_PATH, packet with request IDLE and IPS state TRAFFIC_WRAPPED. Inner ring, LONG_PATH, packet with request WTR and IPS state TRAFFIC_WRAPPED.  All the other nodes keep forwarding the traffic.  When the WTR timer times out on node 7, it unwraps, and becomes IDLE. Starts sending IDLE IPS packets on both rings.  Node 8 receives and IDLE IPS packet from node 7 (outer ring), unwraps, and starts sending IDLE packets (both rings).  Upon receiving IDLE IPS packet, all the other nodes also enters the IDLE.  SYSTEM RECOVERED!

Topology Discovery:  The main goal of the Topology Discovery is to select an appropriate ring to send the Data packet on.  Each node has a Topology structure in it, which contains all the nodes in the Ring and the destination to them on each ring.

Topology Discovery (cont.):  When node X is sending the Data packet to node Y, it first of all goes to the Topology Discovery which X contains and decides which ring is better to send the Data packet on. Afterwards, X sends to Y the Data Packet on the chosen ring.

Topology Discovery (cont.):  To support this, each node periodically sends out Topology Discovery Packets on both rings. It is empty at first. Each node, when receiving such a packet, attaches its MacBinding to it.  MacBinding contains all the needed information of that node: it contains its address, number of hops between it, and the origin node, and its wrap condition.  When the packet returns to the origin node, it has the MacBindings of all the nodes in the Ring. When node wants to send a Data Packet, it will use this information.

Topology Discovery (cont.):  The updating of the topology is done as follows:  When a node gets back its own Topology Packet it compares the information in it with the Topology that he has.  It will come to conclusion that the Topology of Ring has changed if the following happens:

Topology Discovery (cont.): 1. It receives its own Topology Packet and the Topology specified there is different from the one he has. Then he will update its “Temp Topology” – structure indicating that the topology may have changed. 2. It receives its own Topology Packet and the Topology specified there is same as the Temp Topology – meaning he got a different Ring topology twice. Only in this stage, the topology contained in the node will be flushed, and updated according the twice received new topology.

Topology Discovery (cont.):  This method enables to update the current topology of the Ring (which may have changed due to addition of station or link/station failure) and also reduces the possibility of a mistake and unnecessary updating (in case there was a certain delay or a mistake in some node, when stating its information into a MacBinding).

Topology Discovery (cont.):  In case the topology received by mistake, we don’t update it right away, but we wait to see if we receive it again, updating the Temp Topology only.  If we receive it again, it probably is the new changed topology of the Ring.  Then we update the Topology itself.

Simulator Presentation: