1. CS 672 1 Summer 2003 Lecture 8

2. CS 672 2 Summer 2003 Populating LFIB with LDP Assigned/Learned Labels Changes in the LFIB may be triggered routing or label advertisements events. Routing events corresponds e.g., IGP learns a new prefix or next hop for an existing prefix changes. Label advertisements corresponds to reception of Label Request and/or Label Mapping messages.

3. CS 672 3 Summer 2003 Summary - LDP Messages Address – is used to advertise its interfaces addresses on establishment of new LDP session or when interface comes up. Label Request – is used to request label-to-FEC mapping from a downstream LSR Label Mapping – is used to advertise label-to-FEC binding in response either to Label Request (DoD) or unsolicited (DU). Label Release – is used to inform the peer that the sender no longer needs a previously received or requested label. Label Withdraw – is used to withdraw a previously advertised label. Note – all LDP messages except Hello use TCP as a reliable transport.

4. CS 672 4 Summer 2003 Label Request Message The encoding for the Label Request Message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Label Request (0x0401) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5. CS 672 5 Summer 2003 Label Mapping Message The encoding for the Label Mapping Message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Label Mapping (0x0400) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6. CS 672 6 Summer 2003 RSVP Big Picture

7. CS 672 7 Summer 2003 Resource ReSerVation Protocol (RSVP) RSVP is a signaling protocol for requesting QoS for IP data flows. RSVP is NOT a routing protocol rather utilizes services of the unicast and multicast IP routing. RSVP messages are encapsulated in IP packets and hop-by-hop routed based on IP destination address. RSVP reservation requests are for simplex data flows. Two reservation requests are required for bi-directional data flows

8. CS 672 8 Summer 2003 RSVP Session RSVP session is described in terms three parameters (DestAddress, ProtocolId, DestPort) DestAddress  IP destination address of the data packets ProtocolId  IP protocol ID DestPort  Destination TCP/UDP port

9. CS 672 9 Summer 2003 Data Microflow A single instance of an application-to-application flow of packets which is identified by: Source IP address, Source Port, Destination IP address Destination Port

10. CS 672 10 Summer 2003 RSVP Reservation Model In RSVP, QoS reservation request is initiated by the receiver. Receiver-oriented reservation model is motivated by several factors e.g.: Scalability (need to support larger number of users in multicast applications) Flexibility (e.g., to support receivers with different media formats) When an application in the receiver has some data to send, a request is passed from application to the RSVP process (protocol stack) RSVP protocol builds a message to make a QoS request RSVP reservation request is carried to all routers along the reverse direction of data flow to the source each router along allocated/reserves the requested QoS

11. CS 672 11 Summer 2003 RSVP Reservation Model Sender R1 R2 R3 R2 Data flow Receiver RSVP Reservation Request

12. CS 672 12 Summer 2003 Differentiated QoS Mechanisms The requested QoS for a given data flow is enabled through set of mechanisms that are collectively referred to as traffic management functions. Connection Admission Control (CAC) CAC decides whether to accept or reject a reservation request. CAC is applies during signaling of the reservation request. Depending upon the router/switch architecture and the point of congestion, CAC function can be applied in ingress direction (e.g., ingress to switch fabric), egress (e.g., output link), or both ingress/egress points in the router/switch. Output link bandwidth CAC is the most widely used form.

13. CS 672 13 Summer 2003 Differentiated QoS Mechanisms Packet classification An entity that selects packets based on the contents of packet header according to defined rules. Metering (policing) The process of measuring the temporal (e.g., arrival rate) of a traffic stream selected by a classifier. Commonly used metering (policing) method is known as leaky-bucket algorithm. The metered traffic may be marked, shaped, or dropped.

14. CS 672 14 Summer 2003 Differentiated QoS Mechanisms Marking The process of setting the differentiated service (DS) code point (i.e., TOS field) in a packet based on defined rules. For example, if the traffic exceeds the negotiated SLA, it may be remarked with lower priority. Shaping The process of delaying packets within a traffic stream to cause them to conform to some predefined profile (or contract). For example, the egress traffic from a node may be shaped to leaky-bucket algorithm.

15. CS 672 15 Summer 2003 Differentiated QoS Mechanisms Packet Scheduling The process of delaying packets within a traffic stream to cause them to conform to some predefined profile (or contract). The process of packets transmission where the packet departure are scheduled based on priority and/or to enable share/guarantee bandwidth Examples of commonly used schedulers include:  Strict priority  Round-Robin (RR)  Weighted Round-Robin (WRR)  Weighted Fair Queuing (WFQ) Shaper is a special type of scheduler.

16. CS 672 16 Summer 2003 Guaranteed Service Guaranteed service requires end-to-end bandwidth and delay guarantees. For example, real-time applications such as voice need guaranteed service. Controlled-load service can tolerate certain level of packet loss and delay. Controlled-load service is expected to receiver better service than the traditional best effort services as the network load increases. For example, adaptive real-time applications fall under this category. Best-effort service does not require end-to-end bandwidth and delay guarantees. For example, data applications.

17. CS 672 17 Summer 2003 FLOWSPEC Object RSVP reservation request is described in terms of a pair of objects namely FLOWSPEC and FILTERSPEC. Collectively, this pair of objects are referred to as the flow descriptor. The FLOWSPEC object carries information that is required for making a reservation (from receiver’s perspective). When making a reservation for a guaranteed service, FLOWSPEC object contains traffic and QoS such as data rate and delay parameters.

18. CS 672 18 Summer 2003 FLOWSPEC Object TSpec specifies the traffic parameters such as peak data rate (p), token bucket rate (r) (i.e., average data rate), token bucket size (b) RSpec specifies the required level of QOS and consists of parameters such as rate R (bytes/sec) and a slack term (S) in microseconds TSpec is used to program metering or policing entity. RSpec is used to perform CAC and program the packet scheduler.

19. CS 672 19 Summer 2003 FLOWSPEC Object (guaranteed service) 31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a) | Unused | 10 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 2 (c) |0| reserved | 9 (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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | 130 (h) | 0 (i) | 2 (j) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 | Rate [R] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11 | Slack Term [S] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TSpec RSpec

20. CS 672 20 Summer 2003 FLOWSPEC Object (controlled-load service) TSpec 31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a) | reserved | 7 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 5 (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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+