1 / 32

Lecture 9

Lecture 9. FILTERSPEC Object. FILTERSPEC Object defines filters for selecting a subset of data packets in a session. In general, these filters can be specified in terms: sender IP address/port, higher-level protocols, or any fields in the packet header

tanika
Download Presentation

Lecture 9

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. Lecture 9

  2. FILTERSPEC Object • FILTERSPEC Object defines filters for selecting a subset of data packets in a session. In general, these filters can be specified in terms: • sender IP address/port, • higher-level protocols, or • any fields in the packet header • RSVP (current specification) restricts the filter definition to be based on: • Sender IP address • (optional) Source TCP/UDP port number

  3. FILTERSPEC Object • FILTERSPEC + Session information identifies the set of packets (i.e., flow) which is to receive the requested QoS in the FLOWSPEC Object (i.e., TSpec, RSpec). • In a given session, packets that do not match any of the specified filters are treated as a best-effort traffic. • FILTERSPEC is used to set the parameters in the packet classifier.

  4. FILTERSPEC Object +-------------+-------------+-------------+-------------+ | IPv4 SrcAddress (4 bytes) | +-------------+-------------+-------------+-------------+ | ////// | ////// | SrcPort | +-------------+-------------+-------------+-------------+

  5. Reservation Styles • RSVP reservation request also contains a set of options (collectively referred to reservation style). • RSVP has two kind of reservation options namely: • Reservation style option that selects the type of reservation is to be made for different senders within the same sessions. • Sender selection option that selects the list of senders that receive the requested QoS.

  6. Reservation Styles • Reservation style option may have following attributes: • distinct – i.e., create a separate reservation for each upstream sender. • shared – i.e., create a single reservation that is shared among all packets of selected senders. • Sender selection option may have following attributes: • explicit –i.e., the selection of senders is explicitly listed. In the case of explicit sender-selection reservation, each filter spec matches exactly one sender. • wildcard –i.e., no filter spec is used (all senders are eligible).

  7. Reservation Styles Reservation Distinct Shared Explicit Sender Selection Wildcard • Fixed Filter Style (FF) - separate reservation for each sender. • Wildcard Filter (WF) Style – means shared reservation for all upstream senders • Shared Explicit (SE) Style – means a single reservation is shared among a set of explicitly • identified senders.

  8. Sender 1 Receiver 1 Reservation by Sender 1 Reservation by Sender 2 Sender 2 Receiver 2 Fixed Filter (FF) Reservation

  9. Sender 1 Reservation for S1 Receiver 1 Shared reservation for S1 and S2 Sender 2 Reservation for S2 Receiver 2 Shared Explicit (SE) Reservation

  10. RSVP Messages • RSVP defines a number of messages for establishing establishing, maintaining, and releasing sessions. • RSVP currently defines following messages: • Path • Resv • PathErr • ResvErr • PathTear • ResvTear • ResvConf

  11. RSVP Message Formats 0 1 2 3 +-------------+-------------+-------------+-------------+ | Length (bytes) | Class-Num | C-Type | +-------------+-------------+-------------+-------------+ | | // (Object contents) // | | +-------------+-------------+-------------+-------------+ • Each message contains a common header. • Common header contains fields such as: • Vers - RSVP protocol version. Current version is 1. • Msg Type - A number identifying the message type. For example, = 1 means Path message, =2 Resv Message, …

  12. RSVP Objects • Each RSVP message consists of a fixed number header and a variable number of objects. • Each RSVP Object is in the form of Type Length Value (TLV). Object type is indicated in the Class-Num field. • RSVP has defined following Object types: • SESSION, RSVP_HOP, TIMER_VALUES, STYLE, FLOWSPEC, FILTER_SPEC, SENDER_TEMPLATE, SENDER_TEMPLATE, …

  13. RSVP Object Formats • Class-num identifies different classes e.g., 1= IPv4/UDP session, 2= IPv6/UDP session, 3=RSVP_HOP, … 0 1 2 3 +-------------+-------------+-------------+-------------+ | Length (bytes) | Class-Num | C-Type | +-------------+-------------+-------------+-------------+ | | // (Object contents) // | | +-------------+-------------+-------------+-------------+

  14. RSVP Objects • SESSION Object • Destination IP address, Protocol ID, Destination Port • RSVP_HOP Object • IP address of the message sender, Logical Interface Handle (LIH). • Used to route RSVP message in the reverse direction • TIMER_VALUES Object • Contain value of the refresh period values • STYLES Object • Reservation styles

  15. RSVP Objects • FLOWSPEC Object • Define the required QoS (i.e., RSPEC, TSPEC) • FILTER_SPEC Object • Selects subset of data packets that should get the requested QoS. • SENDER_TEMPLATE • Sender IP address, … • SENDER_TSPEC Object • Sender’s traffic parameters

  16. RSVP_HOP Object • In a PATH message (i.e., downstream direction), RSVP_HOP object carries the IP address of the node sending this message or the previous hop (PHOP) address. • In a RESV message (i.e., upstream direction), RSVP_HOP object carries the IP address of the node sending the RESV message. That is from the node receiving this message, it is the address of the next hop (NHOP).

  17. RSVP_HOP Object IPv4 RSVP_HOP object: Class = 3, C-Type = 1 +-------------+-------------+-------------+-------------+ | IPv4 Next/Previous Hop Address | +-------------+-------------+-------------+-------------+ | Logical Interface Handle | +-------------+-------------+-------------+-------------+

  18. SENDER_TSPEC • Specifies sender’s traffic parameters. This object is carried unchanged from RSVP sender to receiver. 31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a) | reserved | 7 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 1 (c) |0| reserved | 6 (d) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 127 (e) | 0 (f) | 5 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++++++++++++++

  19. PATH Messages • When an application in the sending node has some data to transmit, it triggers a request to the RSVP module. • The RSVP module in the sending node: • Builds the PATH message • PATH message contains objects such as: <Common Header><SESSION><RSVP_HOP><TIME_VALUES> <SENDER <_TEMPLATE><SENDER_TSPEC> … and optional objects • Sets source IP address = sender node’s address, destination IP address = receiver node’s address • Performs a CAC check. If CAC check passes, allocate (set aside but not reserved yet) resources such as bandwidth. • Sets the RSVP_HOP object = IP address of the outgoing interface. • Sends the Path message to the downstream RSVP neighbor.

  20. PATH Messages • The PATH message is hop-by-hop routed along the same path that would be taken by the data packets. • Upon receiving the PATH message, the downstream RSVP node: • Creates the Path State Block (PSB) that contains all PATH message related state information. • Stores information such as previous hop (PHOP) in the PSB. • Performs a CAC check. If CAC check passes, allocate (set aside but not reserved yet) resources such as bandwidth. • Sets the RSVP_HOP object = IP address of the outgoing interface. • Sends the Path message to the downstream RSVP neighbor.

  21. PATH Messages • The process of forwarding PATH message repeats until it reaches the destination (i.e., receiver node) • Note the SENDER_TSPEC is carried unmodified from the sender to the receiver. • If any errors occur during PATH message processing, a PathErr message is transmitted in the upstream direction towards the sender.

  22. RESV Messages • Based on information carried in the PATH message, the receiver determines the reservation parameters. • For requesting QoS, the receiver builds the RESV message • PATH message contains objects such as: <Common Header><SESSION><RSVP_HOP><TIME_VALUES> <FILTER_SPEC><FLOWSPEC> • Sets source IP address = IP address of the node originating RESV message, destination IP address = derived from RSVP_HOP in PSB. • This is how RESV message is steered along the path traversed by the corresponding PATH message in the opposite direction. • Performs a CAC check. If CAC check passes, reserve the resources.

  23. RESV Messages • Programs the classifier (based on FILTER_SPEC) and scheduler (based on RSpec). • Sets the RSVP_HOP object = IP address of the outgoing interface. • Creates the RESV State Block (RSB) • Sends the Path message to the Upstream RSVP neighbor • As the RESV message travels upstream, it creates RSB in each RSVP-capable node. • This process repeats until the RESV message arrives at the target destination (i.e., sender ) • If any errors occur during PATH message processing, a PathErr message is transmitted in the downstream direction towards the receiver.

  24. Soft State • RSVP creates its path (i.e., RSB) and reservation (i.e., RSB) state using initial PATH and RESV messages. • RSVP is based on soft state model which means it needs to be refreshed periodically. If not refreshed on time, the reservation state is removed. • Thus each RSVP node periodically refresh PATH and RESV messages on a hop-by-hop basis. • With the exception of certain flags, the PATH/RESV refresh messages are identically to the corresponding initial PATH/RESV messages. • If a node does not receive an appropriate PATH/RESV refresh messages within cleanout timeout, the corresponding PATH/RESV state is deleted. • RSVP uses periodic transmission of refresh messages to refresh its state and any packet loss.

  25. Refresh Reduction • As the number of sessions increase, • the number of PATH/RESV refresh messages that needs to be generated and processed also increase • In steady-state, RSVP soft state model may consume considerable processing and bandwidth resources • Some of the issues associated with refresh volume and unreliable message delivery can be addressed using refresh reduction mechanisms. • For example, use of summary refresh reduces amount of information that needs to be refreshed. • And message ACK allows detect of message loss.

  26. Path/Resv state refresh volume can be reduced via refresh reduction mechanisms Resv Refresh Message Path Refresh Message R2 R3 R4 R1 (Receiver) (Sender) Refresh Reduction

  27. Local Repair – next hop changes • As the next hop for certain destination changes, the data traffic packets will be routed along the newer path. • RSVP adapts accordingly and start sending PATH/RESV refresh messages along the new path to establish and maintain state. • One way to detect next hop change is based on comparison of RSVP_HOP objects. Depending upon refresh period, this method could be slower. • Alternatively, routing protocol notifies the next hop change to RSVP which then quickly adapts accordingly.

  28. RSVP adapts to the next hop change Resv Path Receiver Sender Local Repair – next hop changes

  29. RSVP TE Big Picture

  30. Extending RSVP for MPLS Tunnels • To support several functions related to establishment of traffic engineered MPLS tunnels, RSVP-TE (RFC 3209) extends the original RSVP protocol (RFC 2205). • Specifically, RSVP-TE extensions enable new set of capabilities such as: • Downstream-on-demand (DoD) label distribution mode. • Establishment of explicitly routed LSPs (tunnels) with or without reservation of QoS (e.g., bandwidth). • Re-optimization of established tunnels using a make-before-break approach. • Recording of the actual path traversed by the tunnel • Preemption options

  31. RSVP-TE Extensions • In order to support these capabilities, RSVP-TE specification (RFC 3209) defines following new objects such as: • LABEL_REQUEST Object (LRO) • LABEL Object • RECORD_ROUTE Object (RRO) • EXPLICT_ROUTE Object (ERO) • LSP_TUNNEL_IPv4 SESSION Object • LSP_TUNNEL_IPv4 SENDER_TEMPLATE Object • SESSION_ATTRIBUTE Object

  32. RSVP Vs. RSVP-TE • RSVP is used to request and reserve QoS for IP flows. • In contrast, RSVP-TE is used to establish/maintain MPLS tunnels with or without QoS reservation. • RSVP defines a session as a data flow with particular destination IP address and transport layer protocol (i.e., UDP/TCP port). • In contrast, RSVP-TE defines a session as a set of packets that are assigned the same label at the tunnel source (head). • Because each tunnel can aggregate multiple flows, the number of tunnels does not scale linearly with the number of flows. As a result, RSVP-TE is more scalable as compared with the RSVP.

More Related