RSVP and implementation Details for the lab RSVP

RSVP and implementation • Details for the lab

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…

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

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

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 Qo. S 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)

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 – (K+0. 5) * 1. 5 * R – If do not get refresh until then, remove the state – Accounts for the worse case jitter

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 (RFC 2961) 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

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”

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

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

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

Scalability • May have 100, 000 of LSPs – How do I handle the timers for the periodic refreshes? • Changes may affect 1, 000 s 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

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

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

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 A+B+C 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!

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

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

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

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