Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Chapter 7: Label Distribution Protocols TOPICS – LDP – CR-LDP – RSVP – RSVP-TE Connection-Oriented Networks - Harry Perros 1 • MPLS requires a set of procedures for the reliable distribution of label bindings between LSRs. • MPLS does not require a single label distribution protocol. • LDP/CR-LDP and RSVP-TE are the most popular label distribution protocols Connection-Oriented Networks - Harry Perros 2 The Label Distribution Protocol (LDP) TOPICS: - Label spaces, hello adjacencies and sessions - LDP PDU format - LDP messages and formats Connection-Oriented Networks - Harry Perros 3 LDP peers • Two LSRs that use LDP to exchange labels and FEC mapping information are known as LPD peers. • Two LDP peers exchange information over an LDP session. • Several different LDP messages have been defined. Connection-Oriented Networks - Harry Perros 4 LDP messages • Four categories of messages have been defined, namely: – Discovery messages – Session messages – Advertisement messages – Notification messages Connection-Oriented Networks - Harry Perros 5 • Discovery messages provide a mechanism whereby LSRs indicate their presence by sending a hello message periodically. • Session messages are used to establish, maintain, and terminate an LDP session • Advertisement messages are used to create, change, and delete label mappings to a FEC. • Notification messages are used to provide advisory information and to signal error information. Connection-Oriented Networks - Harry Perros 6 Forward Equivalent Class (FEC) • Each FEC comprises one or more FEC elements. • Each FEC element identifies a set of packets which may be mapped to the corresponding LSP. • FEC element: Address prefix – This is the most common type of FEC. It is an address prefix of any length from 0 to a full address that represents an IP subnet. • FEC element: Host address – This type is a full host address. When the traffic is destined to a specific host, an LSP can be created for that host address FEC. Connection-Oriented Networks - Harry Perros 7 Label space • The label space is the set of all labels. • There is a common label space for all interfaces where IP packets carry the shim header (i.e. POS, GbE interfaces), known as per platform label space. Connection-Oriented Networks - Harry Perros 8 LDP identifiers • This is a six-byte quantity and it is used to identify the LSR label space – The first four bytes carry a globally unique value identifying the LSR, such as a 32-bit router id that has been assigned to the LSR by the AS administrator. – The last two octets identify a label space. If the label space is per platform, then the last two octets are set to zero. • An LDP id (often referred to as a label space id) is expressed as <LSRid: label space number> Connection-Oriented Networks - Harry Perros 9 LDP sessions between two non-directly connected LSRs. • An LDP session maybe desirable between two non-directly connected LSRs. • For instance, two distant LSRs, LSRa and LSRb, may communicate via an LSP. Label stacking is used as well. LSRa can establish a session to LSRb to exchange labels which are pushed down the stack, per example in MPLS presentation Connection-Oriented Networks - Harry Perros 10 LDP sessions • An LDP session is set-up between two directly connected LSRs, to support the exchange of LDP messages between them. • An LDP session between two LSRs is associated with a label space. Connection-Oriented Networks - Harry Perros 11 LDP runs over TCP/UDP • For reliability, an LDP session runs on top of TCP. When multiple LDP sessions are required between two LSRs, there is one TCP session of each LDP session. • LDP discovery messages (i.e., hello messages), however, run over UDP. Connection-Oriented Networks - Harry Perros 12 LDP discovery • This is a mechanism that enables an LSR to discover potential LPD peers, i.e., other LSRs, which are directly connected to it. • An LSR sends periodically LDP link hellos out of each interface. Hello packets are sent over UDP addressed to a well-known LDP discovery port for the “all routers on this subnet” group multicast address. Connection-Oriented Networks - Harry Perros 13 • An LDP link hello sent by an LSR carries the LDP id for the label space the LSR wants to use for the interface, and possibly additional information. • Receipt of an LDP link hello identifies a hello adjacency. For each interface, there is one hello adjacency. Connection-Oriented Networks - Harry Perros 14 Extended discovery mechanism • This is used for non-directly connected LSRs. • An LSR periodically sends LDP targeted hellos to a specific address, over UDP. • Receipt of an LDP targeted hello identifies a hello adjacency. Connection-Oriented Networks - Harry Perros 15 Establishing an LDP session • The exchange of LDP link hellos between two LSRs, triggers the establishment of an LDP session. • Single link between two LSRs: single hello adjacency and a single LDP session. • Parallel links with per platform label space: as many hello adjacencies as the number of links, but one LDP session. Connection-Oriented Networks - Harry Perros 16 • The establishment of an LDP session involves the following steps: – First, a TCP session is established. – Then, an LDP session is initialized, during which the two LSRs negotiate session parameters, such as: protocol version, label distribution method, timer values, etc. Connection-Oriented Networks - Harry Perros 17 Maintaining hello adjacencies • An LSR maintains a timer for each hello adjacency, which it restarts each time it receives a hello message. • If the timer expires without receiving a hello message from the peer LSR, the hello adjacency is deleted. If all hello adjacencies associated with an LDP session are deleted, the LDP session is terminated. Connection-Oriented Networks - Harry Perros 18 Maintaining LDP sessions • An LSR maintains a keepAlive timer for each peer session. • The timer is reset each time it receives an LDP PDU (any PDU) from its LDP peer. If the LDP peer has nothing to send, it sends a keepAlive message. Connection-Oriented Networks - Harry Perros 19 LDP PDU format LDP header LDP message 1 . . . LDP message N Connection-Oriented Networks - Harry Perros An LDP PDU consists of an LDP header followed by one or more LDP messages, which may not be related to each other. 20 The LDP PDU header 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 Version PDU length LDP identifier Version: LDP protocol version (currently version 1) PDU length: Total length in bytes excluding the version and PDU length fields. Maximum = 4096 bytes LDP identifier (label space id): <32-bit router id, label space number> Connection-Oriented Networks - Harry Perros 21 LDP messages • Each LDP message consists of a header followed by mandatory and optional parameters. • The header and the parameters are all encoded using the type-length-value (TLV) scheme. Connection-Oriented Networks - Harry Perros 22 TLV structure 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 U F Type length . . . Value • U: Unknown TLV bit. . – It is used when an unknown TLV is received. If U=0, a notification is returned to the message originator and the entire message is ignored. If U=1, the TLV is silently ignored and the rest of the message is processed as if the TLV did not exist • F: Forward unknown TLV bit. – This bit applies only when U=1, and the LDP message containing the unknown TLV has to be forwarded. If F=0, the unknown TLV is not forwarded with the rest of the message. If F=1, the unknown TLV is forwarded with the rest of the message Connection-Oriented Networks - Harry Perros 23 TLV structure (continued) 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 U F Type length . . . Value • Type: Encodes how the value field is to be interpreted • Length: Specifies the length of the value field in bytes • Value: Contains information which is interpreted as specified in the type field. It may contain TLV encoding itself! Connection-Oriented Networks - Harry Perros 24 LDP messages 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 U Message type Message length Message ID Mandatory parameters Optional parameters U: Unknown message bit. Upon receipt of an unknown message, if U=0, a notification is returned to the message originator. If U=1, the unknown message is silently ignored. Message type: Identifies the type of message Message length: Total length in bytes of message ID field and the mandatory and optional parameters fields Message ID: A 32-bit value used to identify this message. Subsequent messages related to this one have to carry the same message ID. Connection-Oriented Networks - Harry Perros 25 LDP messages: • • • • • • Notification Hello Initialization KeepAlive Address Address withdraw Connection-Oriented Networks - Harry Perros • • • • • Label mapping Label request Label abort request Label withdraw Label release 26 Notification message • It is used to inform an LDP peer of a fatal error or to provide advisory information re. the outcome of processing an LDP message or the state of an LDP session. Some of the notification messages are: – Malformed PDU or message – Unknown or malformed TLV – Session KeepAlive timer expiration – Unilateral session shutdown – Initialization message events – Events resulting from other errors Connection-Oriented Networks - Harry Perros 27 Hello message • LDP hello messages are exchanged for discovering LDP adjacencies. • Hello messages maybe either link hellos or targeted hellos. • The message type field in the LPD PDU header indicates it is a hello message. Connection-Oriented Networks - Harry Perros 28 Hello message structure 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 Hello (0x0100) Message length Message ID Common hello parameters TLV Optional parameters Connection-Oriented Networks - Harry Perros 29 Common hello parameters TLV 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 0 Common hello parameters Hold time length T R Reserved • Hold time: – It specifies the hello hold time in seconds. This is the time that the the sending LSR will maintain its record of hellos from the receiving LSR without receipt of another hello. – If hold time=0, then the defaulted value is used, which is 15 sec for link hellos and 45 sec for targeted hellos. A value of 0xffff means infinite. – The hold timer is reset each time a hello message is received. If it expires before a hello message is received, the hello adjacency is deleted. Connection-Oriented Networks - Harry Perros 30 Common hello parameters TLV (Continued..) 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 0 Common hello parameters Hold time length T R Reserved • T: – It specifies if it is a targeted hello (T=1) or a link hello (T=0). • R: – This field is known as the request send targeted hellos. A value of 1 indicates that the receiver is requested to send periodic targeted hellos to the source of this hello. A value of 0 makes no such request. Connection-Oriented Networks - Harry Perros 31 Initialization message • This is the most complex LDP message, and it is used to request the establishment of an LDP session. • Several important parameters are specified in this message. Connection-Oriented Networks - Harry Perros 32 Initialization message structure 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 Initialization (0x0200) Message length Message ID Common session parameters TLV Optional parameters Connection-Oriented Networks - Harry Perros 33 Common session parameters TLV 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 0 Common session parameters KeepAlive time Protocol version A D Reserved length PVLim Max PDU length Receiver LDP identifier • KeepAlive time: It indicates the maximum number of seconds that may elapse between the receipt of two successive LDP PDUs. The KeepAlive timer is reset each time an LDP PDU is received. Connection-Oriented Networks - Harry Perros 34 • A: It indicates the type of label advertisement. Downstream unsolicited (A=0), or downstream on demand (A=1). • D: It is used to enable loop detection • PVLim (Path vector limit): Gives the maximum number of LSRs recorded in the path vector used for loop detection. • Max PDU length: Defaulted value of the maximum allowable length is 4096 bytes. • Receiver LDP identifier: Identifies the receiver’s label space Connection-Oriented Networks - Harry Perros 35 Address message and address withdraw message • Before sending label mapping and label request messages, an LSR advertises its interface addresses using the address messages. • Previously advertised addresses can be withdrawn using the address withdraw message. Connection-Oriented Networks - Harry Perros 36 Label mapping message • An LSR uses this message to advertise to its LDP peers a binding of a label to a FEC. • The message consists of two mandatory TLVs: – FEC TLV – Label TLV Connection-Oriented Networks - Harry Perros 37 Label message structure 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 Connection-Oriented Networks - Harry Perros 38 FEC TLV 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 0 FEC (0x0100) length FEC element 1 ... FEC element n • A FEC element is one of the FECs, such as: address prefix, host address Connection-Oriented Networks - Harry Perros 39 Label TLVs 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 0 Generic label length Label Connection-Oriented Networks - Harry Perros 40 Label request message 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 An LSR sends a label request message to an LDP peer to request a binding (i.e., mapping) for a FEC. Connection-Oriented Networks - Harry Perros 41 An LSR may transmit a request message under the following conditions: – The LSR recognizes a new FEC via the forwarding table, and the next hop is an LDP peer, and the LSR does not already have a mapping from the next hop for the given FEC. – The next hop to the FEC changes, and the LSR does not already have a mapping from the next hop for the given FEC. – The LSR receives a label request for a FEC from an upstream LDP peer, the FEC next hop is an LDP peer, and the LSR does not already have a mapping from the next hop. Connection-Oriented Networks - Harry Perros 42 The Constrained-based Routing - Label Distribution Protocol (CR-LDP) TOPICS – CR-LSP – CR-LSP setup procedure – The label request message – The label mapping message – The traffic parameters TLV Connection-Oriented Networks - Harry Perros 43 A constrained-routed label-switched path • CR-LDP is a signalling protocol based on LDP. • It is used to set-up a unidirectional point-to-point LSP, referred to as constrained-routed labelswitched path (CR-LSP). • A CR-LSP is analogous to an ATM point-to-point connection, only it is unidirectional. • A bidirectional LSP is setup by creating two separate LSPs, one in each direction. Connection-Oriented Networks - Harry Perros 44 CR-LSP • An LSP is set-up as a result of the routing information in an IP network using the shortest path algorithm. • A CR-LSP is calculated at the source LSR based on criteria not limited to routing information, such as explicit routing and QoS-based routing. • The route is then signaled to the other nodes along the path. • This routing technique is known as source routing. Connection-Oriented Networks - Harry Perros 45 C B D A G E F • In this MPLS network, router A wants to set-up a CR-LDP (i.e., a point-to-point unicast connection) to router G. • A calculates a path through the network that – – – – may minimize the number of hops (as in LDP), or it may minimize the total end-to-end delay, or it may maximize throughput, or path is pre-calculated to achieve load-balancing, etc. • It then uses CR-LDP messages to set-up the connection through the MPLS network. Connection-Oriented Networks - Harry Perros 46 CR-LDPs, therefore, can be used for a variety of reasons, such as: – Evenly distribute traffic among links by moving some of the traffic from highly utilized links to less utilized links (load balancing), – create tunnels for MPLS-based VPNs, – introduce routes based on a QoS criterion, such as minimum number of hops, minimum total endto-end delay, and maximum throughput. Connection-Oriented Networks - Harry Perros 47 Some CR-LDP features • It is based on LDP, and it runs on top of TCP for reliability. • The CR-LDP state-machine does not require periodic refreshment. • Strict and loose explicit routes – This allows the source node some degree of imperfect knowledge about the network topology Connection-Oriented Networks - Harry Perros 48 • Route pinning – Fixes the path through a loosely defined route, so that it does not change when a better next hop becomes available. • Specification of traffic parameters – The peak rate, committed rate, and service granularity can be specified. Policers are also used at the ingress. Connection-Oriented Networks - Harry Perros 49 • CR-LSP preemption – If a route for a high-priority CR-LSP cannot be found, existing CR-LSPs with a lower priority may be rerouted to permit the higher-priority CR-LSP to be established. • Resource class – The network operator may classify network resources in various ways. These classes are also known as “colours” or “administrative groups”. When a CR-LSP is established, the resource class it can draw from has to be established. Connection-Oriented Networks - Harry Perros 50 LDP support • CR-LDP requires the following LDP messages: – Basic/Extended discovery messages – Label request message for downstream on demand with ordered control – Label mapping message for downstream on demand with ordered control – Notification messages – Withdraw and release messages – Loop detection (for loosely routed segments) Connection-Oriented Networks - Harry Perros 51 CR-LSP setup procedure • A CR LSP is setup using downstream-on-demand allocation with ordered control. • A request at an ingress LSR to setup a CR-LSP might originate from a management system or an application. • The ingress LSR calculates the explicit route (using information provided by the management system, or the application, or from a routing table) and creates the label request message. Connection-Oriented Networks - Harry Perros 52 • The explicit route is a series of abstract nodes (nodes or autonomous systems) carried in an ERTLV. • The ingress LSR sends the label request message to the first LSR indicated in the ER-TLV. • The receiving LSR forwards the label request message to the next LSR in the ER-TLV, and so on until the message reaches the egress LSR. • The egress LSR returns a label mapping message that will traverse the path in the opposite direction. Connection-Oriented Networks - Harry Perros 53 An example of how a CR-LSP is setup A B C D E Label request message Time Label mapping message Connection-Oriented Networks - Harry Perros 54 The label request message 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 Message length FEC TLV Message id LSPID TLV (mandatory) ER-TLV (optional) Pinning TLV (optional) Traffic TLV (optional) Resource class TLV (optional) Preemption TLV (optional) Connection-Oriented Networks - Harry Perros 55 LSPID TLV • The LSPID is a unique identifier of a CR-LSP. • It is composed of the ingress LSR router ID (or any of its own IPv4 addresses) and an CR-LSP id which is locally unique to that LSR. • The LSPID is useful in – network management. – it can also be used in an already established CR-LSP as a hop in an ER-TLV – In CR-LSP repair Connection-Oriented Networks - Harry Perros 56 FEC TLV • A new FEC element is introduced in CR-LDP to support CR-LSPs • A FEC TLV with a type CR-LSP, is a CR-LSP FEC TLV. • One of the other FEC TLVs introduced in LDP may be also used. Connection-Oriented Networks - Harry Perros 57 Explicit route TLV (ER-TLV) 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 0 Type (0x0800) ER-hop TLV 2 … ER-hop TLV n length ER-hop TLV 1 • One or more ER-hop TLVs can be defined Connection-Oriented Networks - Harry Perros 58 Explicit route hop TLV (ER-hop TLV) 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 0 Type L length Value // • Type: IPv4 prefix, IPv6 prefix, autonomous system number, LSPID • Length: specifies the length of the value field • L bit: Set to 1, if it is a loose ER-hop, or to 0 if it is a strict ER-hop • Value: A variable-length field that contains the node (or the abstract node) that is part of the CR-LSP. Connection-Oriented Networks - Harry Perros 59 The label mapping message 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 Message length FEC TLV Label TLV Message id Label request message id TLV Traffic TLV (optional) LSPID TLV (optional) Connection-Oriented Networks - Harry Perros 60 Traffic parameters TLV 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 0 length Type (0x0810) Flags Frequency Reserved Peak burst size (PBS) Weight Peak data rate (PDR) Committed data rate (CDR) Excess burst size (EBS) Committed burst size Connection-Oriented Networks - Harry Perros 61 Peak rate: PDR, PBS • Peak rate: This is the maximum rate expressed in bytes/second at which traffic is sent to the CRLDP. • It is defined is terms of a token bucket P – The maximum token bucket size is set equal to the peak burst size (PBS), expressed in bytes. – The token bucket is replenished at a rate equal to the peak data rate (PDR), expressed in bytes/sec. Connection-Oriented Networks - Harry Perros 62 Token bucket operation • Initially, the token count Tp=PBS. • Let PDR = N bytes/sec. Then, every second the token count Tp is incremented by N if Tp ≤PBS (It should not exceed PBS). • When a packet of size B arrives, if Tp -B≥0, then the packet is not in excess of the peak rate, and Tp = Tp -B. • Otherwise, it is in excess of the peak rate. Tp is not decreased. The packet is a violating packet and it can be marked or dropped. Connection-Oriented Networks - Harry Perros 63 Example of the peak rate token bucket operation: PBS Tp time Packet 1 Packet 2 • Rate of arrival = PDR, packet size ≤ PBS • Legend: – Blue line: indicates the level of Tp – Red line indicates the arrival of a packet – The slope of the lines is = PDR Connection-Oriented Networks - Harry Perros 64 Rate of arrival is temporarily > PDR, packet size ≤ PBS PBS Tp time Packet 1 Packet 2 Packet 3 Packet 1 goes through because of the token count containing enough bytes Packet 2 is not as lucky! It’ll be dropped or marked. Tp is not decreased. Packet 3 goes through. The token bucket mechanism permits the peak rate of the source to exceed temporarily the PDR (like the CDVT in ATM) Connection-Oriented Networks - Harry Perros 65 Rate of arrival ≤ PDR, but packet size > PBS PBS Tp time Packet 1 Packet 1 will be dropped or marked. Tp is not decreased. The token bucket mechanism does not permit a packet bigger than MBS to go through. (MBS has the same meaning as the maximum frame size MFS in the GFR service category of ATM) Connection-Oriented Networks - Harry Perros 66 Committed rate: CDR, CBS • The committed rate is the amount of bandwidth allocated to the CR-LSP by the network. • As in the case of the peak rate, the committed rate is defined by a token bucket C with parameters – Committed data rate (CDR), expressed in bytes/sec – Committed burst size (CBS), expressed in bytes. • Token bucket C is replenished at the rate of CDR, and its maximum size is CBS. Connection-Oriented Networks - Harry Perros 67 Excess token bucket • The excess token bucket E is defined by the parameters: – committed data rate (CDR), expressed in bytes/sec – excess burst size (EBS), expressed in bytes. • Token bucket E is replenished at the rate of CDR and its maximum size is EBS. Connection-Oriented Networks - Harry Perros 68 Committed and excess token bucket operation: • Initially, the committed token count Tc = CBS, and the excess token count Te = EBS. • Let CDR = M bytes/sec. Then, every second – Tc is increment by M if Tc < CBS (Should not exceed PBS). – Te is increment by M, if Te < EBS (Should not exceed EBS) • When a packet of size B arrives, if Tc-B≥0, then the packet is not in excess of the committed rate, and Tc = Tc - B. • Otherwise, if Te-B≥0, then the packet is in excess of the committed rate, but not in excess of the EBS and Te = Te - B. • Otherwise, it is in excess of both the committed rate and the EBS, and neither Tc or Te are decremented. Connection-Oriented Networks - Harry Perros 69 An example EBS Te time CBS Tc Packet 1 Packet 2 (marked) Packet 3 Packet 3 (marked) Connection-Oriented Networks - Harry Perros Packet 4 (dropped) 70 Effect of the token buckets: • PDR > CDR and PBS < CBS, then – Packet may go through depending on the current size of the committed token bucket. – If it does not, packet may go through as marked depending on the size of the excess token bucket • PDR < CDR and PBS > CBS, then – Packet gets marked always Connection-Oriented Networks - Harry Perros 71 Bandwidth allocation • How much bandwidth (i.e., committed rate) should be allocated? – This problem is identical to that in ATM, where it has been adequately addressed. • How big should EBS be? – This depends on whether the network wants to carry marked packets and by how much. It also may depend on the SLA between user and network operator. Connection-Oriented Networks - Harry Perros 72 Flags 0 1 Res 2 3 4 5 6 7 F6 F5 F4 F3 F2 F1 • Six flags are defined: – – – – – – Flag F1: corresponds to the PDR Flag F2: corresponds to the PBS Flag F3: corresponds to the CDR Flag F4: corresponds to the CBS Flag F5: corresponds to the EBS Flag F6: corresponds to the weight • Each flag indicates whether the value it is associated with is negotiable or not Connection-Oriented Networks - Harry Perros 73 Frequency • It specifies at what granularity the CDR allocated to the CR-LSP is made available. The following frequency code points have been defined: – 0 - Unspecified – 1 - Frequent • The available rate should average the CDR when measured over any time interval equal to or longer than a small number of shortest packet times at the CDR. – 2- VeryFrequent • The available rate should average the CDR when measured over any time interval equal to or longer than the shortest packet time at the CDR. – 3-255: Reserved Connection-Oriented Networks - Harry Perros 74 Weight • It indicates the weight of the CR-LSP. It is used to determine the CR-LSP’s relative share of the excess bandwidth. • Weight values are from 1 to 255. • 0 means that weight is not applicable. Connection-Oriented Networks - Harry Perros 75 Class services • Class services can be constructed by appropriately manipulating the traffic parameters, and the token bucket decisions re. passing/dropping/marking a packet. • Below, we give several examples of different class services Connection-Oriented Networks - Harry Perros 76 Delay Sensitive (DS) service • The network commits to deliver with high probability user datagrams at a rate of PDR with minimum delay and delay requirement. Datagrams in excess of PDR will be discarded • Traffic parameters: – – – – – – – PDR=user specified PBS= user specified CDR=PDR CBS=PBS EBS=0 Frequency=Frequent Dropping action: drop>PDR Connection-Oriented Networks - Harry Perros 77 Throughput Sensitive (TS) service • The network commits to deliver with high probability user datagrams at a rate of at least CDR. The user can transmit at a rate higher than CDR but datagrams in excess of CDR have a lower probability of being delivered. • Traffic parameters: – – – – – – – PDR=user specified PBS=user specified CDR=user specified CBS=user specified EBS=0 Frequency=Unspecified Dropping action: drop>PDR, BPS, mark > CDR, CBS Connection-Oriented Networks - Harry Perros 78 Best Effort (BE) service • No expected service guarantees • Traffic parameters: – – – – – – – PDR=infinite PBS= infinite CDR= infinite CBS= infinite EBS=0 Frequency=Unspecified Dropping action: none Connection-Oriented Networks - Harry Perros 79 Frame Relay Service (FRS) ATM-CBR Traffic parameters: Traffic parameters: – – – – – – – PDR=user specific PBS= user specific CDR= CIR CBS= ?? EBS=?? Frequency=Unspecified Dropping action: drop>PDR, PBS mark>CDR,CBS,EBS Connection-Oriented Networks - Harry Perros – – – – – – – PDR=PCR PBS= CDVT CDR= PCR CBS= CDVT EBS=0 Frequency=VeryFrequent Dropping action: drop>PCR 80 ATM-RT VBR – – – – – – – PDR=PCR PBS= VDVT CDR= SCR CBS= MBS EBS=0 Frequency=Frequent Dropping action: drop>PCR mark>SCR,MBS ATM-NRT VBR – – – – – – – PDR=PCR PBS= VDVT CDR= SCR CBS= MBS EBS=0 Frequency=Unspecified Dropping action: drop>PCR mark>SCR,MBS Connection-Oriented Networks - Harry Perros ATM-UBR – – – – – – – PDR=PCR PBS= CDVT CDR= - CBS= - EBS=0 Frequency=Unspecified Dropping action: drop>PCR 81 The Resource Reservation Protocol (RSVP) TOPICS - Main features of RSVP - Reservation styles - Soft State - The RSVP message format - The Path message - The Resv message Connection-Oriented Networks - Harry Perros 82 Main features of RSVP • RSVP was designed to support the integrated services (intserv) architecture. • The intserv architecture was developed by IETF in the mid 1990s with a view to introducing QoS in the IP network. • Intserv was never widely accepted. It has been superceded by the DiffServ architecture, which has been successfully deployed in the IP network. Connection-Oriented Networks - Harry Perros 83 • RSVP is a signaling protocol used for the reliable establishment and maintenance of resource reservations for both unicast and many-to-many multicast applications • RSVP can be used to carry other types of control information since it is not aware of the content of the RSVP protocol fields. • In view of this, it was proposed to be used in MPLS. Connection-Oriented Networks - Harry Perros 84 Path and Resv messages RSVP makes use of two messages: – Path: This message originates from the sender and travels to the receiver. – Resv: Upon receipt of the Path message, the receiver responds with a Resv message, which travels on the reverse path of the Path message, and reserves bandwidth on each router along the path. Connection-Oriented Networks - Harry Perros 85 An example Sender Path Path Resv Receiver Resv Path Resv Connection-Oriented Networks - Harry Perros Path Resv 86 The Path message It contains the following information: • Phop: This is the address of the previous hop RSVP-capable router that forwards the message. This address is stored in the path state information at each node, and it is used to send the reservation message Resv upstream towards the sender. • Sender template: This field carries the sender’s IP address and optionally the UDP/TCP sender port. Connection-Oriented Networks - Harry Perros 87 • Sender TSpec: This defines the traffic characteristics of the data flow that the sender will generate. • Adspec: This carries one-pass with advertising (OPWA) information. This is information (advertisements) gathered at each node along the path taken by the Path message, such as availability of specific QoS control services. This information is delivered to the receiver who can use it to construct a reservation request or adjust appropriately an existing reservation. Connection-Oriented Networks - Harry Perros 88 The Resv message The Resv message carries the following information: • Flowspec: It specifies the desired QoS, and it consists of: – Receiver Tspec: A set of traffic descriptors which is used by the nodes along the path to reserve resources – Rspec: It defines the desired bandwidth and delay guarantees. – Service class: In intserv, the service class could be either the guaranteed service or the controlled-load service. Connection-Oriented Networks - Harry Perros 89 • Guaranteed service: – It provides firm bounds on the end-to-end queueing delay with no packet loss for all conforming packets • Controlled-load service. – It provides QoS that closely approximates the best effort service a user would receive from an unloaded network. Specifically: • A high percentage of transmitted packets will be successfully delivered. The packet loss should be close to the error rate of the links. • The end-to-end delay of the delivered packets will not greatly exceed the minimum end-to-end delay. Connection-Oriented Networks - Harry Perros 90 • Filter spec: It defines the packets that will receive the requested QoS defined in the flowspec. A simple filter spec could be just the sender’s IP address and optionally its UDP or TCP port. Connection-Oriented Networks - Harry Perros 91 • RSVP messages are sent in raw IP datagrams without a TCP or UDP encapsulation. (UDP encapsulation is permitted for routers that do not support raw IP datagrams). • RSVP is simplex, that is, it makes reservations for unidirectional data flows. Therefore, in order for two users A and B to communicate both ways, two separate sessions have to be established; one session from A to B, and another one from B to A. Connection-Oriented Networks - Harry Perros 92 Reservation styles Three different reservation schemes are possible, based on: 1. When multiple senders are transmitting to the same receiver, a separate reservation for each data flow or a single reservation for all the data flows on a router is possible. 2. Explicit or wildcard: The list of senders is explicitly stated by the receiver, or it is open to any sender. Connection-Oriented Networks - Harry Perros 93 The following reservation schemes have been defined: • Wildcard-filter (WF) style • Fixed-filter (FF) style • Shared explicit (SE) style Connection-Oriented Networks - Harry Perros 94 • Wildcard-filter (WF) style: Any sender can transmit to the session and there is a single resource reservation shared by all the data flows from all upstream senders. The resource reservation is the largest of all requested reservations. Connection-Oriented Networks - Harry Perros 95 • Fixed-filter (FF) style: A separate reservation is made for each particular sender specified in the explicit list of senders. Other senders identified in the explicit list which transmit in the same session do not share this reservation. • Shared explicit (SE) style: A list of senders is explicitly stated and there is a single shared reservation for all their flows. Connection-Oriented Networks - Harry Perros 96 Soft State • RSVP takes a soft state approach. That is, the state information in a router has to be periodically refreshed by Path and Resv messages. • RSVP runs on top of IP which does not guarantee delivery of packets. The soft state approach provides the necessary reliability in the delivery of the RSVP messages. Connection-Oriented Networks - Harry Perros 97 The RSVP message format • An RSVP message consists of the common header shown below, followed by a variable number of objects. Vers Flags Send_TTL MsgType Reserved Connection-Oriented Networks - Harry Perros RSVP checksum RSVP length 98 MsgType: The message type is specified by a number carried in this 8-bit field. The following messages types and numbers have been specified: – Path – Resv – PathEr – ResvErr – PathTear – ResvTear – ResvConf Connection-Oriented Networks - Harry Perros 99 The object format 2 bytes 1 byte Class-num Length (bytes) 1 byte C-Type Object contents • Length: A 16-bit field used to indicate the total length in bytes of the object. It must be a multiple of 4, and at least equal to 4 • Class-num: An 8-bit field used to identify the object class. • C-Type: An 8-bit field used to define the object type. Connection-Oriented Networks - Harry Perros 100 RSVP objects • NULL: The contents of a NULL object are ignored by the receiver • SESSION: It contains the IP destination address, the IP protocol id, and optionally a destination port. • RSVP_HOP: It carries the IP address of the RSVP-capable router that sent this message. The RSVP_HOP object is referred to as the PHOP (previous hop) object for messages from the sender to the receiver, and the NHOP (next hop) object for messages from the receiver to the sender. • TIME_VALUES: It contains the value for the refresh period used by the creator of the message. It is required in every Path and Resv message. Connection-Oriented Networks - Harry Perros 101 • STYLE: It defines the reservation style plus style-specific information. It is required in every Resv message. • FLOWSPEC: It carries the necessary information in an Resv message to make a reservation in a router. • FILTER_SPEC: It defines which data packets should receive the QoS specified in the FLOWSPEC object. It is required in a Resv message. • SENDER_TEMPLATE: It defines the sender’s IP address and perhaps some additional demultiplexing information, such as a port number. It is required in a Path message. • SENDER_TSPEC: It contains the traffic characteristics if the sender’s data flow. It is required in a Path message. Connection-Oriented Networks - Harry Perros 102 • ADSPEC: It carries the one-pass with advertising information. • ERROR_SPEC: It specifies an error in a PathErr, ResvErr, or a confirmation in a ResvConf message. • POLICY_DATA: It carries information that allows a router to decide whether a reservation is administratively permitted. • INTEGRITY: It carries cryptographic data to authenticate the originating node. • SCOPE: It carries an explicit list of sender hosts towards the information in the message is to be forwarded. • RESV_CONFIRM: It carries the IP address of a receiver that requested a confirmation. Connection-Oriented Networks - Harry Perros 103 The Path message objects • • • • • • INTEGRITY (optional), SESSION RSVP_HOP TIME_VALUES POLICY_DATA objects (optional), A sender descriptor consisting of the SENDER_ TEMPLATE and the SENDER_TSPEC • ADSPEC (optional). Connection-Oriented Networks - Harry Perros 104 Procedure • Each sender host sends a Path message for each data flow it wishes to transmit. • The Path message is forwarded from router to router using the next-hop information in the routing table until it reaches the receiver. • Each router along the path captures and processes the Path message. Connection-Oriented Networks - Harry Perros 105 • The router creates a path state for the pair {sender, receiver} defined in the SENDER_TEMPLATE and SESSION objects of the Path message. • Any POLICY_DATA, SENDER_TSPEC, and ADSPEC objects are also saved in the path state. • If an error is encountered a PathErr message is sent back to the originator of the Path message. Connection-Oriented Networks - Harry Perros 106 The Resv message objects • INTEGRITY (optional) • SESSION • RSVP_HOP • TIME_VALUES • RESV_CONFIRM (optional) • SCOPE (optional) • POLICY_DATA objects (optional), • STYLE • A flow descriptor list Connection-Oriented Networks - Harry Perros 107 • The RSVP_HOP contains the NHOP, that is the IP address of the router that sent the Resv message. • The presence of the RESV_CONFRIM object in the Resv message is a signal to the router to send a ResvConf message to the receiver to confirm the reservation. The RESV_CONFIRM carries the IP address of the receiver. • The flow descriptor list is style dependent. For the wildcard-filter (WF) style the flow descriptor list consists of the FLOWSPEC object. For the Fixed-filter (FF) and shared explicit (SE) styles, it consists of the objects FLOWSPEC and FILTER_SPEC. Connection-Oriented Networks - Harry Perros 108 SENDER_TSPEC contents for intserv The SENDER_TSPEC contains the traffic parameters: token bucket rate, token bucket size, peak data rate, minimum policed unit (i.e., size of smallest allowable packet), and maximum policed unit (i.e., size of maximum allowable packet). Connection-Oriented Networks - Harry Perros 109 FLOWSPEC contents for intserv When requesting the controlled-load service, the FLOWSPEC consists of the receiver TSpec which contains values for the parameters: token bucket rate, token bucket size, peak data rate, minimum policed unit, and maximum policed unit. These parameters are used to calculate the resource reservation in a router. Connection-Oriented Networks - Harry Perros 110 FLOWSPEC contents for intserv • When requesting the guaranteed service, the FLOWSPEC consists of the receiver TSpec and the Rspec which carries the parameters: – rate and – slack time. • These two parameters are used to define the desired bandwidth and delay guarantee. Connection-Oriented Networks - Harry Perros 111 The Resource Reservation ProtocolTraffic Engineering (RSVP - TE) TOPICS – Main features of RSVP-TE – Service classes and reservation styles – The RSVP-TE new objects – The RSVP-TE Path and Resv messages – RSVP-TE extensions Connection-Oriented Networks - Harry Perros 112 Main features of RSVP - TE • RSVP-TE uses downstream-on-demand label allocation with ordered control to setup an LSP. • This is implemented using the Path and Resv messages which have been augmented with new objects. Connection-Oriented Networks - Harry Perros 113 • An LSP can be setup using the next-hop information in the routing table. • RSVP-TE can also setup an explicit route by using a new object, called the EXPLICIT_ROUTE, which encapsulates the hops that make up the explicit path. • Strict or loose routing through an abstract node is permitted. Connection-Oriented Networks - Harry Perros 114 Setting up an LSP - ingress node: – The ingress node sends a Path message with a LABEL REQUEST object. This is a new object and it indicates that a label binding for the path is requested. – If an explicit route is requested, then the EXPLICIT_ROUTE object will be inserted in the Path message. Connection-Oriented Networks - Harry Perros 115 Setting up an LSP - next hop node: – The Path message is forwarded to the next hop indicated in the routing table for the particular IP destination address of the receiver, or the next hop indicated in the EXPLICIT_ROUTE object. – A node incapable of accepting the new requested LSP sends back a PathErr message. Connection-Oriented Networks - Harry Perros 116 Setting up an LSP - egress node: – The egress LSR (i.e., receiver), responds with an Resv message. – A new object called the LABEL object, is inserted in the message which is sent back upstream towards the sender, i.e., the ingress node, following the inverse path traversed by the Path message. Connection-Oriented Networks - Harry Perros 117 Setting up an LSP - going upstream: – Each node that receives the Resv message with a LABEL object uses that label for outgoing traffic associated with the LSP. – It allocates a new label, places it in the LABEL object of the Resv message and sends it upstream to the previous-hop node. – The LSP is established when the sender receives the Resv message. Connection-Oriented Networks - Harry Perros 118 Resource reservation • RSVP-TE enables the reservation of bandwidth along an LSP using standard RSVP reservations together with intserv service classes. • Resource reservation is optional and LSPs can be setup without reserving any resources. Such LSPs can be used, for instance, to carry best effort traffic and implement backup paths. Connection-Oriented Networks - Harry Perros 119 Service classes • There is no restriction in RSVP-TE as to which intserv service classes should be supported. RSVP-TE, however, should support the controlled-load service and the null service. • The null service class is newer service class that was introduced in RSVP in order to support RSVP signaling for the differentiated service (diffserv) architecture. Connection-Oriented Networks - Harry Perros 120 Reservation styles • Of these three reservation styles defined in RSVP, the wildcard-filter is not used in RSVP-TE. • The receiver node can use the FF or SE style for an LSP, and it can chose different styles for different LSPs. Connection-Oriented Networks - Harry Perros 121 The RSVP new objects • The following five new objects have been introduced to support the functionality of RSVPTE: – LABEL – LABEL_REQUEST – EXPLICIT_ROUTE – RECORD_ROUTE – SESSION_ATTRIBUTE Connection-Oriented Networks - Harry Perros 122 The LABEL object • Three different object types (C-Type field), are supported namely C-Type 1, C-Type 2 and C-Type 3. • C-Type 1 is a label request for generic labels • C-Type 2 and 3 is a label request for ATM labels and frame relay respectively. Connection-Oriented Networks - Harry Perros 123 The LABEL_REQUEST object 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 Length (bytes) Class-num Reserved C-Type L3PID C_Type 1 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 Length (bytes) Class-num Reserved C-Type L3PID M Res Minimum VPI Minimum VCI Res Maximum VPI Maximum VCI C_Type 2 Connection-Oriented Networks - Harry Perros 124 The EXPLICIT_ROUTE Object • This object is used to specify the hops in the requested explicit route. • Each hop could be a single node or a group of nodes, referred to as an abstract node. For simplicity, RSVP-TE refers to all the hops as abstract nodes, with the understanding that an abstract node could consist of a single node. Connection-Oriented Networks - Harry Perros 125 Sub-object for IPv4 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 L Type Length IPv4 address IPv4 address Prefix length Reserved • Common fields: L, Type, Length – L: 1-bit field to indicate whether the route through the abstract node is strict or lose. – Type: indicates whether the address provided is IPv4, IPv6 or autonomous system. – Length: Length of entire sub-object. Connection-Oriented Networks - Harry Perros 126 The RECORD_ROUTE object • Loops can be detected through the RECORD_ROUTE object. In this object the IP address of each node along the path can be recorded. Also, the labels used along the path can be recorded. The RECORD_ ROUTE object can be present in both Path and Rev messages. Connection-Oriented Networks - Harry Perros 127 The RSVP-TE Path message It is similar to the Path message in RSVP. It consists of the common header followed by objects: – INTEGRITY (optional), – SESSION – RSVP_HOP – TIME_VALUES – EXPLICIT_ROUTE (optional) Connection-Oriented Networks - Harry Perros 128 – LABEL_REQUEST – SESSION_ATTRIBUTE (optional) – POLICY_DATA objects (optional), – A sender descriptor consisting of the SENDER_TEMPLATE and the SENDER_TSPEC – ADSPEC (optional). – RECORD_ROUTE (optional) Connection-Oriented Networks - Harry Perros 129 The RSVP-TE Resv message The RSVP-TE Resv message consists of the common header followed by the objects: – INTEGRITY (optional), – SESSION – RSVP_HOP – TIME_VALUES – RESV_CONFIRM (optional) Connection-Oriented Networks - Harry Perros 130 – SCOPE (optional) – POLICY_DATA objects (optional), – STYLE – A style-dependent flow descriptor list. • For the Fixed-filter (FF) style it consists of the objects: FLOWSPEC, FILTER_SPEC, LABEL, RECORD_ROUTE (optional). • For the shared explicit (SE) style it consists of the objects: FILTER_SPEC, LABEL, RECORD_ROUTE (optional). Connection-Oriented Networks - Harry Perros 131