Resilient packet ring

Resilient packet ring

• IEEE 802.17 resilient packet ring (RPR)

– RPR targets metro edge & metro core areas
– RPR aims at combining
• SONET/SDH’s carrier-class functionalities of high
availability, reliability, and profitable TDM service (voice)
support
• Ethernet’s high bandwidth utilization, low equipment cost,
and simplicity
– RPR vs. SONET/SDH & Ethernet
• Similar to SONET/SDH rings, RPR provides fast recovery
from single link or node failure within 50 ms & carries
legacy TDM traffic with high-level QoS
• Similar to Ethernet, RPR exhibits improved bandwidth
utilization due to statistical multiplexing
• Unlike SONET/SDH rings, RPR utilizes full ring bandwidth
under normal (failure-free) operation
• Unlike Ethernet, RPR provides fairness
Resilient packet ring

• Architecture
– Bidirectional packet-
switched ring with
counterrotating fiber
ringlets 0 and 1
– Up to 255 ring nodes
– RPR MAC over several
physical layers (e.g.,
Ethernet, SONET/SDH)
– Shortest path routing
unless preferred ringlet
specified by MAC client
– Destination stripping
enables spatial reuse
=> increased capacity
Resilient packet ring

• Packet forwarding
– Intermediate nodes forward packet if they don’t
recognize destination MAC address in packet header
– Forwarding methods
• Cut-through
– Packet forwarded before completely received
• Store-and-forward
– Packet forwarded after completely received
– Supplementary 1-byte time-to-live (TTL) field
• Added to each packet by RPR MAC control entity
• Value decremented by each intermediate node
• Prevents packets with unrecognized destination MAC
address from circulating forever
Resilient packet ring

• Multicasting
– Multicast group member-
ship identified by group
MAC destination address
– Realized by means of
broadcasting => no spatial
reuse
– Unidirectional flooding
• Packet removal based on
expired TTL or matching
source MAC address
– Bidirectional flooding
• Packets removal at
cleave point based on
expired TTL
• Cleave point can be put
on any span
Resilient packet ring

• Topology discovery
– RPR’s topology discovery protocol determines
connectivity, order of nodes, and status of each link
– At system initialization
• All nodes broadcast topology discovery control
packets on both ringlets with TTL value equal to 255
(maximum number of nodes)
• Each topology control packet contains information
about status of corresponding node & its attached
links
• By receiving all topology control packets, each node is
able to compute complete topology image (number &
ordering of nodes, status of each link)
• Topology image is stored in topology database of each
node
Resilient packet ring

• Topology discovery
– During normal operation
• Topology discovery packet is sent immediately by a
– New node inserted into ring
– Node after detecting link/node failure
– Node after receiving topology discovery packet
inconsistent with its current topology image
• Ripple effect
– First node noticing a topology change sends topology
discovery packet, followed by all other nodes
• Consistency check
– Once topology image is stable for specified time period,
each node performs consistency check
• Robustness
– After achieving stable & consistent topology image, each
node continues to periodically send topology discovery
packets
Resilient packet ring

• Topology discovery
– Use of topology database
• Determining number of hops between source &
destination nodes
• Setting TTL field to appropriate value
• Selecting shortest path to any destination node
Resilient packet ring

• Node architecture
Resilient packet ring

• Node architecture
– Salient features
• Virtual output queueing (VOQ) to avoid head-of-line
(HOL) blocking
• Ingress traffic throttled by means of token bucket
traffic shapers
• Lossless transit path
– Single-queue mode
» Single FIFO queue called primary transit queue (PTQ)
to store class A in-transit traffic
– Dual-queue mode
» Additional FIFO queue called secondary transit queue
(STQ) to store class B & C in-transit traffic
– RPR network may consist of both single-queue &
dual-queue nodes
• Checker, scheduler, and traffic monitor
Resilient packet ring

• Traffic classes
– Class-based priority scheme to achieve QoS support &
service differentiation
– Traffic classes & subclasses
• Class A: Low-latency & low-jitter service with guaranteed
bandwidth
• Class B: Predictable latency & jitter service
• Class C: Best-effort

Traffic class Subclass Bandwidth preallocation

A A0 Reserved
A1 Reclaimable
B B-CIR Reclaimable
B-EIR No preallocation
C - No preallocation
Resilient packet ring

• Bandwidth preallocation
– To fulfill service guarantees, bandwidth preallocated for
traffic subclasses A0, A1, and B-CIR
• Subclass A0
– Reserved bandwidth
– Reservation done by using topology discovery protocol
– Reserved bandwidth dedicated to node making reservation
• Subclasses A1 & B-CIR
– Part of unreserved bandwidth preallocated to subclasses
A1 & B-CIR => reclaimable bandwidth
– Reclaimable bandwidth not used by A1 & B-CIR (as well as
remaining unreserved bandwidth) can be used by
subclasses B-EIR & C
• Subclasses B-EIR & C
– No bandwidth preallocation
– Fairness eligible traffic
Resilient packet ring

• Access control
– Single-queue mode
• Highest priority given to local control traffic if PTQ not full
• Without local control traffic, in-transit traffic is given
priority over local ingress traffic
– Dual-queue mode
• Highest priority given to local control traffic if both PTQ &
STQ not full
• Without local control traffic, PTQ always served first
• If PTQ empty, local ingress traffic served until STQ reaches
certain threshold
• If STQ threshold crossed, STQ in-transit traffic is given
priority over local ingress traffic
– Benefits
• Lossless transit path for all traffic classes
• Class A traffic experiences only propagation delay &
occasional queueing delay due to nonpreemptive scheduling
Resilient packet ring

• Fairness control
– Lossless path property gives rise to starvation of down-
stream nodes => fairness problem
– Distributed fairness control protocol
• Dynamically throttling upstream traffic
• Maximizing spatial reuse
Resilient packet ring

• RIAS reference model

– Fairness control designed according to ring ingress
aggregated with spatial reuse (RIAS) reference model
– RIAS reference model
• Fairness on each link is determined at granularity of ingress
aggregated (IA) flow (only traffic subclasses B-EIR & C)
• IA flow: aggregate of all flows originating from a given
ingress node
• Goals
– Throttle IA flows at ring ingress nodes to their
network-wide fair rates => alleviated congestion
– Let unused bandwidth be reclaimed by IA flows
=> maximized spatial reuse
• Fairness control realized by backlogged nodes sending
fairness control packets based on local measurements to
upstream ring nodes
Resilient packet ring

• Fairness control algorithm

– Framework
• Each node measures forward_rate & add_rate as byte counts
at output of scheduler
– Forward_rate: serviced rate of all in-transit traffic
– Add_rate: serviced rate of all local traffic
• Both traffic measurements are
– taken over prespecified time period called aging_interval
– low-pass filtered by means of exponential averaging using
parameter 1/LPCOEFF for current measurement &
1 - 1/LPCOEFF for previous average
• Measurements are used by nodes to detect local congestion
• When node n is congested, it calculates its local_fair_rate[n]
• Congested node n sends fairness control packet containing
local_fair_rate[n] to upstream nodes
• Upstream nodes sending via n throttle their traffic to fair rate
• When congestion clears, all nodes periodically increase rate
Resilient packet ring

• Local_fair_rate
– Local_fair_rate[n] of congested node n denotes fair rate
at which source nodes are supposed to transmit via
intermediate node n
– Congested node n sends fairness control packet
containing local_fair_rate[n] to upstream node n-1
– If node n-1 is also congested, it forwards fairness
control packet to upstream node n-2 containing
min {local_fair_rate[n], local_fair_rate[n-1]}
– If node n-1 is not congested but its forward_rate >
local_fair_rate[n], it forwards fairness control packet to
upstream node n-2 containing local_fair_rate[n]
– Otherwise, node n-1 sends null-value fairness control
packet to indicate lack of congestion
Resilient packet ring

• Allowed_rate_congested
– When upstream node i receives fairness control packet with
local_fair_rate[n], it decreases rate controller value of all
flows traversing congested node n to allowed_rate_congested
– Allowed_rate_congested equals sum of serviced rates of all
flows (i,j) originating from node i & traversing node n on their
path toward destination node j => local traffic rates of
upstream node i does not exceed local_fair_rate[n]
– Otherwise, if upstream node i receives null-value fairness
control packet, it increases allowed_rate_congested by
prespecified value to reclaim bandwidth
Resilient packet ring

• Operation modes
– Fairness control algorithm operates in either of two
operation modes
• Aggressive mode (AM)
• Conservative mode (CM)
– Both AM & CM operate within the same aforementioned
framework
– AM & CM differ in how node detects congestion &
calculates its local fair rate
Resilient packet ring

• Aggressive mode (AM)

– AM is default operation mode of RPR deploying dual-
queue mode
– Operation
• Node n is considered congested whenever

STQ_depth[n] > low_threshold

or
forward_rate[n] + add_rate[n] > unreserved_rate

• A congested node n calculates its local_fair_rate[n]

as the serviced rate of local traffic add_rate
Resilient packet ring

• Conservative mode (CM)

– CM deploys single-queue mode by default
– Each node uses access timer
– Operation
• Node n is considered congested whenever access
timer expires or
forward_rate[n] + add_rate[n] > low_threshold
• If node n is congested only in current aging_interval:

local_fair_rate[n] = unreserved_rate/# of active nodes

• If node n is continuously congested:
– local_fair_rate[n] ramps up if
forward_rate[n] + add_rate[n] < low_threshold
– local_fair_rate[n] ramps down if
forward_rate[n] + add_rate[n] > high_threshold
Resilient packet ring

• Protection
– Due to bidirectional dual-fiber ring topology, RPR is able
to recover from single link or node failure
– Fault detection
• Alarm signal issued by underlying physical layer technology
(e.g., loss-of-signal (LOS) alert in SONET/SDH)
• No keep-alive messages from neighboring node for pre-
specified period of time
– Fault notification
• Upon fault detection, node broadcasts topology discovery
update packet to inform all ring nodes about failure
– Fault recovery
• RPR deploys two protection techniques
– Wrapping (optional)
– Steering (mandatory)
Resilient packet ring

• Wrapping
– Optional in RPR
– If deployed, all nodes
must support it
– Similar to automatic
protection switching
(APS) of SONET/SDH
self-healing rings (SHRs)
– Affects only packets
marked wrap eligible
(we bit in header is set)
– Benefits
• Fast recovery time
• Minimized packet loss
– Drawback
• Bandwidth inefficiency
Resilient packet ring

• Steering
– Mandatory in RPR
– After receiving a topo-
logy discovery update
packet sent by wrapping
node, a source node sends
local ingress traffic on
the ringlet in failure-free
direction
– Benefit
• Higher bandwidth
efficiency than wrapping
– Wrap-then-steer
protection strategy
• recommended if both
wrapping & steering used
together =>
packet reordering
Resilient packet ring

• In-order delivery
– RPR deploys two packet modes
• Strict packet mode (default)
– Packets guaranteed to arrive in same order as sent
– Strict order (so) bit in header is set to identify strict
order packets
– Strict order packets cannot be marked wrap eligible
=> discarded at wrap point
– After learning about failure, nodes stop sending strict
order packets & discard strict order in-transit packets
until topology stabilization timer expires
– With stable & consistent updated topology image, nodes
start to steer strict order packets onto respective ringlet
• Relaxed packet mode (optional)
– Relaxed packets may be steered immediately after learning
about failure & are not discarded from transit queues