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 –(K+0.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 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!

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