QOS NETWORKING TABLE OF CONTENTS. Mário Nunes, Jânio Monteiro IST

Transcription

1 IST QOS NETWORKING Mário Nunes, Jânio Monteiro TABLE OF CONTENTS 1. QOS NETWORKING SCENARIOS IP BEST EFFORT DIFFERENCIATED SERVICES (DIFFSERV) INTEGRATED SERVICES (INTSERV) RSVP - Resource reservation MPLS/GMPLS NETWORKING SCENARIOS Conventional Routing Overview Multi-Protocol Label Switching Label Distribution Generalized Multi-Protocol Label Switching (GMPLS) QOS MONITORING USING RTCP Sender and Receiver Reports REFERENCES... 20

2 1. Scenarios This chapter provides an introduction to overview of alternative networking approaches considering also Quality of Service (QoS) protocols now available or under development for Internet Protocol (IP) based networks. A high-level description of each QoS protocol architecture and operation is provided. The standard IP based networks provide "best effort" data delivery by default. To provide adequate service with some level of quantitative or qualitative determinism, IP services must be supplemented. This requires adding some additional functionalities to the network to distinguish traffic with strict timing requirements from traffic that can tolerate delay, jitter and loss. That is what Quality of Service (QoS) protocols are designed to do, managing more effectively the network resources to meet the wide range of application requirements. The goal of QoS is to provide some level of predictability and control beyond the current IP "best-effort" service. A number of QoS protocols have evolved to satisfy the variety of application needs. We describe these protocols individually, then describe how they fit together in various architectures with the end-to-end principle in mind. The challenge of these IP QoS technologies is to provide differentiated delivery services for individual flows or aggregates without breaking the Net in the process. Adding new functionality to the network and improving the "best effort" service represents a fundamental change to the design that made the Internet such a success. To avoid these potential problems as QoS protocols are applied to the Internet, the end-to-end principle is still the primary focus of QoS architects. As a result, the fundamental principle of "Leave complexity at the 'edges' and keep the network 'core' simple" is a central theme among QoS architecture designs. This is not as much a focus for individual QoS protocols, but in how they are used together to enable end-toend QoS. Three different approaches are considered in this chapter, corresponding to different architectures, which can be available to the Olympic trials: IP Best Effort, Differenciated Services (DiffServ), Multi-Protocol Label Switch. In all these architectures we can use the Real Time Control Protocol (RTCP) to monitor packet arrival performance IP Best Effort Standard Internet Protocol (IP) based networks provide "best effort" data delivery by default. IP Best Effort corresponds to the operation of the Internet as it is provided presently by the great majority of ISP. Best-effort IP allows the complexity to stay in the end-hosts, so the network can remain relatively simple. This scales well, as evidenced by the ability of the Internet to support its huge growth. As more hosts are connected, network service demands eventually exceed capacity, but service is not denied. Instead it degrades gracefully. Although the resulting variability in delivery delays (jitter) and packet loss do not adversely affect typical Internet applications, like , file transfer and Web applications, other applications cannot adapt to inconsistent service levels. Delivery delays and delay variation cause problems for applications with real-time requirements, such as those that deliver multimedia, the most demanding of which are two-way applications like telephony and streaming audio and video. These applications require a minimum bit-rate, low delay and/or low delay variation, which usually are not guaranteed in the public Internet. Increasing bandwidth is a necessary first step for accommodating these real-time applications, what is usually called over-provisioning. In LAN environments there is large bandwdith available that usually prevents congestion. Virtual Privates Networks (VPN) is another environment where the OLYMPIC Project Page 2/20

3 traffic load can be controlled in order to avoid congestion. However increasing bandwidth is still not enough to avoid jitter during traffic bursts. Even on a relatively unloaded IP network, delivery delays can vary enough to continue to adversely affect real-time applications Differenciated Services (DiffServ) For several years, a variety of IETF groups have been working on specifications for mechanisms to provide QoS in IP networks. Much of this effort was focused on the Differentiated Services (DiffServ) model. DiffServ defines QoS mechanisms that operate on groups of microflows that have similar QoS requirements. This approach is scalable to large networks and is capable of providing a variety of end-to-end services across multiple separately administered domains. The DiffServ architecture shown in Figure 1.1 achieves its scaling properties by defining a small number of simple differentiated packet forwarding treatments, known as per-hop behaviors (PHB). Individual network elements implement these PHBs through a variety of mechanisms and queuing disciplines. Figure 1.1: DiffServ Architecture. The DiffServ model concentrates policy activities at edge nodes, providing simple aggregate data handling in the core. This way, core routers do not need to maintain excessive state information or make expensive forwarding decisions. As represented in the previous picture, the DiffServ architecture is asymmetric, providing service differentiation in only one direction of traffic flow. Each data packet that enters a DiffServ network is marked by ingress routers with a DiffServ Codepoint (DSCP) with a length of 6 bits. This marking will depend from a previous service agreement between the ingress router and the user. DSCP field occupies 6 bits of the DiffServ (DS) byte as represented in next figure. DS byte substitutes the previously known Type of Service (ToS) byte in the IPv4 header, and the Traffic Class byte in IPv6 header DiffServ Codepoint (DSCP) ECN Class Selector Codepoint Figure 1.2: DS field in IPv4 and IPv6 headers. OLYMPIC Project Page 3/20

4 DSCP values in each IP packet indicate which PHB should be applied. There are currently several values defined which correspond to different service classes or PHB. Best effort PHB has assigned the value '00000 b ' and is considered a default value [12] (RFC2474). Expedited Forward PHB (EF PHB - RFC2598) [15] has assigned value ' b '. It refers to where packets get the maximum priority and can be used to build an end-to-end service with low packet loss, low latency, low Jitter and with an assured bandwidth. This service will appear to the end points like a point- to-point connexion or a virtual leased line and can be used to build a Premium service. Assured Forwarding (AF PHB - RFC 2597) [14] corresponds to four classes and three dropprecedences in each class, so a total of twelve codepoints. It is meant to be used when a client wants an assurance that IP packets, within a certain subscribed information rate, will have a high probability of being forwarded. However, clients can exceed the subscribed profile, with the understanding that the excess traffic will not be delivered with as high probability as the traffic that is within the profile. The AF PHB classes and levels of drop precedence, as shown in the next table. AF Classes Class 1 Class 2 Class 3 Class 4 Low Drop Precedence b b b b Medium Drop Precedence b b b b High Drop Precedence b b b b Table 1.1 : AF classes and drop precedence This means that AF PHB group provides forwarding of IP packets in four independent AF classes and, within each AF class, an IP packet is assigned one of tree different levels of drop precedence. Although these values are defined for a global scope, more AF classes or priority levels may be defined for local use. A certain amount of forwarding resources, buffer space and bandwidth, is allocated to each AF class in each DiffServ node. Within each AF class, IP packets are marked, by the customer or by the DiffServ domain provider, with one of the three possible drop levels. In case of congestion, the drop precedence of a packet determines the relative importance of the packet within the AF class. Below we summarizes the currently defined DSCPs and the corresponding IETF RFCs where they are defined: RFC 2474 RFC 2597 RFC Default (BE) DSCP xxx000 Class Selector (CS) DSCP group (*) , , AF Class , , AF Class , , AF Class , , AF Class Expedited Forwarding (EF) DSCP (*) - assures backward compatibility with IPv4 precedence Table 1.2 : Currently defined DSCPs. As shown above, although the DS field uses the IPv4 TOS byte as defined in RFC 791, it does not preserve the original IPv4 TOS bit values as defined by RFC The IP Precedence bits (0-2) are preserved, however. And although it is possible to assign any PHB to the codepoints in this range, OLYMPIC Project Page 4/20

5 the (required) default PHBs are equivalent to IP Precedence service descriptions, as described in detail in RFC Two other important concepts in the DiffServ architecture are the Service Level Agreement (SLA) and the Traffic Conditioning Agreement (TCA). Between distinct DiffServ Domains, and between a client and his ISP, there will be a service contract, called SLA, that will specify the forwarding service that should be applied to each microflow that comes from a client or from a different domain. An SLA may be either static or dynamic being negotiated by a Bandwidth Broker (BB) either statically or periodically. A BB is a dedicated node in each DiffServ Domain that keeps track of the amount of bandwidth for services, and, which processes admission control requests from customers or BBs of adjacent domains. SLAs can contain rules for the traffic conditioning that will constitute a TCA. Therefore, a TCA is a contract that specifies rules of classification, different traffic patterns and rules to measure, mark, shape and/or drop packets. To control those rules there are entities that classify, mark, meter, shape and drop packets. A Classifier is an entity that selects packets based on the content of packet headers according to defined rules. Classification can be separated in behaviour aggregate (BA) and multi-field (MF) classification. A BA classifier uses only the DS field to make classification and a MF classifier uses the content of an arbitrary number of header fields (source and/or destination address, ports, DS field, etc) to do the same task. A Marker can be used to add a DS byte to a packet, change from the ToS byte to a DS byte or back from DS to ToS, or even remark an already existing Codepoint. A Meter measures the temporal properties of a stream of packets. After comparing those results with a traffic profile specified in a TCA, a meter passes state information to the conditioner that will trigger a particular action for each packet which is either in or out-of-profile. Conditioning essentially involves applying the PHB. A conditioner can use a Shaper or Dropper. Shaping involves delaying some or all the packets in a traffic stream in order to bring the stream into compliance with a traffic profile. A shaper usually has a finite size buffer, and packets may be discarded if there is not sufficient buffer space to hold the delayed packets. A Dropper discards some, or all, of the packets in a traffic stream in order to bring the stream into compliance with the traffic profile. This process is known as policing the stream. As illustrated in Figure 1.3, PHBs are applied by the conditioner to traffic at a network ingress point (network border entry) according to pre-determined policy criteria. The traffic may be marked at this point, and routed according to the marking, then unmarked at the network egress (network border exit). Originating hosts can also apply the DiffServ marking, and there are a number of advantages in doing so. Classifier Conditioner (Shaper/Dropper) Marker Meter Figure 1.3: Differentiated Services Entities As previously stated, DiffServ assumes the existence of a service level agreement (SLA) between networks that share a border. The SLA establishes the policy criteria, and defines the traffic profile. It is expected that traffic will be policed and smoothed at egress points according to the SLA, and any traffic "out of profile" (i.e. above the upper-bounds of bandwidth usage stated in the SLA) at an ingress point have no guarantees (or may incur extra costs, according to the SLA). The policy OLYMPIC Project Page 5/20

6 criteria used can include time of day, source and destination addresses, transport, and/or port numbers (i.e. application Ids). Basically, any context or traffic content (including headers or data) can be used to apply policy. The simplicity of DiffServ to prioritize traffic belies its flexibility and power. When DiffServ uses RSVP parameters or specific application types to identify and classify constant-bit-rate (CBR) traffic, it will be possible to establish well-defined aggregate flows that may be directed to fixed bandwidth pipes. As a result, you could share resources efficiently and still provide guaranteed service. We will describe this type of usage later as we describe the various QoS architectures possible Integrated Services (IntServ) The Integrated Services (IntServ) architecture was designed to augment the existing Best Effort Internet with a range of services tailored for real-time streaming and interactive applications. Until now, within IntServ, the IETF has developed two new services aimed to support two types of applications: 1. Guaranteed Service (RFC 2212) [4], aimed to support real time applications with stringent bandwidth and latency requirements. It provides firm (mathematically provable) bounds on end-to-end queuing delays by combining the parameters from the various network elements in a path, in addition to ensuring bandwidth availability. 2. Controlled Load (RFC 2211) [3], aimed to support traditional applications, whose users require a performance similar to the one offered by a Best-Effort, under a lightly loaded network, but cannot provide the strictly bounded service of Guaranteed service. In IntServ the traffic characteristics associated to these services are strictly defined and resources are previously reserved by means of a signalling protocol, usually the Resource Reservation Protocol (RSVP) (RFC 2205) [1]. The IntServ architecture requires per-flow traffic handling and signalling at every hop along an application s end-to-end path. This means that it does not scale well to large networks and large customer populations. Controlled-Load provides no firm quantitative guarantees. It approximates the behaviour of a Best- Effort Service under unloaded network conditions. The important difference between Controlled- Load and Best-Effort is that the former does not noticeably deteriorate as the network load increases. Actually, it will be as good as Best-Effort on a lightly loaded network. It is expected that a very high percentage of transmitted packets will be successfully delivered by the network to the receiving end nodes. The percentage of packets not successfully delivered must closely approximate the basic packet error rate of the transmission medium. Additionally, the transit delay experienced by most of the delivered packets will not greatly exceed the minimum transmit delay of any successfully delivered packet. Guaranteed Service provides an assured level of bandwidth, which produces a delay-bounded service with no queuing loss for conforming datagrams. It warrants that datagrams will arrive within the appointed delivery time and will not be discarded due to queue overflows, provided the traffic obeys its specified parameters. This service does not attempt to minimise the jitter the difference between the minimal and maximal datagram delay. It merely controls the maximal queuing delay. Integrated Services use a token-bucket model to characterize its input/output queuing algorithm. A token-bucket is designed to smooth the flow of outgoing traffic, but unlike a leaky-bucket model OLYMPIC Project Page 6/20

7 (which also smoothes the out-flow), the token-bucket model allows for data bursts, higher send rates that last for short periods RSVP - Resource reservation The ReSerVation Protocol (RSVP) is a signaling protocol that provides reservation setup and control to enable the integrated services, which is intended to provide the closest thing to circuit emulation on IP networks. RSVP is the most complex of all the QoS technologies, for applications (hosts) and for network elements (routers and switches). As a result, it also represents the biggest departure from standard "best-effort" IP service and provides the highest level of QoS in terms of service guarantees, granularity of resource allocation and detail of feedback to QoS-enabled applications and users. PATH RESV PATH RESV RESV PAT H PATH PATH RESV RESV Sender Receiver Figure 1.4: RSVP "PATH" and "RESV" messages Here is a simplified overview of how the RSVP protocol works, as illustrated in Figure 1.4: Senders characterize outgoing traffic in terms of the upper and lower bounds of bandwidth, delay, and jitter. RSVP sends a PATH message from the sender that contains this traffic specification (TSpec) information to the (unicast or multicast receiver(s)) destination address. Each RSVP-enabled router along the downstream route establishes a "path-state" that includes the previous source address of the PATH message (i.e. the next hop "upstream" towards the sender). To make a resource reservation, receivers send a RESV (reservation request) message "upstream". In addition to the TSpec, the RESV message includes a request specification (Rspec) that indicates the type of Integrated Services required- either Controlled Load or Guaranteed- and a filter specification (filter spec) that characterizes the packets for which the reservation is being made (e.g. the transport protocol and port number). Together, the RSpec and filter spec represent a flow-descriptor that routers use to identify each reservation (a.k.a., a "flow" or a "session"). When each RSVP router along the upstream path receives the RESV message, it uses the admission control process to authenticate the request and allocate the necessary resources. If the request cannot be satisfied (due to lack of resources or authorization failure), the router OLYMPIC Project Page 7/20

8 returns an error back to the receiver. If accepted, the router sends the RESV upstream to the next router. When the last router receives the RESV and accepts the request, it sends a confirmation message back to the receiver (note: the "last router" is either closest to the sender or at a reservation merge point for multicast flows). There is an explicit tear-down process for a reservation when sender or receiver ends an RSVP session. A summary of the main characteristics of the RSVP Protocol mechanisms is presented: Reservations in each router are "soft," which means they need to be refreshed periodically by the receiver(s). RSVP is not a transport, but a network (control) protocol. As such, it does not carry data, but works in parallel with TCP or UDP data "flows." Applications require APIs to specify the flow requirements, initiate the reservation request, and receive notification of reservation success or failure after the initial request and throughout a session. To be useful, these APIs also need to include RSVP error information to describe a failure during reservation setup or anytime thereafter during the lifetime of a reservation as conditions change. Reservations are receiver-based, in order to efficiently accommodate large heterogeneous (multicast) receiver groups. Multicast reservations are "merged" at traffic replication points on their way upstream, which involves complex algorithms that are not well understood yet. We discuss the topic of QoS support for multicast in more detail later in this document. Although RSVP traffic can traverse non-rsvp routers, this creates a "weak-link" in the QoS chain where the service falls-back to "best effort" (i.e. there is no resource allocation across these links). There are two types of RSVP Protocols: Native RSVP has an IP Protocol number 46 (for the protocol field of an IP header), and the RSVP header and payload are encapsulated by the (raw) IP header itself. UDP-encapsulated RSVP has its header contained in a UDP datagram. As mentioned already, RSVP provides the highest level of IP QoS available. It allows an application to request QoS with a high level of granularity and with the best guarantees of service delivery possible. This sounds wonderful and leaves one wondering why we need anything else. The reason is that it comes at the price of complexity and overhead, thus is overkill for many applications and (as we describe later) for some portions of the network MPLS/GMPLS networking scenarios With the exponential growth of the Internet over the last few years, technology has had to adapt constantly to new demands for increased bandwidth. In addition, the Internet will continue to see dramatic growth due to the ever-increasing demand for more bandwidth to the home, with projections of every household having broadband access in the future. In order to meet the growing demand for bandwidth, Internet Service Providers (ISPs) need higher performance switching and routing products. Core network routers contribute to latencies, as each OLYMPIC Project Page 8/20

9 must make its own individual decision on the best way to forward each incoming packet. Traditionally, IP has been routed over ATM using IP over ATM via virtual circuits (VCs) or Multi- Protocol over ATM (MPOA). These forwarding methods proved to be cumbersome and complicated. The need for a simpler forwarding method - one with the traffic management features and performance of traditional switches combined with the forwarding intelligence of a router - is definitely felt. All of these needs can be met with multiprotocol label switching (MPLS), because it integrates the key features of both Layer 2 and Layer 3. Most importantly, it is not limited to any Layer 2 or Layer 3 protocol. In particular, MPLS has several applications and can be extended across multiple product segments (such as an MPLS router, an IP services switch/router, a multiservice switch, an Optical Ethernet switch, as well as optical switches) Conventional Routing Overview Conventional routers (thought as routers that are not MPLS-enabled or that function in a network in which MPLS has not been enabled) have been designed to route information based solely on the destination address - using interior gateway protocols (IGPs), such as routing information protocol (RIP) and open shortest path first (OSPF), or exterior gateway protocol (EGPs) such as border gateway protocol (BGP). In making a routing decision, they do not take specific attributes of the application into consideration. As a result, services cannot be differentiated based on the requirements of the specific application, nor can service providers dynamically adjust network requirements (e.g., allocate bandwidth) based upon existing network conditions (e.g., congestion) or on performance requirements of applications (e.g., Quality of Service (QoS) or Class of Service (CoS)). The forwarding mechanism, in conventional routing, is hop-by-hop routing. In other words, each router that a packet traverses must do a route lookup, based on that destination Layer 3 address in the IP header. This must be performed to determine the packet s next hop in its path to get it to its final destination. The Layer 2 destination address is then replaced with the address of the next hop s Layer 2 address, and the source Layer 2 address is then replaced with the Layer 2 address of the current router, leaving the source and destination Layer 3 addresses in place for the next hop to perform its own route lookup on the packet. This process must be repeated at each hop to deliver the packet to its final destination. Packets are routed through the network in a connectionless manner, i.e., they do not follow any predetermined path. This places a high demand on the routers, simply because of the processing required for the forwarding function, which is performed by each router in the network and is carried out on a per packet basis. Clearly, as Internet traffic continues to expand there will be increasingly heavy demand placed on Internet routers. Therefore in summary, conventional routing: Analyses the IP packet header at each router hop in the network. Requires an analysis of the entire IP header at every router in the path. Is based solely on the destination address in the IP header. Does not consider application-specific information, such as QoS and CoS requirements in making the routing decision. Does not consider existing network conditions such as congestion. OLYMPIC Project Page 9/20

10 Multi-Protocol Label Switching MPLS stands for "Multiprotocol Label Switching. Because MPLS is multi-protocol its techniques are applicable to any Network Layer protocol. However here we will assume an IP Network Layer protocol. Network Layer Protocols IP (v4/v6) Data Link Layer Protocols Multi-Protocol Label Switching (MPLS) Ethernet Frame Relay PPP ATM Figure 1.5: Network Layer and Data Link Layer Protocols MPLS defines an architecture and protocol for encapsulating IP traffic in new routing headers. It uses a technique called label switching, a technology that forwards packets based on labels that assign the data flow to the packet only once - at the point at which the packet enters the network, i.e., the point of entry or ingress. At this point of entry, the packet is examined to determine which route or path it should follow through the network. Based on this analysis, a small fixed-format Layer 2 routing label that includes this path or route is assigned. The path can be assigned taking factors such as destination address, QoS requirements and the current state of the network into consideration. High priority packets and low priority packets can be sent via different paths. And packets can be routed to avoid congested paths. Hence, differentiated services can be provided. MPLS labels are assigned such that they can include the capability to distinguish both the destination address and the application type or service class. This information within the label can be used to alert the MPLS router at the next hop to the packet s predefined path - or to a set of predefined paths that it may travel. As the packet travels through the network, it may be relabeled to travel a more efficient path. But it is always labelled. Only upon leaving the MPLS network is the packet stripped of its label. As far as the original packet is concerned, the routers that carry it through the MPLS network appear as a single hop - a tunnel through the network. Forwarding is done independently of any routing protocols, based only on the label value. Labels are commonly used in Layer 2 technologies and have been for a number of years. The uniqueness, and the advantage, of MPLS is that it does not associate the label with any particular Layer 2 protocol but rather implements the ATM like concept of labels more broadly. By using labels, the packet can be forwarded using predetermined paths and according to specific QoS and CoS criteria, without requiring the packet to be examined by each router in its path. Therefore, both efficiency and network router control are substantially improved. In summary, MPLS: Analyses the IP packet header only once in the router at the entry point (ingress point) into the network. Does not require an analysis of the entire IP header at the routers within the core of the network but rather examination of only a label that is attached to the packet. Considers the destination address as a part of the routing determination but may also include other factors. May consider application-specific requirements and differentiation of traffic based on factors such as QoS and CoS in making the routing decision. This allows differentiated services. OLYMPIC Project Page 10/20

11 Considers network specific conditions. The pre-determined path can be changed based on existing conditions as the packet travels through the network. An MPLS network includes two types of nodes: Label Edge Routers (LERs) at the edge of the network and Label Switch Routers (LSRs) in the core of the network. LERs are essentially edge LSRs. A core LSR may be either a router or an ATM switch. The Forwarding Equivalent Class (FEC) is a representation of a group of packets that share the same requirements for their transport. All packets in such a group are provided the same treatment en route to the destination. As opposed to conventional IP forwarding, in MPLS the assignment of a particular packet to a particular FEC is done just once, as the packet enters the network. FECs are based on service requirements for a given set of packets or simply for an address prefix. Each LSR builds a table to specify how a packet must be forwarded. This table, called a Label Information Base (LIB), is comprised of FEC-to-label bindings. MPLS provides Label Switched Paths (LSPs). An LSP is the pre-defined path (setup prior to data transmission) by which the packet will be forwarded from the LER to the first LSR and from that LSR to each of the LSRs across the MPLS network cloud. It might also be thought of as a tunnel through the network. Each tunnel has a definite entrance and a definite exit and no exit points within the tunnel because data is not routed at the LSRs within the tunnel Label Distribution The concept of label switched paths (LSP) requires that the forwarding tables at each LSR include information such that it can map the incoming label to the outgoing label and forward the packet using the predetermined path. In other words, the LSR must be able to map the incoming interface and label value to the appropriate outgoing interface and label value. Label Distribution is the process of establishing this mapping. Currently, several protocols can be used for the distribution of labels between LSR peers, such as Label Distribution Protocol (LDP), Constraint-based Routed - Label Distribution Protocol (CR-LDP), resource reservation protocol (RSVP) and Border Gateway Protocol (BGP). The MPLS architecture [6] does not specify that any one protocol should be used for the distribution of labels between LSR peers. In fact, the protocol used should depend on what requirements must be met by a particular network. The LDP was designed solely for this use, but LDP alone cannot meet QoS needs. In order to support QoS applications, an LDP must be able to properly select and reserve network resources along an LSP. In order to support this, one can either use an existing protocol used for resource reservation and extend it for label distribution (for example RSVP), or take a protocol that can be used for label distribution and extend it to support resource reservation (for example LDP and BGP). The LDP Specification [7] defines LDP as the set of procedures and messages by which LSRs establish LSPs through a network by mapping network-layer routing information directly to datalink layer switched paths. However, as these LSPs are built, there is also a need to ensure that they can support CoS and Traffic Engineering requirements. In addition, there are some cases where there is a need for a method of creating explicitly routed LSPs through an MPLS domain. As stated before, LDP alone cannot support this, so it has been extended to support constraint-based routing (CR-LDP). CR-LDP is not alone in offering this functionality; RSVP is another protocol that provides many of the same benefits of CR-LDP but with Traffic Engineering extensions; i.e., RSVP-TE [9]. OLYMPIC Project Page 11/20

12 RSVP-TE Hosts and routers that support both RSVP and Multi-Protocol Label Switching can associate labels with RSVP flows. When MPLS and RSVP are combined, the definition of a flow can be made more flexible. As previously explained, RSVP communicates with two basic types of messages, PATH and RESV. PATH messages flow from a sender to one or multiple receivers. Upon receipt of a PATH message, a receiver can send an RESV message in return. The label itself is carried within the RESV message. Figure 1.6: Extended RSVP packet flow Previous figure shows an example of a downstream allocation mapping of labels. Label distribution flows in the opposite direction of LSP flow. In other words, the label bound to a FEC is received from its downstream neighbour. LSP tunnels allow the implementation of a variety of policies related to network performance optimisation. For example, LSP tunnels can be automatically or manually routed away from network failures, congestion, and bottlenecks. Furthermore, multiple parallel LSP tunnels can be established between two nodes, and traffic between the two nodes can be mapped onto the LSP tunnels according to local policy. Extended RSVP [9] has been designed to specifically address these issues by enabling MPLS Traffic Engineering (MPLS-TE). Extended RSVP includes support for creation of explicitly routed LSPs, either for best-effort traffic or for traffic with resource reservation requirements. The explicitly routed path is specified as a set of hops through the network. It can be specified manually by a network administrator, or computed automatically by a network management program that monitors network conditions such as congestion. The explicit route may also be either strict (all hops are specifically identified) or loose (only some hops are specifically identified; others are determined by IP routing). Additionally, it should be pointed out that while basic RSVP was intended for host-to-host establishment of resource reservations, Extended RSVP would more typically be used between the entry (ingress) and exit (egress) routers within an MPLS network. Capabilities of RSVP-TE include: Remains in a soft state, requiring the retransmission of refresh messages in order to maintain an LSP. Provides downstream-on-demand label distribution. Reserves network resources for explicit LSPs. Uses IP datagrams to transport messages between peers instead of using TCP and, therefore, must handle the loss of distribution messages itself Constraint-based routed LDP (CR-LDP) Constraint-based routed LDP is another method of establishing point-to-point LSPs and QoS in MPLS. These attributes are particularly useful when attempting to engineer links over the public OLYMPIC Project Page 12/20

13 Internet or when setting up a virtual private network (VPN). CR-LDP allows for explicit routes, using both strict and loose hops, providing maximum flexibility in building a specific path through a network. Some of the appeal to CR-LDP is that its version of QoS is similar to the technology of ATM. It also has the ability to allocate bandwidth based on an LSP s priority (ranging from 0-7) and/or its age. Figure 1.7: CR-LDP packet flow Capabilities of CR-LDP include: Remains in a hard state and can be thought of as a nailed-up connection. Has both explicit setup and explicit teardown. Needs no refresh; once up, it stays up until torn down. Provides a neighbour discovery mechanism by multicasting hello messages as a user datagram protocol (UDP) packet to the LDP port at the all routers on this subnet multicast group address to find all directly connected LSRs. CR-LDP is an extension on an already existing and running protocol, LDP Routing Protocols in the MPLS environment IGP (Interior Gateway Protocol) are routing protocols used within an autonomous system (AS) to provide intra-as routing. Most interior routing protocols used today fall under two different models, distance vector and link state. In production environments, link state algorithms are usually preferred for their resiliency, scalability, and built-in intelligence. Common link state protocols are OSPF and IS-IS. For MPLS environments, typical link state routing protocols are being extended to support the construction of LSPs that meet specific QoS requirements. While these extensions are being used for traffic engineering, it is important to note that IGPs are used for providing a next hop label forwarding entry (NHLFE). The NHLFE is used when forwarding a labelled packet by providing the packet s next hop, and carries information on what to do with the packet upon receipt. If the next hop is itself, the LSR will pop the top level label and forward the resulting packet to itself. Another forwarding decision will then be made, based on what remains after the label stacked is popped. At this point, the packet may still be labelled, or it may be a native IP packet. If it is a native IP packet, the LER will then make a forwarding decision based on its IGP. BGP (Border Gateway Protocol) is a routing protocol usually used between autonomous systems (AS) to provide inter-as routing. It is currently widely deployed to interconnect large provider networks into what we call the Internet. In MPLS, BGP can also be used to distribute label-binding information for each route it advertises.. A label for a route can be piggybacked within the same UPDATE message used to advertise it to its peer. The label and any related information is carried as part of the network layer reachability information (NLRI). OLYMPIC Project Page 13/20

14 Generalized Multi-Protocol Label Switching (GMPLS) Recent work has been done to extend and adapt the MPLS control plane, and specifically MPLS constraint-based routing, so that it can be used, not just with routers and ATM switches, but also with optical crossconnects (OXCs). This is a fundamental step in the evolution and integration of data and optical network architectures. GMPLS architecture clearly separates the control plane and the forwarding plane. In addition, it also clearly separates the control plane in two parts: signalling plane: containing the signalling protocols routing plane: containing the routing protocols. The original MPLS architecture [6] is extended in GMPLS architecture to include LSRs whose forwarding plane recognizes neither packet, nor cell boundaries, and therefore, can't forward data based on the information carried in either packet or cell headers. Specifically, such LSRs include devices where the forwarding decision is based on time slots, wavelengths, or physical ports. Using MPLS as the foundation for connection establishment, a common control plane addresses several issues related to this network evolution. First, a common control plane simplifies network operations and management, which ultimately results in reduced operational costs. Second, a common control plane provides a wide range of deployment scenarios, ranging from overlay to peer, where the overlay model is realized using only a subset of the functionality needed to implement the peer model. This allows the choice of peer or overlay (or a combination of both) deployment models to be driven by business and engineering considerations, rather than constrained by the current approach of stratification of subnetworks into technology domains. At the same time, developing a common control plane by reusing and extending existing routing and signalling protocols avoids the need to reinvent the wheel, thus minimizing risks associated with protocol development and reducing the time to market for advanced optical switching equipment. Some enhancements are clearly required to the existing MPLS routing and signalling protocols to address the peculiar characteristics of optical transport networks. These protocol extensions are being standardized by the Internet Engineering Task Force (IETF) under the framework of generalized MPLS (GMPLS). These extensions can be summarized as follows: Enhancements to the RSVP-TE and CR-LDP signalling protocols to allow the signalling and instantiation of optical channel trails in optical transport networks and other connectionoriented networking environments. Enhancements to OSPF and IS-IS interior gateway routing protocols (IGPs) to advertise availability of optical resources in the network (e.g., bandwidth on wavelengths, interface types) and other network attributes and constraints. A new link management protocol, LMP, designed to address the issues related to link management in optical networks. Additional functionality has been added to GMPLS to address some limitations of the MPLS control plane, such as the inability to establish bi-directional connections in a single request, and the absence of mechanisms to account for protection bandwidth so that it can be used for lower-priority traffic. Using the MPLS framework and its signalling protocols, a link or node failure (e.g., power outage) along the routes of established service connections could only be handled locally, or along the nodes of the path. However, in the GMPLS framework, additional capability has been added such that failures which impact service connections can also be reported to a predefined alarm centre (e.g., a centralized management system). Thus, the devices in the network can detect a failure, report the failure, quickly determine whether spare capacity is available on other routes, and then use signalling to restore the service connection onto a fault-free route, circumventing the point of failure. OLYMPIC Project Page 14/20

15 Generalized MPLS (GMPLS) differs from traditional MPLS in that it supports multiple types of switching, i.e. the addition of support for TDM, lambda, and fiber (port) switching. The support for the additional types of switching has driven GMPLS to extend certain base functions of traditional MPLS and, in some cases, to add functionality. These changes and additions impact basic LSP properties, how labels are requested and communicated, the unidirectional nature of LSPs, how errors are propagated, and information provided for synchronizing the ingress and egress LSRs 1.5. QoS monitoring using RTCP Multimedia transport over IP networks are usually supported by the Real Time Protocol (RTP) over UDP. However, the UDP protocol gives no guaranty about the correct reception of media packets and therefore they can be lost, reordered or have different delay variations. The RTP protocol, using Sequence Numbering and Timestamps, enable receiver QoS detection, however there must exist a solution to convey QoS parameters between receivers and sources. This is one of the main tasks performed by the Real Time Control Protocol (RTCP) [18]. RTCP is based on the periodic transmission of control packets to all participants in a session, using the same distribution mechanism as the data packets. Using UDP and separate port numbers, data and control packets are multiplexed. RTCP performs four basic functions, where the following first three are mandatory when RTP is used in the IP multicast environment, being also recommended for all environments. The primary function is to provide feedback on the quality of the data distribution. This is an integral part of the RTP's role as a transport protocol and is related to the flow and congestion control functions of other transport protocols. The feedback may be directly useful for control of adaptive encoding, but experiments with IP multicasting have shown that it is also critical to get feedback from the receivers to diagnose faults in the distribution. Sending reception feedback reports to all participants allows one who is observing problems to evaluate whether those problems are local or global. With a distribution mechanism like IP multicast, it is also possible for an entity such as a network service provider (who is not otherwise involved in the session) to receive the feedback information and act as a third-party monitor to diagnose network problems. Additionally RTCP carries a persistent transport-level identifier for an RTP source called the canonical name or CNAME. Since the SSRC identifier may change if a conflict is discovered or a program is restarted, receivers require the CNAME to keep track of each participant. Receivers also require the CNAME to associate multiple data streams from a given participant in a set of related RTP sessions, for example to synchronize audio and video. The first two functions require that all participants send RTCP packets, therefore the rate must be controlled in order for RTP to scale up to a large number of participants. By having each participant send its control packets to all the others, each can independently observe the number of participants. This number is used to calculate the rate at which the packets are sent. A fourth, optional function is to convey minimal session control information, for example participant identification to be displayed in the user interface. This is most likely to be useful in "loosely controlled" sessions where participants enter and leave without membership control or parameter negotiation. RTCP serves as a convenient channel to reach all the participants, but it is not necessarily expected to support all the control communication requirements of an application. A higher-level session control protocol, which is beyond the scope of this document, may be needed. The RTCP specification [18] defines several RTCP packet types to carry a variety of control information: OLYMPIC Project Page 15/20

16 Sender Report (SR) for transmission and reception statistics from participants that are active senders. Receiver Report (RR) for reception statistics from participants that are not active senders. Source description items (SDES) including CNAME. End of participation indication (BYE). Application specific functions (APP). Multiple RTCP packets may be concatenated without any intervening separators to form a compound RTCP packet that is sent in a single packet of the lower layer protocol, for example UDP. There is no explicit count of individual RTCP packets in the compound packet since the lower layer protocols are expected to provide an overall length to determine the end of the compound packet Sender and Receiver Reports Sender and Receiver Reports are very important in order to convey quality information between a sender (Source) and receivers, either in IP multicast as Unicast. It is expected that reception quality feedback will be useful not only for the sender but also for other receivers and third-party monitors. The sender may modify its transmissions based on the feedback; receivers can determine whether problems are local, regional or global; network managers may use profile-independent monitors that receive only the RTCP packets and not the corresponding RTP data packets to evaluate the performance of their networks for multicast distribution. The following figure (Figure 1.8) represents a complete RTCP Sender Report as defined in [18]. 1 byte 1 byte 1 byte 1 byte V P RC PT = 200 Length of this RTCP packet SSRC of Sender Wallclock time when this report was sent- Network Time Protocol (NTP) timestamp (64 bits) RTP timestamp identifying the moment this packet was sent Total number of RTP data packets transmitted by the sender Total number of payload data octets transmitted by the sender SSRC identifier of the first source ( SSRC_1 ) % of lost RTP Cumulative number of packets lost data packets Extended highest sequence number (SN) received in one RTP packet Interarrival Jitter estimate The middle 32 bits out of 64 in the NTP timestamp received as part of the most recent RTCP sender report (SR) packet (LSR) The delay between receiving the last SR packet from source SSRC_1 and sending this reception report block (DLSR) Header Sender Info Report Blocks Reception Information from each Source (as many as identified by RC) SSRC identifier of the second source ( SSRC_2 )... OLYMPIC Project Page 16/20

17 profile-specific extensions Figure 1.8: Complete RTCP s Sender Report (SR) Packet Although we represented in previous figure a complete RTCP packet, in an unidirectional media delivery, as in the OLYMPIC architecture, the report blocks (in grey) are not usually necessary. They are mainly used in sessions were a sender can also play the role of a receiver and therefore it needs to send receiver statistics to other senders. Therefore, in media delivery, the Sender Report will have the following format: 1 byte 1 byte 1 byte 1 byte V P RC=0 PT = 200 Length of this RTCP packet SSRC of Sender Wallclock time when this report was sent- Network Time Protocol (NTP) timestamp (64 bits) RTP timestamp identifying the moment this packet was sent Total number of RTP data packets transmitted by the sender Total number of payload data octets transmitted by the sender profile-specific extensions Header Sender Info Figure 1.9: Typical RTCP Sender Report (SR) packet for unidirectional media delivery A source or a third-party monitor can easily understand how is the reception quality going, looking to the RTCP Receiver Report fields. The following figure (Figure 1.10) represents those fields in an RTCP Receiver Report packet as defined in [18]. 1 byte 1 byte 1 byte 1 byte V P RC PT = 201 Length of this RTCP packet SSRC of Sender SSRC identifier of the first source ( SSRC_1 ) % of lost RTP Cumulative number of packets lost data packets Extended highest sequence number (SN) received in one RTP packet Interarrival Jitter The middle 32 bits out of 64 in the NTP timestamp received as part of the most recent RTCP sender report (SR) packet (LSR) The delay between receiving the last SR packet from source SSRC_1 and sending this reception report block (DLSR) SSRC identifier of the second source ( SSRC_2 )... Profile-specific extensions Figure 1.10: RTCP Receiver Report (RR) Packet Header Report Blocks Reception Information from each Source (as many as identified by RC) OLYMPIC Project Page 17/20

18 The format of the receiver report (RR) header is the same as that of the SR packet except that the packet type field contains the constant 201. As previously represented, the Sender Report (SR) packet has two time identifiers, the RTP Timestamp and the NTP Timestamp. The wallclock time (absolute time) is represented using the timestamp format of the Network Time Protocol (NTP), which is in seconds relative to 0h UTC on 1 January The full resolution NTP timestamp is a 64-bit unsigned fixed-point number with the integer part in the first 32 bits and the fractional part in the last 32 bits. In some fields where a more compact representation is appropriate, only the middle 32 bits are used; that is, the low 16 bits of the integer part and the high 16 bits of the fractional part. The RTP Timestamp corresponds to the same time as the NTP timestamp, but in the same units and with the same random offset as the RTP timestamps in data packets. The correspondence between NTP Timestamp and the RTP Timestamp may be used for intra-media and inter-media synchronization for sources whose NTP timestamps are synchronized, and may be used by media-independent receivers to estimate the nominal RTP clock frequency. Besides reading direct values from Sender and Reception reports, other values can also be computed. One of these values is for example, the Round-trip Time (RTT). Next figure (Figure 1.11) represents the RTT computation method by a Source. Figure 1.11: Round-trip Time (RTT) computation The receiver application computes the last SR timestamp (LSR) extracting the middle 32 bits out of 64 in the NTP timestamp from the most recent RTCP Sender Report (SR) packet. After computing this values it sends it back to the source using a RR packet. It also sends the delay since last SR (DLSR) value in units of 1/(2 16 ) seconds, between receiving the last SR packet and sending this reception report block. Therefore the sender application, knowing the arrival time of the RR (T), can compute the RTT using: RTT = T LSR DLSR As represented in next figure (Figure 1.12), in IP Multicast the RTT can also be computed and the Source application can differentiate each receiver using the IP address of each one. We must not forget that the source maintains point-to-point RTSP/TCP connections to each receiver, and therefore it known all receivers IP address. OLYMPIC Project Page 18/20

19 Although not shown in the figure, it is important to note that if each receiver sends their RRs to the IP Multicast group address, other receivers will also receive those RRs. This is very important for scalability issues, since each receiver may restraint their RR according to the number of other RRs sent and by this way it will limit the feedback implosion problem. Source (IP address S) Receiver 1 (IP address R1) MULTICAST DATA STREAM Receiver 2 (IP address R2) Sender Report (SR) RTT computation for IP R1 RTT computation for IP R2 Receiver Report 1 (RR1) Receiver Report 2 (RR2) Figure 1.12: Round-trip Time (RTT) computation in Multicast Additionally, cumulative counts are used in both the sender information and receiver report blocks so that differences may be calculated between any two reports to make measurements over both short and long time periods, and to provide resilience against the loss of a report. The difference between the last two reports received can be used to estimate the recent quality of the distribution. The NTP timestamp is included so that rates may be calculated from these differences over the interval between two reports. Since that timestamp is independent of the clock rate for the data encoding, it is possible to implement encoding- and profile-independent quality monitors. A calculation example is the packet loss rate between two reception reports. The difference in the cumulative number of packets lost gives the number lost during that interval. The difference in the extended last sequence numbers received gives the number of packets expected during the interval. The ratio of the two is the packet loss fraction over the interval. This ratio should equal the fraction lost field if the two reports are consecutive, but otherwise not. The loss rate per second can be obtained by dividing the loss fraction by the difference in NTP timestamps, expressed in seconds. The number of packets received is the number of packets expected minus the number lost. The number of packets expected may also be used to judge the statistical validity of any loss estimates. For example, 1 out of 5 packets lost has a lower significance than 200 out of From the sender information, a third-party monitor can calculate the average payload data rate and the average packet rate over an interval without receiving the data. Taking the ratio of the two gives the average payload size. If it can be assumed that packet loss is independent of packet size, then the number of packets received by a particular receiver times the average payload size (or the corresponding packet size) gives the apparent throughput available to that receiver In addition to the cumulative counts, which allow long-term packet loss measurements using differences between reports, the fraction lost field provides a short-term measurement from a single report. This becomes more important as the size of a session scales up enough that reception state information might not be kept for all receivers or the interval between reports becomes long enough that only one report might have been received from a particular receiver. The interarrival jitter field provides a second short-term measure of network congestion. Packet loss tracks persistent congestion while the jitter measure tracks transient congestion. The jitter measure may indicate congestion before it leads to packet loss. Since the interarrival jitter field is only a OLYMPIC Project Page 19/20

20 snapshot of the jitter at the time of a report, it may be necessary to analyse a number of reports from one receiver over time or from multiple receivers, e.g., within a single network. 2. References [1] R. Braden et al., "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, Internet Engineering Task Force, September [2] J. Wroclawski, "The use of RSVP with IETF Integrated Services," RFC 2210, Internet Engineering Task Force, September [3] J. Wroclawski, "Specification of the Controlled-Load Network Element Service," RFC 2211, Internet Engineering Task Force, September [4] S. Shenker et al., "Specification of Guaranteed Quality of Service," RFC 2212, Internet Engineering Task Force, September [5] D. Awduche et al., Requirements for Traffic Engineering Over MPLS, IETF RFC 2702, September [6] E. Rosen et al., Multiprotocol Label Switching Architecture, IETF RFC 3031, January [7] L. Andersson et al., LDP Specification, IETF RFC 3036, January [8] B. Thomas, E. Gray, LDP Applicability, IETF RFC 3037, January [9] D. Awduche et al., RSVP-TE: Extensions to RSVP for LSP Tunnels, IETF RFC 3209, December [10] A. Banerjee et al., Generalized Multiprotocol Label Switching: An Overview of Signaling Enhancements and Recovery Techniques, IEEE Communications Magazine, July [11] Nortel Networks White Paper, MPLS -An introduction to multiprotocol label switching [12] K. Nichols et al, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC2474, Internet Engineering Task Force, December [13] S. Blake et al, "An Architecture for the Differentiated Services," RFC2475, Internet Engineering Task Force, December [14] J. Heinanen et al, "Assured Forwarding PHB Group," RFC2597, Internet Engineering Task Force, June [15] V. Jacobson et al, "An Expedited Forwarding PHB Group," RFC2598, Internet Engineering Task Force, June [16] Y. Bernet et al, A framework for Integrated Services Operation over DiffServ Networks, RFC2998, Internet Engineering Task Force, November [17] S. Wenger, "RTCP-based feedback: Concepts and Message Timing Rules", work-in-progress, Internet-Draft "draft-wenger-avt-rtcp-feedback-01.txt", Internet Engineering Task Force, June [18] H. Schulzrinne et al, "RTP: A Transport Protocol for Real-Time Applications," RFC1889, Internet Engineering Task Force, Standards Track, January OLYMPIC Project Page 20/20