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