1 / 19

RSVP and implementation

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

bratt
Download Presentation

RSVP and implementation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related