RSVP and implementation

1
RSVP and implementation

• Details for the lab

2
RSVP messages

• PATH, RESV
• To setup the LSP
• PATHtear, RESVtear
• To tear down an LSP
• PATHerr, RESVerr
• For sending error messages downstream and
  upstream
• PATHconf, RESVconf
• Confirmation
• HELLO
• Hello? What hello? It is supposed to be soft
  state
• But in real life things are always more
  difficult

3
How to send PATH and RESV

• PATH follows the IGP next hop to the tunnel
  egress
• Unless superseeded by ERO
• For loose ERO hop follow IGP again
• Need ROUTER_ALERT
• RESV is always sent to the upstream hop (PHOP)
• EXAMPLE

4
Packet formats

• Packets use protocol IPPROT_RSVP (46)
• Basic definition in RFC2205, RFC3209
• Packet header
• Contains packet type, length, checksum, and RSVP
  TTL
• Packets contain a variable number of objects

5
Some important RSVP objects

• SESSION
• Contains information that identifies the LSP
• TIME_VALUES
• Contains information on when the LSPs will be
  refreshed
• FLOWSPEC
• This is used to carry QoS information, we will
  see it later
• RSVP_LABEL
• Carries the label information, appears in RESVs
• LABEL_REQUEST
• Asks for a label, appears in PATHs
• EXPLICIT_ROUTE
• Contains a source route (strict or loose)

6
Refreses

• PATHs and RESVs are sent periodically
• Each router repeats PATHs and RESVs independently
  from other routers
• Refresh based on refresh interval R and number of
  messages that can be lost before I delete state K
  
• Updates are sent with a 50 jitter
• Avoid network wide synchronization
• Routers remember state for
• (K0.5) 1.5 R
• If do not get refresh until then, remove the
  state
• Accounts for the worse case jitter

7
Refresh reduction

• Soft state has quite some limitations
• Can cause too much refresh traffic
• Can loose messages
• If a PATH is lost setting up an LSP may take long
  time
• If a RESVtear is lost tearing down an LSP may
  take long time
• If a router crashes, it will take long time to
  detect it
• Refresh reduction (RFC2961) undoes most of the
  soft state mechanism
• Bundling
• Multiple RSVP messages in a packet
• MESSAGE_ID(_ACK) objects
• Reliable messages
• Summary refreshes
• Send only the MESSAGE_IDs in the refresh messages

8
Identifiers for the LSPs

• May have multiple LSPs starting from the same
  ingress and terminating at the same egress
• Identify based on
• Ingress IP address (extended tunnel id in the
  SESSION object)
• Egress IP address (tunnel endpoint address in
  the SESSION object)
• Tunnel ID (in the SESSION object)
• Also LSP id
• In the SENDER_TEMPLATE object (for PATHs)
• In the FILTER_SPEC object (for RESVs)
• Multiple tunnels may belong to the same logical
  session
• Make before break

9
Using the LSPs

• If I am ingress use the LSP to reach some
  destination
• Load balance traffic among multiple LSPs
• Can share with unequal weights
• Advertise them in IGP and use them as links
• forwarding adjacencies
• LSP priority and pre-emption
• Setup priority
• Hold priority
• Make before break
• Avoid the impact on traffic when rerouting
• This is why a session may have multiple LSPs

10
Walkthrough of an RSVP implementation

• Basic data structures
• Interfaces
• Sessions
• Psb, rsb
• Multiple per session
• Upstream and downstream nhops
• Where to send the packets
• They may change
• If I have a loose ERO
• And the IGP best path changes

11
RSVP tasks

• Allocate and add labels to the LFIB
• Generate refreshes
• Need to avoid synchronization
• Track interface changes to adapt the LSPs
• Add/del/up/down
• May bring down (RESVtear) or reroute
• EXAMPLE
• Track IGP changes to adapt the LSPs
• May reroute
• EXAMPLE

12
Scalability

• May have 100,000 of LSPs
• How do I handle the timers for the periodic
  refreshes?
• Changes may affect 1,000s of LSPs
• If an interface goes down or a nhop changes
• May take long time to process all the LSPs
• Must schedule properly so that I do not neglect
  other duties
• May generate too many messages
• Must pace properly so I do not cause network
  spikes and lost messages
• Must schedule properly so I do not neglect other
  interfaces
• Must schedule properly so I do not neglect other
  tasks
• May receive storms of packets
• Must schedule so I do not neglect other
  interfaces
• Must schedule so I do not neglect other tasks

13
Control Flow

• Usually actions are triggered because of
• Reception of a protocol packet
• Reception of a PATH message
• Timer expiration
• E.g. sending a refresh
• External event
• Interface up/down
• Next hop up/down/change

14
Basic Design principle

• Isolate the pieces of work
• Different event handlers
• Different threads
• And keep a well defined interface between them
• Usually queues
• This keeps the code cleaner and simpler
• Can follow the worker model
• Check for work
• Process a piece of work
• Repeat or sleep
• Amount of work to be done is predictable

15
Why break down work

• Say that for each incoming packet I have to do 3
  pieces of work A, B, C
• For example (A parse packet and check for
  errors, B create session state, C create
  output packet and send it out)
• Option 1 Do ABC in one big function/handler
• If something slows down C (for example packet
  pacing forces me to send packets out slowly) then
  everything slows down
• I will have to drop incoming packets
• All processing is done at the pace of the slowest
  component
• I may have a lot of CPU available but I still
  drop incoming packets!

16
Why continued

• Option 2 Do A, B, C in separate handlers, with
  queues of packets between them
• Then if C is slow, I can still continue accepting
  packets and doing A and B.
• If C is tooo slow then the queue between B and C
  will fill up and will have to slow down B and
  eventually A
• But for transient bursts of packets this will
  work better
• I will be able to accept and process packets
• Packet will be queued internally until C can
  clear the backlog

17
Example packet recv/processing

• Each incoming packet will trigger some action
• I do not want to perform this action inside the
  packet read handler
• May take variable time, trigger other actions etc
  and make my code complex
• Isolate packet reception from packet processing
• Read packet
• Do some basic checks, parse
• drop early if errors or I am overloaded
• Put it in some queue
• A separate handler will pick it up from the queue
  and process it

18
Example processing/packet tx

• I do not want to mix processing with sending
  packets
• Processing handlers will generate packets for
  sending
• queue the packets to be sent and a different
  handler will actually send them

19
Event design

• GRAPH
• Packet read handler
• Reads packets into read queues
• Packet send handler
• Sends packets from send queues
• Timer handler
• Processing handler
• Processes incoming packets
• updates state
• Generates outgoing packets
• Interface handler
• Interface up/down/add/delete
• Nhop handler
• Nhop add/del/up/down