IPv6 based – On Demand Resource Management in Diffserv · PDF fileIPv6 based – On...

IPv6 based – On Demand Resource Management in Diffserv

(RMD)

Patrick Goering

Master of Science Thesis University of Twente

Electrical Engineering 14 August 2003

Examination committee:

Prof. Dr. Ir. Ignas Niemegeers (UT) Dr. Ir. Georgios Karagiannis (UT/Ericsson) first supervisor Dr. Ir. Geert Heijenk (UT/Ericsson) Dr. Ir. Victor Nicola (UT) Ir. Hommad el Allali (UT)

ii

iii

Abstract Through the years many heterogeneous telecommunication networks that support specific services have been developed. It is expected that the second generation systems, which are presently in use, will soon reach their capacity limitations, especially in densely populated areas. Thus a third generation mobile telecommunication system is being developed to support all distinctive applications provided by the second generation wireless networks, as well as introducing new ones. The Universal Mobile Telecommunications System (UMTS) is such a system that intends to provide global mobility and a wide range of services, including telephony, messaging, paging, Internet and broadband data connections. A UMTS network is built up from three interacting domains, the Core Network, the UMTS Terrestrial Radio Access Network (UTRAN) and the User Equipment. As the wired links used in the UTRAN usually contain a high number of leased lines, spread over a large geographical area over large distances, it is important to efficiently use the bandwidth of these expensive lines. The UTRAN specification allows for two types of transport networks to be applied, the ATM-based and the IP-based transport network. The ATM-based UTRAN satisfies the requirements to support a wide range of services. Thus it is expected that the IP based network should also satisfy these requirements. Real time applications require fast dynamic resource reservation, simplicity, low cost, easy to implement and good scaling properties. There are two different architectures defined to enable the use of Quality of Service (QoS) over IP based networks, Integrated Services (Intserv) and Differentiated Services (Diffserv). As Intserv and Diffserv cannot satisfy all UTRAN requirements, the Resource Management in Diffserv (RMD) scheme aims to satisfy them by enhancing the Diffserv architecture with new admission control and resource reservation concepts. The main goal of this thesis is to enhance the original RMD prototype implementation. This has to be done by implementing the protocol features that are currently not implemented and are needed with respect to the fulfillment of the IP-based UTRAN requirements. The protocol feature that is not implemented in the original RMD prototype implementation is the bi-directional reservation feature. Furthermore, this has to be done by integrating the RMD and RSVP (Resource Reservation Protocol) protocols, focusing on the IPv6 implementation. The RMD scheme consists of two protocols, a per hop reservation (PHR) protocol and a per domain reservation (PDR) protocol, which both have to be encapsulated in the RSVP messages. For the RMD and RSVP protocol integration two new RSVP objects have been defined that contain the PHR and PDR information. Both IPv4 and IPv6 versions of the RMD and RSVP protocol integration are implemented using the Linux environment. However, more focus has been given to the IPv6 version of this implementation. The RMD and RSVP protocol integration is denoted in this thesis as RSVPv2, while the RMD and RSVP protocol integration that is based on the IPv6 specification is denoted in this thesis as RSVPv2-IPv6. The correctness of both prototype implementations has been verified by using functionality experiments for the operation of the bi-directional feature and of the RSVPv2-IPv6 protocol during successful and unsuccessful reservations. The prototype implementations of the bi-directional feature and of the RSVPv2-IPv6 protocol show that their implementation in the Linux environment is feasible.

iv

v

Preface This thesis is the result of a final thesis project for the Department of Electrical engineering of the faculty of Electrical Engineering, Mathematics and Computer Science (EEMCS) at the University of Twente. Most of the work was conducted at the Wireless Multimedia Research (WMR) unit in Ericsson EuroLab Netherlands, Enschede, The Netherlands. The writing part of this thesis was mostly done at the Design and Analysis of Communications Systems group at the University of Twente. Regarding my M.Sc. thesis work, I would like to thank my examination committee for valuable inputs and comments. They are: Prof. Dr. Ir. Ignas Niemegeers, Dr. Ir. Georgios Karagiannis, Dr. Ir. Geert Heijenk, Dr. Ir. Victor Nicola, Ir. Hommad el Allali. I would like to thank my supervisor at Ericsson and later at the University, Georgios Karagiannis, for the many hours he spent on my thesis work and final report. The many discussions and conversations, comments and critics helped to make this thesis better. Also the colleagues at WMR deserve my thanks, especially Alex Stienstra who helped implementing and testing the IPv6 based prototype of RMD. Also, I want to thank Simon Oosthoek for his knowledge of the Linux environment, RMD and of course for the real coffee in the Lab. I also want to thank my brother for his humor and for being my brother. Finally, I would like to thank my parents for their support and understanding.

vi

vii

Abbreviations 3GPP Third Generation Partnership Project AAL2 ATM adaptation layer 2 AF Assured Forwarding BSB Blockade State Block CBQ Class Based Queueing Diffserv Differentiated Services DECT Digital European Cordless Telecommunications DS Differentiated Services DSCP Differentiated Service Code Point EF Expedited Forwarding FF Fixed Filter FIFO First In First Out GSM Global System for Mobile Communications Intserv Integrated Services IMQ Intermediate Queuing Device ISP Internet Service Provider NSIS Next Steps in Signaling PDP Packet Data Protocol PDR Per Domain Reservation PHB Per Hop Behavior PHR Per Hop Reservation PSB Path State Block PSTN Public Switched Telephony Network Qdisc Queuing discipline QoS Quality of Service RAT Robust Audio Tool RED Random Early Detection RIMA RMD Measurement-based Admission Control RNC Radio Network Controller RMD Resource Management in Diffserv RODA RMD On Demand RSB Reservation State Block RSVP Resource Reservation Protocol RTAP Real Time Application Program SEP Simple External Protocol SLA Service Level Agreement SLS Service Level Specification SMS Short Message Service TBF Token Bucket Filter TCSB Traffic Control State Block TOS Type of Service TTL Time To Live UDP User Datagram Protocol UMTS Universal Mobile Telecommunications System UTRAN UMTS Terrestrial Radio Access Network

viii

Table of Contents 1 Introduction ...........................................................................................................................................1

1.1 UTRAN QoS requirements.........................................................................................................2 1.2 UTRAN ATM based transport network .....................................................................................3 1.3 UTRAN IP based transport network...........................................................................................4

1.3.1 RMD in the IP based UTRAN............................................................................................5 1.4 Scope of this Thesis....................................................................................................................6 1.5 Organization of this Thesis.........................................................................................................6

2 Resource management in IP networks.................................................................................................7 2.1 Integrated Services Architecture.................................................................................................7 2.2 Differentiated Services Architecture...........................................................................................7 2.3 Resource Reservation Protocol (RSVP) .....................................................................................8

2.3.1 RSVP Signaling Message Types.........................................................................................8 2.3.2 RSVP Operation.................................................................................................................9

2.4 Resource Management in Diffserv (RMD)...............................................................................11 2.4.1 PHR Signaling Message Types.........................................................................................12 2.4.2 PDR Signaling Message Types.........................................................................................12 2.4.3 Normal Operation.............................................................................................................13 2.4.4 Fault handling operation...................................................................................................15

3 Protocol design.....................................................................................................................................17 3.1 RMD Bi-directional protocol design ........................................................................................17

3.1.1 Requirements....................................................................................................................18 3.1.2 Normal operation of RMD Bi-directional reservations.....................................................18 3.1.3 Protocol components used for RMD bi-directional reservation........................................21

3.2 RSVPv2 protocol design ..........................................................................................................25 3.2.1 Operation of the RSVPv2 protocol ...................................................................................25 3.2.2 Similarities and differences between IPv4 and IPv6 based RSVPv2 design specifications29 3.2.3 RSVPv2 protocol components..........................................................................................41

4 Prototype Implementation ..................................................................................................................45 4.1 Linux implementation environment ..........................................................................................45

4.1.1 Traffic control ...................................................................................................................45 4.2 Bi-directional prototype implementation..................................................................................47

4.2.1 Signaling messages...........................................................................................................48 4.2.2 Implementation overview .................................................................................................48 4.2.3 Ingress functionality..........................................................................................................49 4.2.4 Interior node.....................................................................................................................51 4.2.5 Egress functionality ..........................................................................................................52 4.2.6 Signaling message processing...........................................................................................54

4.3 RSVPv2 prototype implementation..........................................................................................56 4.3.1 Signaling messages...........................................................................................................56 4.3.2 Message interception alternatives.....................................................................................57 4.3.3 RSVP and RMD integration alternatives..........................................................................58 4.3.4 Implementation Overview.................................................................................................61 4.3.5 Ingress node......................................................................................................................64 4.3.6 Interior node.....................................................................................................................65 4.3.7 Egress node.......................................................................................................................67 4.3.8 RMD/RSVP (RSVPv2) daemon.......................................................................................68 4.3.9 Signaling message processing...........................................................................................70

5 Experimental Results...........................................................................................................................75 5.1 Bi-directional reservation experiments.....................................................................................75

5.1.1 Network setup...................................................................................................................75 5.1.2 Successful Reservation functionality experiments............................................................75 5.1.3 Unsuccessful Reservation functionality experiments........................................................77

5.2 RSVPv2-IPv6 experiments.......................................................................................................78 5.2.1 Network setup...................................................................................................................78 5.2.2 Successful Reservation functionality experiments............................................................80 5.2.3 Unsuccessful Reservation experiments.............................................................................82 5.2.4 Performance experiments..................................................................................................82

ix

5.2.5 Demonstration ..................................................................................................................83 6 Conclusions and future work .............................................................................................................85

6.1 Conclusions..............................................................................................................................85 6.2 Future Work .............................................................................................................................86

References ....................................................................................................................................................89 Appendix A: RSVP Objects based on IPv4 and IPv6 ..............................................................................93

x

1

1 Introduction Through the years many heterogeneous telecommunication networks, which support specific services have been developed. These networks are, however, unable to offer a common solution to the entire service spectrum. The first type of networks were developed to support voice services, i.e., telephony. Through the years these networks evolved from analogue to digital transmission networks. As the need for data transfers arose, dedicated data networks were developed. Later on, the wireless personal communication networks were developed. In particular, the use of mobile communications has increased rapidly during the last two decades. The first generation analogue cellular phones was introduced in the business sector in 1980’s. Cellular systems were developed to support two way voice service to wide-ranging vehicles on streets and highways by using high power transmitters. Cordless systems, were aimed to provide low mobility, low power, economical two way wireless voice communications inside buildings. The second generation digital systems have been recently introduced, in which different wireless networks were developed for specific applications. For example, cellular, e.g., GSM (Global System for Mobile Communications) and cordless, e.g., DECT (Digital European Cordless Telecommunications) digital telephone networks are used to support voice communication. Wide area data networks are used to support low data rate digital messages. Wireless local area networks, e.g., IEEE802.11 and ad-hoc networks, e.g., Bluetooth, are used to support high data rate digital messages in local areas (i.e., limited coverage). It is expected that these second generation systems will soon reach their capacity limitations, especially in densely populated areas. Thus there is a need for a new third generation mobile telecommunication system that is able to support all the distinctive applications provided by the second generation wireless networks as well as introducing new ones, such as Internet and multimedia applications (e.g., e-mail, world wide web and video). The Universal Mobile Telecommunications System (UMTS) is such a third generation (3G) mobile system being developed by the Third Generation Partnership Project (3GPP) [3GPP], which intends to provide global mobility and a wide range of services, including telephony, messaging, paging, Internet and broadband data. An abstract view of the UMTS network architecture is depicted in Figure 1-1. A UMTS network (see [3GPP-25401]) is built up from three interacting domains: Core Network, UMTS Terrestrial Radio Access Network (UTRAN) and User Equipment, also denoted as Mobile Station, which represents the mobile device carried and used by a mobile user. The core network provides support for circuit-switched and packet-switched services towards the mobile stations. The support for circuit switched services includes mobility management, access control and call control as well as interworking with external circuit-switched networks such as the public switched telephony network (PSTN). The support for packet switched services includes mobility management, access control and control of packet data protocol (PDP) contexts. In addition, the core network provides interworking with external packet-switched networks such as the public Internet. The UTRAN consists of a number of nodes as shown in Figure 1-1. The base station (i.e., Node B) provides the radio channel coding/decoding and transmission/reception function to and from mobile stations in its coverage area, which is called a cell. The RNC (Radio Network Controller) controls a number of base stations including the radio channels and the connections to mobile stations. Furthermore, the RNC can provide soft handover, combining and splitting between streams from different base stations belonging to the same mobile station. Moreover, the RNC is also responsible for the allocation of transport resources within the radio access network. The UTRAN transport network interconnects the RNC’s with the base stations. In particular, the transport of information takes place either between the base station and the RNC or between multiple RNCs. Two types of transport networks can be applied in the UTRAN, see [3GPP-25401]. The UTRAN ATM transport network, where the transport network is mainly consisting of ATM switches, and the UTRAN IP based transport network, where the transport network is mainly consisting of IP routers. Due to the characteristics of the UTRAN, strict QoS (Quality of Service) requirements are imposed on the used resource management schemes (see Section 1.1). An efficient QoS resource management scheme is already applied on the UTRAN ATM based transport network. (see Section 1.2). Finding an efficient QoS resource management scheme for the IP based

2

UTRAN (see Section 1.3) that will also meet these demands is a tough venture. Efforts to enable QoS in IP networks have led to the development of two main architectures, the Integrated Services (Intserv) [RFC1633] architecture and more recently, the Differentiated Services (Diffserv) [RFC2475] architecture. Currently, other resource reservation mechanisms are being specified, of which the most promising are described in [RFC3175], [BeCs00], [PaSc98], [ChLe99], [StZh99], [WhCr98]. While these schemes are able to satisfy the expectations that users of demanding real-time applications have, they fail to meet all the requirements like fast dynamic resource reservation, simplicity, low costs and being easy to implement along with good scalability properties. A new dynamic resource reservation mechanism, called Resource Management in Diffserv (RMD),which has been developed and described in [WeJa03a], [WeJa03b], [WeCs02] aims to correct this situation. RMD is a dynamic resource reservation management scheme that enhances the Diffserv architecture with new admission control and resource reservation concepts and can be used in many IP network environments. This thesis is enhancing the RMD scheme prototype implementation presented in [Jaco01] and [WeOo02], by implementing the protocol features that are currently not implemented and are needed with respect to the fulfillment of the IP-based UTRAN requirements. Furthermore, this has to be accomplished by integrating the RSVP and RMD protocols, focusing on its IPv6 implementation. In this thesis we denote the integrated RSVP- RMD version that is based on the IPv6 implementation as RSVPv2-IPv6.

RNC Mobile station

Node B

Node B

Node B

RNC

UTRAN

UTRAN

Transport Network

RNC

UMTS

IInntteerrnneett

Core Network

PPSSTTNN

Figure 1-1: UMTS network architecture

1.1 UTRAN QoS requirements A detailed description of the QoS requirements in UTRAN is given in [PaKa02]. This section gives a summary of these QoS requirements. The resource reservation between the edges of the radio access network is imposed by radio specific functions, not by the end-to-end reservation. The UTRAN supports the transport of UMTS radio frames, which are short segments of data, coded/decoded and transmitted/received by the base station. The UMTS radio frames must be delivered in a timely manner from the base station to the RNC and the other way around. If they arrive too late, the base station or RNC will discard them. Moreover, the wired links in a radio access network usually contain a high number of leased lines. Because the radio base stations are spread over a large geographical area over large distances, the costs for transmission links are high. This makes over-provisioning of resources an expensive solution. To efficiently utilize the bandwidth of the expensive transmission links statistical multiplexing is introduced by using IP-transport technology. For maximal utilization of the radio spectrum, precise timing mechanisms are active between base station and RNC. Fast and frequent handover operations between radio channels and radio base stations require fast and efficient management in the RAN. At each handover event, a resource reservation and release is needed and therefore the resource reservation protocol needs to be fast and will be used very frequently. Due to the nature of radio frame traffic flows it is needed that the resource reservation protocol is able to support bi-directional unicast reservations. In the UTRAN the RNC can initiate and manage the resource

3

reservations for both directions, to and from the base station, at the same time. Moreover, the bi-directional reservation needs to be done in a single round trip. The reservation scheme has to be simple to implement in interior nodes, because in most cases there are more interior nodes in the path than there are edge nodes. The number of interior nodes in a communications path depends on the network topology chosen by the RAN operator (e.g., ≤ 10 nodes). Therefore, the complexity of the reservation should be moved to the edge nodes as much as possible. The reservation protocol must be able to handle link failures that could result in re-routing and changing paths. The reservation protocol needs to support a severe congestion functionality that can be used to signal the ingress node to adapt to the current available bandwidth. The traffic from a large number of radio base stations needs to be supported by the same transport network. Even if a single radio base station generates a modest traffic volume, the total amount of flows for radio frame transport in the radio access network is very large. Therefore, the protocol needs to be scalable.

1.2 UTRAN ATM based transport network The Release 99 (R99) of the UMTS standard specifies that the transport medium in UTRAN is ATM. The protocol stack used in UTRAN for the user plane, according to Release 99 is shown in Figure 1-2. The radio transmission and reception in the air interface between the mobile station and the radio base station is performed by the radio physical layer. The radio signals received by the base station are sampled into radio frames. These radio frames are transported between base station (i.e., Node B) and RNC by using the radio frame transport layer. This is accomplished over ATM, by using the ATM adaptation layer 2 (AAL2) [ITU-Q2630]. The AAL2 layer provides the resource reservation support. The radio link layer is only used by the mobile station and the RNC and it includes extra radio functionality, such as packet segmentation and re-assembly and Radio Resource Control. The upper layers are used to transport the data traffic for the mobile station. If the mobile station is IP-aware, the upper layers will contain an IP-layer for the end-to-end data traffic. Note that this IP-layer is not used in the UTRAN. This IP-layer is used by the mobile station and the gateway located between the UMTS core network and the Internet.

UpperLayers

RadioLink

Layer

RadioLink

Layer

RadioPhysical

Layer

RadioPhysical

Layer

RadioPhysical

Layer

MobileStation

Node B IntermediateATM Switch

RNC

LinkLayer

LinkLayer

LinkLayer

LinkLayer

IP

UDP

RadioFrame

TransportLayer

RadioFrame

TransportLayer

PhysicalLayer

PhysicalLayer

PhysicalLayer

PhysicalLayer

FrameTransport

Layer

TowardCore Network

WirelessInterface

UTRAN

AAL2 AAL2 AAL2

ATM ATM ATM

Figure 1-2: User plane protocol layers in the ATM-based UTRAN (from [Jaco01])

4

1.3 UTRAN IP based transport network There are several reasons that make the IP technology a good candidate to be used for transmission in the transport network of the UTRAN. The IP technology is flexible since it can be applied on top of various and different link layer technologies such as Ethernet and SDH. The operator has the flexibility to choose any link layer technology without affecting higher layer functionalities. Due to this flexibility the popularity of the IP technology is increasing rapidly. One of the strengths of IP is its simple and flexible management procedure. When the IP technology is used in different parts of the UMTS network then a single network management system could be used, both for the core network and UTRAN. ATM-based systems are connection oriented, before any data can be transmitted a virtual connection must be in place. When comparing the IP-based system with the ATM-based system, the gain is seen in the statistical aggregation of traffic that can be done. This results in an increased transmission efficiency and reduced leasing cost for the operator. Moreover, in the UTRAN environment, the traffic paths between the RNC and several Node Bs can share bandwidth. Due to the statistical multiplexing used in the network, a reduction of the overall required bandwidth will result. Even more transmission efficiency with IP can be obtained by using header compression. Today's commercial IP networks are mainly optimized to carry best-effort traffic. The transport of radio frames in the radio access network puts real-time requirements on the underlying transport network. These requirements can be fulfilled by the connection-oriented transport networks, e.g., AAL2/ATM used by the ATM based UTRAN (See section 1.2). By, at a minimum, meeting the same requirements, the IP networks will be capable of providing the same behavior as the transport networks that are currently used by the ATM based UTRAN, while gaining the advantages of IP networking. Due to the benefits of using an IP-based transport medium instead of ATM, 3GPP has reconsidered the UTRAN architecture. The Release 5 (R5) of UTRAN specifies that the UTRAN transport network can be either ATM based or IP based (see [3GPP-25933]). However, in order to accomplish the IP based UTRAN, some shortcomings of the IP layer must be solved. These shortcomings are related to the support of the QoS requirements, see Section 1.1.

UpperLayers

RadioLink

Layer

RadioLink

Layer

RadioPhysical

Layer

RadioPhysical

Layer

RadioPhysical

Layer

MobileStation

Node B IntermediateRouter

RNC

LinkLayer

LinkLayer

LinkLayer

LinkLayer

IPIPIP IP

UDPUDP UDP

RadioFrame

TransportLayer

RadioFrame

TransportLayer

PhysicalLayer

PhysicalLayer

PhysicalLayer

PhysicalLayer

FrameTransport

Layer

TowardCore Network

WirelessInterface

UTRAN

Figure 1-3: User plane protocol layers in IP-based UTRAN (from [Jaco01])

The only difference between the protocol stacks used in the UTRAN ATM based transport network and the IP based transport network, is that the AAL2/ATM layers have been substituted with the UDP/IP layers. UDP (User Datagram Protocol) (see [RFC768]) is an unreliable transport protocol, see Figure 1-3. Release 5 of UTRAN specifies that the UTRAN IP based transport network should use the IPv6 version (see [RFC2460]). The IPv6 layer is designed to overcome some of the limitations of the current widely used IPv4 protocol (see [RFC791]). Compared to IPv4 the following main features are different in IPv6:

5

• larger address space (128 bits for IPv6 versus 32 bits for IPv4). • Optimized forwarding through the use of a routing hierarchy (smaller routing tables) • more efficient auto-configuration procedures • more compact header in spite of longer addresses which allows routers to process packets faster. • The option mechanism is entirely revised. In IPv6 the headers do not contain any variable length

optional element. Instead, extension headers are attached after the main header. Note that in IPv4 Options fell gradually out of use, mostly because of performance effects.

• the IPSec security protocol [RFC2401], [RFC2411] is provided as a standard feature into the IPv6 specification.

1.3.1 RMD in the IP based UTRAN The RMD scheme [WeJa03a], as described in [Jaco01] can satisfy the QoS requirements listed in Section 1.1 and therefore, it can be used in the IP based UTRAN for resource management provisioning. Figure 1-4 gives an overview of how the RMD scheme can be integrated into the IP based UTRAN architecture. The UTRAN IP based transport network is denoted in Figure 1-4 as a RMD domain, i.e., a domain where the RMD protocol is used. Each RNC and each base station (i.e., node B) is co-located with an edge node, i.e., a RMD node (router) located at the boundary of the RMD domain. The interior nodes are RMD nodes (routers) that are located in the interior of the RMD domain. Note that the edge nodes that are able to process the traffic that is incoming into the RMD domain are denoted as ingress nodes, while the edge nodes that are able to process the traffic that is outgoing the RMD domain are denoted as egress nodes.

UE

UE

RRNNCC

RMD Domain

PPDDRR

PPHHRR

Interior Edge Edge NNooddee BB

NNooddee BB

IIPP--bbaasseedd UUTTRRAANN

PPDDRR

PPHHRR

PPHHRR

CCoorree NNeettwwoorrkk

IInntteerrnneett

Figure 1-4: RMD in IP based UTRAN architecture

RMD is based on two main design goals (see WeCs02]). One of the goals is that RMD should be stateless on some nodes (e.g. interior routers). Thus no per-flow state is used, unlike RSVP [RFC2205], which installs one state for each flow on all the nodes in the communication path. The other goal is that RMD even though stateless should associate each reservation to each flow and therefore should provide certain QoS guarantees for each flow. In RMD these two goals are met by separating a complex reservation mechanism used in some nodes from a much simpler reservation mechanism needed in other nodes. In particular, it is assumed that the edge nodes will support “per-flow states” , i.e., are stateful. Another assumption is that the nodes between these stateful nodes, i.e., interior nodes can have a simpler execution by using only one aggregated reservation state per traffic class. The edges will generate reservation requests for each flow, similar to RSVP, but in order to achieve simplicity in interior nodes, a reservation-based approach on the number of the requested resources per traffic class is applied. The admission control is done on the resource parameter values included in the reservation requests, i.e. signaling messages and available resources per traffic class. The Differentiated Services (DS) field in the IP header and the Per-Hop Behavior (PHB) are the main building blocks used for service differentiation. The data packets are handled at each node according to the PHB indicated by the DS field (i.e., Differentiated Service Code Point (DSCP) [RC2474]) in the message header. Currently, the Diffserv architecture supports only static resource reservations. The RMD framework enhances Diffserv with dynamic resource management developed on Diffserv principles, which does not affect its scalability. This can be achieved by separation of the complex per domain

6

reservation mechanism from the simple reservation mechanism needed for a node. Accordingly, in the RMD framework, there are two types of protocols defined. The Per Domain Reservation (PDR) protocol and the Per Hop Reservation (PHR) protocol. The PDR protocol is used for resource management in the whole Diffserv domain and is used only on the edge nodes, while the PHR protocol is used for managing resources for each node, on per hop basis and is used on all nodes in the RMD domain (see Figure 1-4).

1.4 Scope of this Thesis The main goal of this thesis is to enhance the RMD scheme prototype implementation presented in [Jaco01] and [WeOo02]. This has to be done by implementing the protocol features that are currently not implemented and are needed with respect to the fulfillment of the IP-based UTRAN requirements. Furthermore, this has to be done by integrating the RMD and RSVP protocols, focusing on the IPv6 implementation. In this thesis we denote the integrated RMD and RSVP version as RSVPv2, while the integrated RMD and RSVP protocol version that is specifically based on the IPv6 specification is denoted as RSVPv2-IPv6. In particular, the objectives of this thesis work are: 1) Study the current design and implementation of the RMD protocol. 2) Study and identify the development and implementation steps of the RMD protocol features that are

currently not implemented and are needed with respect to the fulfillment of the IP-based UTRAN requirements, i.e., bi-directional reservations.

3) Implement the RMD protocol features that are currently not implemented and are needed with respect to the fulfillment of the IP-based UTRAN requirements. The implementation should be accomplished on software using the Linux operating system, the Python and the C and/or C++ programming languages.

4) Specify and accomplish functionality experiments on the implemented RMD protocol features that are currently not implemented and are needed with respect to the fulfillment of the IP-based UTRAN requirements.

5) Study and identify the development and implementation steps of the integrated RSVP and RMD version, which is based on the IPv6 implementation, i.e., RSVPv2-IPv6.

6) Implement the RSVPv2-IPv6 functionality blocks on software using the Linux operating system, the Python and the C and/or C++ programming languages.

7) Specify and accomplish functionality and performance experiments on the implemented RSVPv2-IPv6 prototype. Perform a basic demonstration using this prototype

The objectives (2), (5) and (6) are accomplished in co-operation with the other RMD team members, while the rest of the objectives are mainly accomplished by the author of the thesis.

1.5 Organization of this Thesis The rest of the thesis is organized as follows. Chapter 2 introduces existing IP based resource management schemes. It includes the description of the RSVP and RMD protocols. Chapter 3 describes the design of the enhanced RMD versions. It actually includes the design of the bi-directional protocol feature and the design of the RSVPv2 protocol. Chapter 4 presents the prototype implementation of the bi-directional protocol feature and the prototype implementation of the RSVPv2 protocol. Chapter 5 presents the experimental results from the prototype implementations. Finally, chapter 6 concludes and gives suggestions for further studies.

7

2 Resource management in IP networks Current Internet applications, from the most simple ones like e-mailing and web browsing going to high demanding real time applications like IP telephony and multimedia conferencing, raise the expectations that both, users and software developers of these applications have from the Internet. These demands have led to the development of QoS on the Internet as a necessity. To enable QoS on the best effort Internet model complexity in several aspects is introduced. Starting from applications, different networking layers and network architectures but also in network management and business models. All these aspects have been major research topics over the past few years. Finding an efficient solution for end-to-end QoS over Internet i.e. the IP networks that will satisfy both ISPs and their customers is a tough venture. This chapter introduces the two most promising existing QoS architectures, i.e., Integrated Services (Intserv) and Differentiated services (Diffserv). Furthermore, this chapter presents two signaling protocols that might be used in the UMTS Radio Access Network (UTRAN) to support dynamic resource reservation management.

2.1 Integrated Services Architecture The Integrated Services (Intserv) architecture [RFC1633] uses an explicit mechanism to signal per-flow QoS requirements to network elements (hosts, routers). Network elements, depending on the available resources, implement one of the defined Intserv services (Guaranteed or Controlled Load services) based on which QoS will be delivered in the data transmission path. The RSVP signaling protocol [RFC2205], [RFC2210] was designed as a dynamic mechanism for explicit reservation of resources in Intserv, although Intserv can use other mechanisms as well. It is initiated by an application at the beginning of a communication session. But, even though Intserv is designed to provide end-to-end QoS it is currently not widely deployed. Maintaining and controlling resources per flow introduces severe scalability problems at the core networks, where the number of processed flows can be in the millions range. Consequently the usage of the Integrated Services architecture is limited to small access networks where the number of flows using reservations is modest. The simplified RSVP/Intserv framework is shown in Figure 2-1. Every RSVP aware router in Intserv will be able to perform RSVP signalling, admission control, policing and scheduling.

Source

- RSVP signaling - Admission control - Policing - Scheduling - Softstate

RSVP Signaling Data packet flow

Destination

Figure 2-1: RSVP/Intserv framework

2.2 Differentiated Services Architecture The Differentiated Services (Diffserv) architecture [RFC2475] and [RFC2638] was introduced as a result of the efforts to avoid the scalability and complexity problems of Intserv. Per-flow state is pushed to the edges and the traffic through Diffserv routers is treated on aggregate basis. The service differentiation is achieved by means of Differentiated Service (DS) field in the IP header and the Per-Hop Behaviour (PHB) as main building blocks. At each node packets are handled according to the PHB invoked by the DS byte in the packet header. The PHB defines the externally observable behaviour at the node. Two PHBs have been defined, the assured forwarding (AF-) PHB [RFC2597] and the expedited forwarding (EF-) PHB [RFC2598]. The Diffserv domain will provide to its customer, which is a host or another domain, the required service by complying fully with the agreed Service Level Agreement (SLA). A SLA is a bilateral agreement between the boundary domains negotiated either statically or dynamically. The transit service to be provided with accompanying parameters like transmit capacity, burst size and peak

8

rate, is specified in the technical part of the SLA, i.e. the Service Level Specification (SLS). The Diffserv architecture is certainly promising, but there are a lot of open issues related to intra-domain resource allocation mechanisms and inter-domain communication in case of dynamic resource provisioning that need to be defined and researched. The simplified Diffserv framework is given in Figure 2-2. The Diffserv architecture may use different types of protocols to dynamically reserve resources in the Diffserv domain. The main ones are the RSVP, RSVP aggregation and RMD protocols.

Source

Destination

SLSSLS

• policing• scheduling

• policing• scheduling

Diffserv Domain 1 Diffserv Domain 2

• scheduling

SLS

Figure 2-2: Differentiated Services framework

2.3 Resource Reservation Protocol (RSVP) Currently, the most commonly used protocol for Quality of Service (QoS) support in the Internet is the Resource ReSerVation Protocol (RSVP) [ZhDe93], [RFC2205] and [RFC2209]. This protocol is used within the Integrated Services QoS architecture [RFC1633] to request from every node, located in a communication path, a specific QoS for a particular application data flow. In other words, RSVP is providing an end-to-end reservation and is applied (used) in all routers located in a communication path from a sender to a receiver. It supports multicast and unicast reservations with receiver initiated reservations and it adapts dynamically to route changes. A disadvantage of RSVP is related to the fact that the number of the reservation states maintained at each router are increasing linearly with the number of data flows supported by a router. This causes scalability problems in routers that have to support more than several thousands of flows simultaneously. Therefore, RSVP is only deployed in small networks, where the number of supported flows that are using the RSVP protocol, is low.

2.3.1 RSVP Signaling Message Types In order to request and maintain from every node, located in a communication path, a specific QoS for a particular application data flow, RSVP uses several signaling message types that are listed below: • Path: sent by every RSVP sender host downstream along the route provided by the routing protocol.

This message follows the same path that the user data follows and a path state is installed in every node along the way. The state includes traffic characteristics and also the IP address of the previous hop.

• Resv: sent by a receiver towards a sender along the same path followed by the user data packets, which belong to the same flow. To accomplish this, the IP address of the previous hop from the path state is used. A reservation state is installed in every node along the way followed by the Resv message. The state includes a flowspec (the desired QoS) and a filterspec (the data packets to receive the QoS defined by the flowspec).

• PathTear: this message follows exactly the same path followed by the PATH message and it removes on each (RSVP aware) node that it passes, both RSVP states, i.e., path and reservation states belonging to the same flow.

9

• ResvTear: this message follows exactly the same path followed by the Resv message and it removes on each (RSVP aware) node that it passes, the reservation states belonging to the same flow. The path state is not removed.

• PathErr: sent (hop by hop) upstream towards the sender application by a node, when an error is detected in the functionality associated with the Path message. The path state is not changed.

• ResvErr: sent (hop by hop) downstream towards the receiver by a node, when an error is detected in the functionality associated with the Resv message.

• ResvConf: When a confirmation request (object) is contained in the Resv message, the sender will send a ResvConf towards the receiver.

2.3.2 RSVP Operation RSVP is a receiver initiated protocol, since the receiver of the data flow initiates and maintains the actual reservation and not the sender. The sender transmits a Path message towards the receiver. This message is used to create a path state associated to a specific flow ID in every intermediate node. The state contains backward routing information, allowing the receiver to send Resv messages that have to follow the same path as the path followed by the data flow from sender to receiver. When the receiver gets the Path message, it creates a reservation state and sends a Resv message towards the sender. Every intermediate node sets up a reservation state according to the desired QoS and forwards the Resv message. The Resv message is also used to refresh the state. Figure 2-3 shows how a reservation for a new flow is made.

Receiver

RSVP Path

RSVP Resv

Figure 2-3: Resource reservation for a new flow in IntServ using RSVP

If the requested reservation can be supported on all nodes in the communication path from sender to receiver, the sender starts sending user data. The RSVP reservation states are temporary states (soft states) that have to be updated regularly. This means that PATH and RESV messages will have to be re-transmitted periodically. If these states are not refreshed then the reservation will automatically be released. Figure 2-4 shows the whole process of admission control of a new QoS request and refreshing of reservations.

RSVP PathRSVP Path

RSVP Path

Data traffic

RSVPNode

RSVPNode

RSVPSender

RSVPReceiver

RSVP ResvRSVP Resv

RSVP Resv

RSVP PathRSVP Path

RSVP Path

RSVP ResvRSVP Resv

RSVP Resv

Figure 2-4: Normal operation for successful reservation

10

In Figure 2-5 the explicit release procedure by a receiver is shown, while Figure 2-6 shows the explicit release procedure by the sender. Both release procedures are needed, because RSVP supports multicast with multiple senders and receivers. This way one sender or receiver can unjoin a multicast group. The ResvTear message only removes the reservation state in the RSVP nodes, the path state is not affected. The PathTear message on the other hand removes both the reservation state and the path state from the RSVP nodes.

RSVPNode

RSVPNode

RSVPSender

RSVPReceiver

RSVP ResvTearRSVP ResvTear

RSVP ResvTear

Figure 2-5: Explicit release by the receiver

RSVP PathTearRSVP PathTear

RSVP PathTear

RSVPNode

RSVPNode

RSVPSender

RSVPReceiver

Figure 2-6: Explicit release by the sender

If a node in the communication path cannot forward the Path message any further, that node sends a PathErr message back to the sender. If a reservation (reservation state) cannot be made a ResvErr message is send back to the receiver by the node that could not support the requested QoS. See Figure 2-7 and Figure 2-8 for a flow diagram of an unsuccessful Path and Resv message respectively.

RSVP PathRSVP Path

RSVPNode

RSVPNode

RSVPSender

RSVPReceiver

RSVP PathErrRSVP PathErr

X

Figure 2-7: Unsuccessful processing of a Path message

11

RSVPNode

RSVPNode

RSVPSender

RSVPReceiver

RSVP ResvRSVP Resv

RSVP ResvErrRSVP ResvErr

X

Figure 2-8: Unsuccessful processing of a Resv message

RSVP supports transparent operation through routers that do not support RSVP. This can be detected by the receiver, allowing the applications to know the QoS could not be guaranteed (in a RSVP way) in the entire communication path. RSVP control messages are send as raw IP datagrams and the Path, Pathtear and ResvConf messages include the router alert option, because they have to be processed by all RSVP nodes, while they are not addressed to an intermediate router.

2.4 Resource Management in Diffserv (RMD) Resource Management in Diffserv (RMD) (see e.g., [WeJa03a], [WeJa03b]) is a dynamic resource reservation protocol based on Differentiated Services (Diffserv) principles that is used to reserve network resources without suffering form the scalability problems of RSVP. It is a single domain edge to edge reservation scheme, that extends the standardized Diffserv Per Hop Behavior (PHB) with resource provisioning and control. It is assumed that some kind of external mechanism exists for signaling reservation requests to the edge nodes in the Diffserv domain. The edges use RMD to decide if the request can be admitted. RMD separates the problem of a complex reservation for the entire domain from a simple reservation within just one node. For this purpose, RMD defines two major protocol concepts (see Figure 2-9), the per-hop reservation (PHR) protocol and the per-domain reservation (PDR) protocol. Note that an edge node is a node that is located at the boundary of the RMD domain, while an interior node is a node located in the interior of the RMD domain. An ingress node is an edge node that processes the traffic that is coming in the RMD domain. An egress node is an edge node that processes the traffic that is going out of the RMD domain.

Edge Node (PHR and PDR functionality) Interior Node (PHR functionality only)

QoS Request

QoS Request Forwarded to Next Hop

PDR Message

PHR PHR PHR

Figure 2-9: Per-hop reservation (PHR) and per-domain reservation (PDR) protocols

12

The RMD framework currently specifies two different PHR protocols: • Reservation-based PHR (RODA) [WeJa03b]

Each node in the communication path from an ingress node to an egress node keeps only one reservation state per traffic class (i.e., per DSCP). A threshold that specifies the maximum number of reservable resource units is maintained.

• Measurement-based Admission Control PHR (RIMA) [RIMA] All nodes check the availability of resources before flows are admitted and reservation states are not installed. Measurements are done per traffic class (per DSCP), on the real average traffic (user) data load.

The PHR protocol is used to either install reservation states or monitor available resources in each interior node in a communication path. There is one reservation state per PHB in all nodes in the communication path. The reservation is done in terms of resource units, which may be based on a single parameter such as the bandwidth or on more sophisticated parameters. When a reservation is made, the number of requested resource units is added to the number of currently reserved resources per PHB. The PDR protocol manages the reservation of the resources in the entire Diffserv domain and is only implemented in the edge nodes of the domain. The PDR protocol is the link between the external resource reservation schemes and the PHR protocol. In the context of RMD, it is possible for the PDR to inter-operate with one or more PHR protocols. Furthermore, the PDR should always be able to interpret the external resource requests and map them into an appropriate Diffserv Code Point (DSCP) and the parameters for the used PHR protocol. RMD can make use of the Diffserv classes Expedited Forwarding (EF) [RFC2598] and Assured Forwarding (AF) [RFC2597] QoS classes. The EF class provides low loss, low latency, low jitter and an assured bandwidth. The AF classes give different levels of assurance in terms of packet forwarding with different levels of drop precedence.

2.4.1 PHR Signaling Message Types All PHR messages are generated by the ingress node and sent in the direction of the far-end receiving host. These messages are processed by all interior nodes in the communications path. The PHR signaling messages must follow the same path as the user data messages. Therefore the same source and destination addresses are used in the IP packets and the routing should be independent of the DSCP value. The RMD messages must never leave the Diffserv domain and are therefore discarded by the egress node. In the first prototype the PHR messages are carried in the IP header options field of an Ipv4 packet, as defined in [RFC791]. The following PHR messages are defined in RODA: • PHR_Resource_Request: It is used to initiate or update the PHB reservation state on all nodes located

in the communication path between the ingress and the egress nodes according to an external QoS request.

• PHR_Refresh_Update: This signaling message is used to refresh the PHB reservation soft state on all nodes located in the communication path between the ingress and egress nodes. If the resources belonging to a flow are not refreshed within a refresh period, then they are automatically subtracted from the resources maintained by the PHB reservation state.

• PHR_Resource_Release: This is used to explicitly release reserved resources for a particular flow from a PHB reservation state.

It is important that PHR messages are not lost in the Diffserv domain and therefore, they have a higher priority than usual data packets.

2.4.2 PDR Signaling Message Types These messages are generated and processed only by the RMD edge nodes and not by the interior nodes. A PDR message is encapsulated and sent together with a PHR message in one single IP packet. • PDR_Reservation_Request: This message is generated by the ingress node in order to initiate or

update the PDR state in the egress node. This PDR signaling message is typically sent together with a PHR_Resource_Request message.

13

• PDR_Refresh_Request. The ingress node sends this message to the egress node to refresh the PDR states located in the egress node. This PDR signaling message is sent together with the PHR_Refresh_Update message.

• PDR_Release_Request. This message can be used if the external protocol uses release messages. Many resource reservation protocols, including all protocols that do not use a soft-state reservation principle, use release messages to release reservations. This PDR signaling message is sent together with the PHR_Resource_Release.

• PDR_Reservation_Report. This report message is sent by the egress node back to the ingress node to report that an IP packet containing a PHR_Resource_Request message and/or a PDR_Reservation_Request message has been received. Furthermore, this message reports the status of the PHR_Resource_Request and the reservation to the ingress node.

• PDR_Refresh_Report. This message is similar to the PDR_Reservation_Report message, but is used to report the status of the PHR_Refresh_Update and PDR_Refresh_Request messages instead.

• PDR_Congestion_Report: This message is sent by the egress node to notify the ingress node about severe congestion.

• PDR_Request_Info: This message is sent together with a PHR signaling message from the ingress node to the egress node. It contains the information that is required by the egress node to associate the PHR signaling message to the PDR flow ID and/or the IP address of the ingress node.

A PDR_Request_Info message is encapsulated in the PHR_Resource_Request, PHR_Refresh_Update and PHR_Release_Request messages. While some of the PDR messages are sent together with a PHR message, it is also possible that a PDR message is sent by its own. Therefore PDR-only packets also get a higher priority then usual data packets.

2.4.3 Normal Operation Normal operation refers to the situation when no problems are occurring in the network, such as route changes, link failure, severe congestion, loss of signaling messages, etc. In Figure 2-10, an example is given that demonstrates how RMD operates under normal conditions, using the RODA PHR protocol. In this example, it is assumed that a sender wants to reserve resources for a new flow using a sender-initiated end-to-end resource reservation scheme. The request is reservation-based and contains information like a flow identifier and quantitative QoS parameters. The flow identifier is typically the destination IP-address and the destination port number used by all packets in the flow. The QoS parameters can be a token bucket specifier, containing parameters such as data bit rate and maximum packet size.

External QoS message PHR Message with Encapsulated PDR Message PDR Only Message

1 2 4

3 Sender Receiver

Ingress

Egress

Diffserv domain with RMD

Figure 2-10: Message interaction in RMD, normal operation

When an external end-to-end QoS request arrives at the ingress node, the request is classified into an appropriate traffic class by giving the flow a DSCP value, corresponding with a Diffserv class PHB. The PDR state is associated with a flow ID. If the QoS request is satisfied locally in the ingress node, then the

14

ingress generates both a PHR_Resource_Request message and a PDR_Reservation_Request message, encapsulated in the PHR message. The IP header will have the same values as the data packets for the flow, to make sure that they follow exactly the same path as the data flow. This means that the source address is the IP address of the far-end sender and the destination address is the IP address of the far-end receiver. The DSCP of the IP packet is the same as the traffic class the flow is associated with. The signaling messages get a higher priority than the user data messages by using a local DSCP. Along the path, all interior nodes will process the PHR_Resource_Request. They identify the DSCP from the IP header and, if possible, reserve the requested resources carried in the PHR_Resource_Request. The node reserves the requested resources by adding the requested amount to the total amount of reserved resources for the particular DSCP. All interior nodes ignore the PDR message in the IP packet. Finally, when the PHR and PDR messages arrive at the egress node, both are decapsulated and processed. The egress node discards them and does not forward them out of the domain, although the destination address is the far-end receiver. At this point the egress node can do a local per-flow admission control based on the PHR functionality. If the egress node accepts the new flow, then a new PDR state is installed, including the flow identifier, and a PDR_Reservation_Report message is sent back to the ingress node to inform about the successful reservation. Finally, the external request is re-created from the information in the PDR_Reservation_Request and sent to the next hop. When the PDR_Reservation_Request reaches the ingress node, it configures the policy map to accept the new flow. All traffic that matches the flow identifier is mapped into the assigned DSCP and receives the expected behavior by all interior nodes. Each flow is policed and shaped by the ingress node according to the reservation, so that no one can over-load the network. RMD uses soft states and therefore it is necessary to refresh all reservations in the domain. The ingress node will generate the PDR_Refresh_Request messages in order to refresh the PDR soft state in the egress node and a PHR_Refresh_Update is generated to refresh the PHR soft state in all nodes in the path. The refreshing process is similar to the process of initiating reservations. A timer will be used by the ingress node to specify when the reservations must be refreshed and the egress node will only send back a PDR_Refresh_Report to the ingress node. The PHR resources in any node are released if there are no PHR_Refresh_Update messages received during a refresh period. Figure 2-11 shows the whole process of admission control of a new QoS request and refreshing of reservations.

PHR_Resource_RequestPDR_Reservation_Request

PHR_Refresh_UpdatePDR_Refresh_Request PHR_Refresh_Update

PDR_Refresh_Request PHR_Refresh_UpdatePDR_Refresh_Request

PHR_Resource_RequestPDR_Reservation_Request PHR_Resource_Request

PDR_Reservation_Request

PDR_Reservation_Report

PDR_Refresh_Report

QoSRequest

QoSRequest

Data traffic

InteriorNode

InteriorNode

IngressNode

EgressNode

PHR_Resource_ReleasePDR_Release_Request PHR_Resource_Release

PDR_Release_Request PHR_Resource_ReleasePDR_Release_Request

Figure 2-11: Normal Operation for successful reservation

15

In the next example, one of the interior nodes does not have available resources and cannot admit the requested flow. When the interior node receives a PHR_Resource_Request message, it checks the resource parameters and tries to reserve the requested amount of resources. If that is not possible, the interior node will mark the PHR message and forward it to the next hop. A marked PHR_Resource_Request message is ignored by all interior nodes and just forwarded to the egress node. The PHR_Refresh_Update messages are processed even when they are marked. When the marked PHR_Resource_Request message reaches the egress node, the egress does not install any new reservation. It will instead send a marked PDR_Reservation_Report back to the ingress to inform about the failed reservation. The Time-To-Live fields (TTL) in the IP header of the PHR message and in the PDR message are used to keep track of the number of nodes with a successful reservation. Then, the ingress releases the already made reservations in the interior nodes. Also the sender is informed about the rejection using the external protocol. Figure 2-12 shows the process of a flow that is rejected by an interior node.

PHR_Resource_Request PDR_Reservation_Request

PHR_Resource_Request (Marked) PDR_Reservation_Request

PDR_Reservation_Report (Marked)

QoS Request

QoS Request Rejected

Interior Node

Interior Node

Ingress Node

Egress Node

M

Interior Node

PHR_Resource_Request PDR_Reservation_Request

PHR_Resource_Release PDR_Release_Request

Figure 2-12: Resources unavailable at an interior node

When a node receives a PHR_Resource_Release, it identifies the DSCP and estimates the refresh period where it last processed a PHR_Refresh_Update.

2.4.4 Fault handling operation The PHR signaling messages and subsequently the PDR signaling messages might be dropped, for example due to link failure. This is problematic, since the dropped signaling messages might have reserved resources in some interior nodes in the communication path before they are dropped. These reservations will be occupied until they are released by the soft state timeout and will not be used in the mean time. The ingress nodes are responsible for handling the loss of the PHR signaling messages. After sending a PHR_Resource_Request message together with a PDR_Reservation_Request, the ingress node will wait for a pre-defined amount of time to receive the PDR_Reservation_Report message. If the ingress node does not receive this acknowledgment within the pre-defined time, it will conclude that an error has occurred. The ingress node will not send any new PDR and PHR signaling messages associated with the same flow during the first subsequent refresh period. In this way, all the possible unused reserved resources will implicitly be released within one refresh period. If the problem is a route or link failure, a re-transmission of the reservation message is likely to fail again. Severe congestion is an error state in a node. It can occur because of route changes, a link failure or just a long period of congestion. There are two types of severe congestion handling, severe congestion with PHR marking and severe congestion with proportional marking.

2.4.4.1 Severe congestion handling with PHR marking When severe congestion occurs, the ingress node must be informed. If the severe congestion occurs in an interior node, then this node sets the severe congestion flag in the next PHR signaling message and forwards it to the egress node. The egress node will inform the ingress node by sending a report message with the severe congestion flag set. After receiving this message, the ingress node discards all new incoming requests for the severely congested path, for a certain time.

16

A flow diagram showing the severe congestion handling is depicted in Figure 2-13, where the severe congestion flag is set in a PHR_Refresh_Update and as a result, no data traffic is sent to that communication path. Note that this separation is only for illustrative purposes, since once a severe congestion occurs in the path independently of which messages are marked with severe congestion, all flows sent on that path will be blocked. Optionally, the ingress may notify the sender using the external protocol with a tear down message.

PHR_Refresh_UpdatePDR_Refresh_Request PHR_Refresh_Update (Severe)

PDR_Refresh_Request

PDR_Refresh_Report (Severe)

Tear DownReservation

InteriorNode

InteriorNode

IngressNode

EgressNode

S

X

Data traffic

Data TrafficBlocked

Figure 2-13: Severe congestion handling with PHR marking

2.4.4.2 Severe congestion handling with proportional marking This section describes the severe congestion handling which uses proportional marking, see [WeJa03a]. An interior node that is under severe congestion may loose data packets. This interior node will mark ongoing data packets, proportionally and according to the number of packets that are dropped. Therefore, in case of severe congestion the egress node, receives a number of marked and unmarked data packets. Using this information, the egress node can define the dropping probability, i.e., PDrop. For each flow ID, the egress node will count the number of marked bytes and the number of unmarked bytes, and it will calculate the blocking probability PDrop using the following formula:

um

mdrop BB

B

+=P

where Bm = number of marked bytes and Bu = number of unmarked bytes. The egress node creates then a PDR_Congestion_Report message. It will set its “S” bit to 1 and it will also include the PDrop information into the message that will be sent towards the ingress node. The ingress node, based on this blocking probability, might terminate the flow. That is, for a higher blocking probability there is a higher chance that the flow will be terminated. If a flow needs to be terminated, the ingress node will generate a "PHR_Resource_Release" message for this flow.

number user data bytes number marked bytes

PDR_Congestion_Report (S, Pdrop)

Tear Down Reservation

Interior Node

Interior Node

Ingress Node

Egress Node

S

X

Data traffic

Data Traffic Blocked

number unmarked bytes

PHR_Resource_Release PHR_Resource_Release

PHR_Resource_Release

Figure 2-14: Severe congestion handling with proportional marking

17

3 Protocol design The original version of the RMD prototype implementation presented in [Jaco01] does not include the implementation of the bi-directional feature that is needed with respect to the fulfillment of the IP-based UTRAN bi-directional requirement. In the UTRAN the RNC can initiate and manage the resource reservations for both directions, to and from the base station, at the same time. Therefore, the original RMD prototype implementation (see [Jaco01]) has to be extended by adding the design and implementation of the bi-directional feature. Furthermore, this chapter presents the design of the integration of the RMD and RSVP protocols. Existing designs and implementations of the RMD and RSVP protocols have been studied, such as the original RMD implementation [Jaco01], the ISI RSVP implementation [ISI-RSVP] and the design steps of the RSVP and RMD integration that focuses on the IPv4 specification [Shi02]. Both IPv4 and IPv6 versions have been considered during the design of the integrated protocol. However more focus has been given to the IPv6 version of this design. The RMD and RSVP protocol integration is denoted in this thesis as RSVPv2, while the RMD and RSVP protocol integration that is specifically based on the IPv6 specification is denoted in this thesis as RSVPv2-IPv6.

3.1 RMD Bi-directional protocol design In an IP-based RAN there is a need for bi-directional reservation of resources (see section 3.4.2). The RNC has to support the initiation and management of resource reservations for both directions, i.e., RNC towards the mobile users, i.e., forward direction, and mobile users towards the RNC, i.e., reverse direction. It is possible to realize a bi-directional reservation by combining two uni-directional reservations. Moreover, the communication paths used in the forward and reverse directions may be different. Figure 3-1 depicts a RMD domain where the RNC is co-located with edge1, which is the RMD edge node that initiates the bi-directional reservation. Furthermore, a base station is co-located with edge2, which is another RMD edge node. The forward path represents the communication path that interconnects edge1 with edge2 in the forward direction, while the reverse path represents the communication path that interconnects edge2 with edge1 in the reverse direction. Both forward and reverse paths can consist of one or more interior nodes. Note that on both edge nodes and for each bi-directional flow, ingress and egress functionality is required. The ingress functionality processes the RMD messages that are incoming the RMD domain, while the egress functionality processes the RMD messages that are outgoing the RMD domain. In both directions the same ingress and egress nodes are needed in the communication path. Furthermore, in each edge node, the IP address of the output buffer does not need to be the same as the IP address of the input buffer. Note that an interface has an output buffer and an input buffer.

18

forward path

reverse path

ingress

egress

Base stationEdge2

PHRrequest

RMD domain

ingress

egress

RNCEdge1

PDRreport

Interior

Interior Interior

Interior

Figure 3-1: communication between edge1 and edge2

3.1.1 Requirements In order to support bi-directional reservations, the edge nodes of the RMD domain have to support several requirements: • edge nodes must be able to distinguish between uni-directional and bi-directional reservation request,

refresh and update PDR messages. A “B” flag in the header of the PDR signaling messages (see [ReKa02]) should be used.

• bi-directional reservations can be asymmetric, the number of requested resources can be different between the forward and reverse direction. Thus parameters for the reservation in the reverse direction, i.e., from egress node to ingress node, must be included in the RMD signaling message.

• when a bi-directional reservation request arrives at the egress node, a uni-directional PHR signaling message will have to be constructed corresponding to the data included in the bi-directional message. This uni-directional message, including a PDR message, is then sent in the reverse direction.

• ingress and egress nodes will have to maintain a PDR state that includes the bi-directional flow specification. This is needed, because when a reservation request, refresh or release message arrives at the egress node, the correct action also has to be taken for the reverse direction. Thus a reservation request, refresh or release message has to be sent for the corresponding bi-directional reservation. Similarly, when the ingress node receives a reservation request for the reverse direction it has to be able to update the corresponding bi-directional reservation state.

3.1.2 Normal operation of RMD Bi-directional reservations This section describes the normal operation of RMD bi-directional reservations. The normal operation consists of successful and unsuccessful bi-directional reservations. In order to simplify the description of the successful and unsuccessful procedure for bi-directional reservations, it is considered that the forward and reverse paths of reservations, described in section 3.1.2.1 and section 3.1.2.2, are the same.

3.1.2.1 Successful reservation This section describes the successful reservation for a RMD bi-directional reservation. When the ingress node (see Figure 3-2) receives a request for a bi-directional reservation from the external protocol, it will

19

send a PHR_Resource_Request message (PHR_Res_Req(forward)) towards the egress node. This message encapsulates a PDR_Reservation_Request with the “B” flag on. Furthermore, this message contains the IP address of a receiving port of the ingress node.

PHR_Res_Req(forward) PDR_Res_Req(bi-forward) PHR_Res_Req(forward)

PDR_Res_Req(bi-forward)

QoS Request

Interior1 Node

Interior2 Node

Edge1 Ingress Node

Edge2 Egress Node

PHR_Res_Req(reverse) PDR_Res_Req(reverse)



PHR_Res_Req(forward) PDR_Res_Req(bi-forward)

Figure 3-2: Successful bi-directional reservation request

The egress node notices the “B” flag in the PDR message and it will reuse the PHR_Resource_Request and the encapsulated PDR message for the reverse direction. The PHR_Resource_Request is then denoted as (PHR_Res_Req(reverse). The differences between the fields in the two messages are:

• The IP source address of the PHR_Res_Req(reverse) is equal to the IP destination address of the PHR_Res_Req(forward). The IP destination address of the PHR_Res_Req(reverse) is equal to the IP source address of the PHR_Res_Req(forward) message. However, note that when the IP address of the output buffer is not the same as the IP address of the input buffer of an edge node and source and destination addresses cannot be swapped, then an additional procedure has to be used. This procedure has to identify and associate the IP addresses of the input and output buffers of each edge node.

• The PHR_Res_Req(reverse) contains the value of the “Reverse Requested Resources” field that was included in the PDR_Reservation_Request.

• The PDR_Reservation_Request message has the “B” flag off. For the PHR_Refresh_Update and the PHR_Release_Request messages, see Figure 3-3 and Figure 3-4, respectively, similar functionality has to be used. Note that PDR report messages are not used for these cases.

PHR_Ref_Upd(forward) PDR_Ref_Upd(bi-forward) PHR_Ref_Upd(forward)

PDR_Ref_Upd(bi-forward)

QoS Request

Interior1 Node

Interior2 Node

Edge1 Ingress Node

Edge2 Egress Node

PHR_Ref_Upd(reverse) PDR_Ref_Upd(reverse)


PHR_Ref_Upd(forward) PDR_Ref_Upd(bi-forward)


Figure 3-3: Successful bi-directional reservation refresh

20

PHR_Rel_Req(forward) PDR_Rel_Req(bi-forward) PHR_Rel_Req(forward)

PDR_Rel_Req(bi-forward)

QoS Request

Interior1 Node

Interior2 Node

Edge1 Ingress Node

Edge2Egress Node

PHR_Rel_Req(reverse) PDR_Rel_Req(reverse) PHR_Rel_Req(reverse)

PDR_Rel_Req(reverse) PHR_Rel_Req(reverse) PDR_Rel_Req(reverse)

PHR_Rel_Req(forward) PDR_Rel_Req(bi-forward)

Figure 3-4: Successful bi-directional reservation release

3.1.2.2 Unsuccessful reservation This section describes the unsuccessful reservation for a RMD bi-directional reservation. A reservation can be unsuccessful when a node does not have enough available resources. The unsuccessful reservation is initiated in the same way as the successful reservation procedure, but now one of the interior nodes that is unable to satisfy the reservation request, marks the PHR_Res_Req(forward) message by setting both the “M” bit and the “T” bit to “1” . This interior node will include the TTL value of the IP packet that carried the message in the PDR_TTL field of the encapsulated PDR message. Figure 3-5 shows the situation where an interior node that is located on the forward path is not able to satisfy a bi-directional reservation request. In this situation when the egress node receives a marked PHR_Res_Req(forward), by checking the “B” and “M” bits, it will deduce that one of the interior nodes did not have enough available resources for the bi-directional reservation request. It then stops the bi-directional reservation request procedure and directly sends a PDR_Reservation_Report(bi-forward) to the ingress node. This report includes the values of the “B” , “M” and “PDR_TTL” fields. The ingress node calculates the number of hops to the rejecting node from the PDR_TTL value that was included in the PDR message. Furthermore, the ingress node starts a partial release procedure, by setting the TTL value of the IP packet to the number of hops, i.e., the PDR_TTL value, minus 1. The node before the one that was not able to satisfy the request will be the last one to process the PHR_Rel_Req(forward) message before it is discarded.

PHR_Res_Req(forward)PDR_Res_Req(bi-forward) PHR_Res_Req(forward)

PDR_Res_Req(bi-forward) PHR_Res_Req(forward-M)PDR_Res_Req(bi-forward)

QoSRequest

InteriorNode

InteriorNode

Edge1IngressNode

Edge2EgressNode

PDR_Reservation_Report(bi-forward-M)

M

PHR_Rel_Req(forward)PDR_Rel_Req(bi-forward)

Figure 3-5: Unsuccessful bi-directional reservation and partial release on the forward path

It is also possible for the reservation request to fail on the reverse path as can be seen in Figure 3-6, where an interior node located on the reverse path is not able to satisfy the bi-directional reservation request. In this situation, the bi-directional reservation request procedure on the forward path will be the same as for

21

the successful reservation. The egress node will create the PHR and PDR messages as described under the successful reservation. The TTL value of the IP packet that contains the PHR_Res_Req(bi-forward) message will be copied into the TTL field of the IP header of the PHR_Resource_Request packet. Because interior nodes do not need to differentiate between uni- and bi-directional reservations the interior node with insufficient resources available behaves the same as in the case of the unsuccessful bi-directional reservation procedure on the forward path. It marks the PHR_Res_Req(forward) message by setting both the “M” bit and the “T” bit to “1” . It also includes the TTL value of the IP packet that carried the message in the PDR_TTL field of the encapsulated PDR message. The ingress node will start a partial release procedure by sending a PHR_Release_Request(forward) towards the egress node. The ingress node calculates the number of hops to the rejecting node from the PDR_TTL value that was included in the PDR message. A partial release procedure is started by setting the TTL value of the IP packet to the number of hops, i.e., PDR_TTL, minus 1. The egress node receives the PDR_Rel_Req(bi-forward) and creates the PDR_Rel_Req(reverse) message in a similar way as in the successful bi-directional reservation release procedure. Furthermore, it will copy the TTL value included in the IP packet that is carrying the PDR_Rel_Req(bi-forward) into the TTL field of the IP packet containing the PDR_Rel_Req(reverse) message. The node before the one that was not able to satisfy the request will be the last one to process the PHR_Rel_Req(reverse) message before it is discarded.

PHR_Res_Req(forward)PDR_Res_Req(bi-forward) PHR_Res_Req(forward)

PDR_Res_Req(bi-forward) PHR_Res_Req(forward)PDR_Res_Req(bi-forward)

QoSRequest

InteriorNode

InteriorNode

Edge1IngressNode

Edge2EgressNode

PHR_Res_Req(reverse)PDR_Res_Req(reverse)PHR_Res_Req(reverse)

PDR_Res_Req(reverse)PHR_Res_Req(reverse-M)PDR_Res_Req(reverse)

M

PHR_Rel_Req(forward)PDR_Rel_Req(bi-forward) PHR_Rel_Req(forward)

PDR_Rel_Req(bi-forward) PHR_Rel_Req(forward)PDR_Rel_Req(bi-forward)

PHR_Rel_Req(reverse)PDR_Rel_Req(reverse)

Figure 3-6: Unsuccessful bi-directional reservation and partial release on the reverse path

3.1.3 Protocol components used for RMD bi-directional reservation This section describes the protocol components that are used in the design of the RMD bi-directional reservation feature. The following sections describe the protocol components used in an ingress, interior and egress node separately, but a single node should be able to support all three functions at the same time. The design consists of two parts: the control plane and the data plane. The data plane focuses on receiving, processing and transmitting data packets, while the control plane focuses on processing signaling packets to control and manage the data plane. Several protocol components used in the design of the bi-directional feature are identical to the ones used in the first version of the RMD prototype, see [Jaco01]. The bi-directional feature is affecting only of the implementation of the ingress and egress nodes and not the implementation of the interior nodes. However, the protocol components used in the interior node will also be presented here for completeness reasons. The Simple External Protocol (SEP) [Jaco01] is used as an external QoS protocol in the first version of the RMD prototype [Jaco01].

22

3.1.3.1 Ingress node The protocol components used in the ingress node are depicted in Figure 3-7, Figure 3-8 and Figure 3-9. In particular, Figure 3-7 shows that the ingress node supports ingress and egress functionalities. The ingress functionality is triggered either by an external QoS request, or by the egress functionality, via PDR Report messages. These messages are received by the egress functionality via the reverse path. Figure 3-8 and Figure 3-9 show the protocol components that are used to support the ingress and egress functionality, respectively. These protocol components are:

• SEP Filter: filters packets based on the SEP flow identifier, using a map from flow identifiers to classes.

• PDRingress Queuing Discipline is responsible for sending PHR and PDR reservation and refresh messages. It has only one class, so filters do not apply to this queuing discipline.

• PDRegress queuing discipline is executed inside the egress functionality and replies to the PHR and PDR signaling messages for a flow. At the same time, it discards them so that no RMD signaling messages leave the Diffserv domain.

• PHRegress Queuing Discipline is responsible for catching PHR and PDR signaling messages for new flows.

• Ingress daemon: is responsible for the message interaction with SEP and mappings between SEP and the RODA PHR. It is implemented in the ingress functionality and inspects SEP packets with the IP router alert option. It performs admission control on SEP messages, based on which it installs or removes the new queuing disciplines on the correct outgoing interface. This daemon manages the PDRingress queuing disciplines in the kernel.

• Egress daemon: processes the events from the PHRegress queuing disciplines, performs admission control and forwards the SEP packets to the next hop.

• Interior Daemon: gives the opportunity to dynamically modify certain parameters into a queuing discipline. For the time being this module is not activated.

• the DS filter, PHR filter and Packet Scheduling components are identical to the ones used in the Interior node (see Section 3.1.3.2).

forward path

reverse path

Ingress functionality

Egress functionality

PDR report

Ingress edge

Figure 3-7: Components used in an ingress node for support of bi-directional reservation

23

PDR ingress daemon

PDRingress Queuing

Discipline

Packet scheduler (FIFO, PRIO,

CBQ)

Data Flow Out

Data Flow In

RMD Signaling SEP SignalingIngress functionality

Control path

Data path

PHR filter (signaling) / Interior daemon

SEP filter

DS filter TBF shaper

Figure 3-8: RMD protocol components used for ingress functionality

PDR egress daemon


CBQ)

Data Flow Out Data Flow In

RMD/SEP Signaling RMD Signaling


Control path

Data path

PHR filter (signaling) /

Interior daemon

RSVPv2 filter DS filter

PDRegress Queuing Discipline

FIFO

FIFO

PHRegress Queuing discipline

Figure 3-9: RMD protocol components used for egress functionality

24

3.1.3.2 Interior node: The protocol components used in the interior node are shown in Figure 3-10:

• DS filter: is a combination of the Tc_index filter and the dsmark queuing discipline (See [Alme01]). The dsmark queuing discipline is used to get and set the DSCP field in an IP packet. The tc_index filter selects the appropriate traffic classes based on the DSCP value.

• PHR filter: is dependent on the chosen PHR protocol. In the case of RODA the number of reserved units is managed here. Severe congestion is detected and signaled to the egress node. When a reservation fails, when not enough resources are available, the IP TTL value of the packet is signaled to the edges, which is used during the partial release procedure.

• Packet scheduler: manages the de-queuing of packets sent out through the network interface. It selects the class that is allowed to send the next packet based on its priority. Several classes and queuing disciplines with different properties can be connected together to get precise control over the priorities that are assigned to the different packets. Some possibilities (see [tc-man] and [tc-howto] ) are:

o PRIO (priority queuing) is a simple classful queuing discipline that can contain a number of classes of differing priority. The classes are de-queued in descending order of priority.

o CBQ (Class Based Queueing) is a classful queuing discipline that can be used to implement a hierarchy of classes of different priorities. Each class is assigned a given amount of bandwidth. It is also possible to let classes borrow bandwidth from each other.

o FIFO (First In First Out) is a simple queue that inserts packets at the tail of a list when they are en-queued. A de-queued packet is taken from the head of the list and when the list is full packets are dropped. This can be used for EF traffic.

o RED (Random Early Detection): is a classless queuing discipline that starts to drop packets with a configurable probability when the queue reaches a certain average length. The probability increases as the queue grows bigger. This can be used to implement AF (Assured Forwarding) traffic.

DS filter


CBQ) Data Flow Out

Data Flow In

RMD Signaling

RMD Signaling

Control path

Data path

PHR filter (signaling) / Interior daemon

Figure 3-10: Protocol components used in interior node

25

3.1.3.3 Egress node The protocol components used in the ingress node are depicted in Figure 3-11, Figure 3-8 and Figure 3-9. In particular, Figure 3-11 shows that the egress node, similarly to the ingress node, supports ingress and egress functionalities. The egress functionality is triggered by the RMD messages that arrive from the forward path. The ingress functionality is triggered by the egress functionality via PHR request messages. The protocol components used in the ingress and egress functionalities are identical to the ones described in Section 3.1.3.1.

forward path

reverse path


Ingress functionality

PHR request

Egress edge

Figure 3-11: Components used in an egress node for support of bi-directional reservation

3.2 RSVPv2 protocol design This chapter describes the design of the RSVP and RMD protocol integration. By integrating both protocols, per flow reservation states are only used in the parts of the network where the number of flows is not large. Scalability is achieved by maintaining a low number of reservation states where the number of flows is large. Both IPv4 and IPv6 versions have been considered during the design of the integrated protocol. However more focus has been given to the IPv6 version of this design. The RMD and RSVP protocol integration is denoted in this thesis as RSVPv2, while the RMD and RSVP protocol integration that is based on the IPv6 specification is denoted in this thesis as RSVPv2-IPv6. Due to time constraints it has been decided that this design should not include any bi-directional reservation procedures, but only unidirectional reservation procedures. However, it should not require extensive work to add the bi-directional feature at a later stage.

3.2.1 Operation of the RSVPv2 protocol Several RSVP and RMD protocol integration alternatives are described and compared in [Shi02]. An alternative denoted as Alternative_5 has been chosen in [Shi02] as the one that satisfies the predefined requirements of the RSVPv2 protocol. The RSVPv2 flow diagrams presented in this section represent the flow diagrams associated to the Alternative_5 introduced in [Shi02]. This integration alternative assumes (requires) that the PATH message includes information that can be used to generate the resource units required by the PHR protocol. Furthermore, in this solution it is considered that the RSVP PATH message is used to carry the PHR messages that are traveling from the ingress node towards the egress node. Also RSVP RESV messages are used to carry PDR report messages. Moreover, it is considered that the edge nodes do maintain backward routing information. The resource units per certain DSCP required for the initiation of the PHR protocol can be derived from the Traffic Specification carried by the PATH message. When a RSVP message arrives at a node, it has to be intercepted, and processed by this node as described in Table 3-1.

26

Originating from Destined for Action of node Outside RMD Inside RMD Add PHR/PDR information Outside RMD Outside RMD RSVP only functionality Inside RMD Outside RMD Remove PHR/PDR

information Inside RMD Inside RMD Interior node functionality

Table 3-1: Types of node actions when a RSVP message is received

The node should check whether this message has been received from inside or from the outside of the RMD domain. When the message remains in the RMD domain the node should function as an interior node only. When a message remains out of the RMD domain the node should process it as an RSVP message only. When it arrived from the outside of the RMD domain, and it is destined for the inside of the RMD domain, the RSVP message has to be rebuilt (see [RFC2205]) and the PHR and PDR information has to be added to` the RSVP message when needed. When a message arrived from the inside of the RMD domain and destined for the outside of the RMD domain, the RSVP packet has to be rebuild without using the PHR and PDR information.

3.2.1.1 Normal Operation In this section the integration between the RMD and RSVP protocols during a normal operation procedure is shown. In particular, Figure 3-12 and Figure 3-13 depict the successful reservation and Figure 3-14 depicts the unsuccessful reservation. In the successful reservation procedure the “PHR_Resource_Request” and “PHR_Refresh_Update” messages are encapsulated within a modified RSVP PATH message, denoted as RSVP PATH*. The interior nodes do not process the modified RSVP PATH* message as a standard RSVP PATH message but as a PHR message. The interior node is only checking and processing the PHR information without checking the other RSVP objects of the RSVP PATH message. The edge nodes process the RSVP PATH* message as a standard RSVP PATH message and as a PHR/PDR message. When the egress node receives the PATH message it creates either the PDR_Reservation_Report or the PDR_Refresh_Report messages which are encapsulated within a new RSVP RESV message, denoted as RSVP RESV*. This message will include among normal RMD information also the, “M” and “S” bits that were carried by the “PHR_Resource_Request” or the “PHR_Refresh_Update” , respectively. The interior nodes do not process the RSVP RESV* message as a standard RSVP RESV message. The PHR_Resource_Release message is encapsulated within a modified RSVP PATHtear message, denoted as RSVP PATHtear*. Similar to the previous situation, the interior nodes do not process the RSVP PATHtear* message as a standard RSVP PATHtear message, but as a PHR message. The ingress nodes process this message as a RSVP PATHtear and as a PHR/PDR message. The RSVP reservation state is released by the RSVP PATHTear or RSVP RESVTear that are processed by ingress and egress as standard RSVP messages. In the unsuccessful reservation procedure, similar to the successful reservation procedure, the “PHR_Resource_Request” message is encapsulated within a modified RSVP PATH message, denoted as RSVP PATH*. The egress node will have to store the “M” and “S” bits associated with each PHR_Resource_Request message. The PDR_Reservation_Report message is encapsulated within a modified RSVP PATHerror message denoted as RSVP PATHError*. This message will include among normal RMD information also the “M” and “S” bits, stored by the edge node. When the ingress node receives the PDR_Reservation_Report with the “M” bit set to “1” it will have to initiate an RSVP PATHtear* that will have to be sent towards the receiver. The PHR_Resource_Release message in this case is encapsulated within a RSVP PATHtear message denoted as RSVP PATHtear*. The RSVP PATHtear* message represents a modified RSVP PATHtear message which is generated locally at the ingress node during the procedures shown in Figure 3-14. The RSVP PATHtear* encapsulates a PHR_Resource_Release message.. Additionally a PDR_ReqInfo is encapsulated. This RSVP PATHtear* message is not processed by the interior nodes as a standard RSVP PATHtear message but as a PHR_Resource_Release message.

27

RRSSVVPP RREESSVV** (PDR_Reservation_Report)

RSVP RESV* PDR_Refresh_Report

RSVP PATH

RSVP PATH

RSVP PATH

RRSSVVPP PPAATTHH** (PHR_ Resource_Request)

((PDR_ReqInfo*)) RRSSVVPP PPAATTHH** (PHR_Resource_Request)

((PDR_ReqInfo*)) RRSSVVPP PPAATTHH** (PHR_Resource_Request)

((PDR_ReqInfo*))

Ingress Interior Egress Interior

RRSSVVPP PPAATTHH** (PHR_Refresh_Update)

((PDR_ReqInfo*)) RRSSVVPP PPAATTHH**

(PHR_Refresh_Update) ((PDR_ReqInfo*))

RRSSVVPP PPAATTHH** (PHR_Refresh_Update)

((PDR_ReqInfo*))

Data Traffic

RSVP PATH

Figure 3-12: RSVPv2 flow diagram for a successful reservation procedure (without showing the explicit release procedure)


RSVP PATHtear* (PHR_Resource_Release)

((PDR_ReqInfo*))

RSVP PATHtear* (PHR_Resource_Release

(PDR_ReqInfo*))

RSVP RESVtear*

RSVP PATHtear


((PDR_ReqInfo*))

RSVP PATHtear

RSVP RESVtear

RSVP RESVtear

Figure 3-13: RSVPv2 flow diagram for a successful reservation procedure (the explicit release procedure)

28


RSVP PATH* (PHR_Resource_Request)

((PDR_ReqInfo*))

RSVP PATH* (PHR_Resource_Request(M ))((PDR_ReqInfo*))

RSVP PATHerror* (PDR_Reservation_Report

(M marked))

RSVP PATH


((PDR_ReqInfo*))

RSVP PATH* (PHR_Resource_Request)

((PDR_ReqInfo*))

RSVP PATHerror

MM

Figure 3-14: RSVPv2 flow diagram for an unsuccessful reservation procedure

3.2.1.2 Fault handling This section presents the RSVP – RMD integration during the Fault Handling operation. In particular, this section describes the severe congestion handling which uses proportional marking, see [WeJa03a]. An interior node that is under severe congestion may loose data packets. This interior node will mark on going data packets, proportionally and according to the number of packets that are dropped. Therefore, in case of severe congestion the egress node, receives a number of marked and unmarked data packets. Using this information, the egress node can define the dropping probability, i.e., PDrop. For each flow ID, the egress node will count the number of marked bytes and the number of unmarked bytes, and it will calculate the blocking probability PDrop using the following formula:

um

mdrop BB

B

+=P

where Bm = number of marked bytes and Bu = number of unmarked bytes. The egress node creates then a PDR_Congestion_Report message which is encapsulated within a modified RSVP PATHerror message, denoted as RSVP PATHerror*. The egress node will set its “S” bit to 1 and it will also include the PDrop information into the message that will be sent towards the ingres node. The ingress node, based on this blocking probability, might terminate the flow. That is, for a higher blocking probability there is a higher chance that the flow will be terminated. If a flow needs to be terminated, the ingress node will generate a "PHR_Resource_Release" message for this flow. The PHR_Resource_Release message is encapsulated within the RSVP PATHtear* message.

29

User Data User Data

RSVP PATHerror* PDR_Congestion_Report ("S" marked + PDrop)


((PDR_ReqInfo*)) RSVP PATHtear* (PHR_Resource_Release)

((PDR_ReqInfo*)) RSVP PATHtear* (PHR_Resource_Release)

((PDR_ReqInfo*))

Ingress Interior Interior Egress

Terminate Flow?

Yes

User Data

User Data (marked bytes)

User Data (unmarked bytes)

RSVP PATHerror

S User Data

RSVP PATHtear

Figure 3-15: RSVPv2 flow diagram for severe congestion handling using proportional marking

3.2.2 Similarities and differences between IPv4 and IPv6 based RSVPv2 design specifications

This section presents the similarities and differences between the IPv4 and IPv6 based RSVPv2 design specifications. Note that an initial design specification of the IPv4 based RSVPv2 protocol has been given in [Shi02]. In Section 3.2.2.1 a comparison between the IPv4 and IPv6 headers is given. Section 3.2.2.2 describes the comparison between the RSVP based on IPv4 and on IPv6 specifications. The comparison between the IPv4 and IPv6 designs that are used in the “RMD in IP option” and “RMD in IP payload” scenarios is given in Section 3.2.2.3.

3.2.2.1 Comparison between IPv4 and IPv6 headers The IPv6 header counts for six fields and two addresses, see Figure 3-16:

• Version field: 4 bits – specifies the format of the IP packet header. • Traffic Class: 8 bits – Internet traffic priority value • Flow label: 20 bits – used for specifying special router handling from source to destination(s) for

a sequence of packets. • Length of payload: 16 bits - Length of payload without including the length of the IPv6 header. • Type of the next header: 8 bits – specifies the next encapsulated protocol. • Hop limit: 8 bits – gives the maximum number of routers to pass though. • Source IP address: 128 bits – IPv6 address of the sender. • Destination IP address: 128 bits – IPv6 address of the intended receiver.

30

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- |Version| Tr. Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Source Address | + + | | +---------------------------------------------------------------+ | | + + | Destination Address | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3-16: IPv6 header

The IPv4 header counts for ten fixed header fields, two addresses, and some options, see Figure 3-17: • Version: 4 bits – specifies the format of the IP packet header. • H. Length (Header Length): 4 bits – specifies the length of the IP packet header in 32 bit words. • TOS (Type of Service): 8 bits – specifies the parameters for the type of service requested. • Total length (in bytes): 16 bits - the sum of the length of the IPv4 header and the payload. • Identification: 16 bits – used to identify the fragments of one datagram from those of another. • Flags: 3 bit – used to control the fragmentation of the datagram. • Fragment offset: 13 bits – used to reassemble fragmented datagrams. • Time To Live (TTL): 8 bits – a timer field used to track the lifetime of the datagram. • Protocol: 8 bits – specifies the next encapsulated field. • Header Checksum: 16 bits – Checksum of the IP header and the options. • Source IP address: 32 bits – IP address of the sender. • Destination IP address: 32 bits – IP address of the intended receiver • Options (variable length)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|Version|H. Length| TOS (Type of Service) | Total length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Identification |flags| Fragment offset |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|(TTL)TimeToLive| Protocol | Header checksum |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Source IP address |+---------------------------------------------------------------+| Destination IP address+---------------------------------------------------------------+/ options (if any) 40 bytes each option /\ \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3-17: IPv4 header

Comparing IPv6 and IPv4, the following can be deduced: • in IPv6 the only field that has the same size as in IPv4 is the Version field: 4 bits. For IPv4 the

version field is: 0100, while for IPv6, the code is: 0110; • six fields that are used in IPv4 are not anymore used in IPv6. These six IPv4 fields are: Header

Length, Type of Service, Identification, Flags, Fragment offset and Header Checksum. • three IPv4 fields were renamed. These are:

o Length becomes in IPv6: Payload Length were only the payload length is specified (without including the length of the IPv6 header);

o Protocol Type becomes in IPv6: Next Header, that reflects the type of the first extension header;

o Time to Live becomes in IPv6: Hop Limit that counts the number of hops that processed the IPv6 packet.

31

• the option mechanism is entirely revised. In IPv6 the headers do not contain any variable length optional element. Instead, extension headers are attached after the main header. Therefore, there is no need in IPv6 for a header length field (IHL). Note that in IPv4 Options fell gradually out of use, mostly because of performance effects.

• two new fields are added: Traffic Class and Flow Label.

3.2.2.2 Comparison between the RSVPv1 objects based on IPv4 and IPv6 specifications

RSVPv1 supports both IP versions, i.e., IPv4 and IPv6. A RSVPv1 message consists of a common header, followed by a body consisting of a variable number of variable-length, typed "objects". Every RSVPv1 object, as described in [RFC2205], consists of one or more 32-bit words with a one-word header (see Figure 3-18).

Length (bytes) Class-Num C-Type

Object contents (variable length)

0 7 15 23 31

Figure 3-18: RSVP Object format

The fields used in a RSVP object, as shown in Figure 3-18, are as follows: • Length: 16 bits - contains the total object length in bytes. It must always be a multiple of 4 and at

least 4 bytes. • Class-Num: 8 bits - identifies the object class. Each object class has a name. • C-Type: 8 bits - It is the Object type, unique within Class-Num

The Common Header used in RSVP is identical for both IP versions and is depicted in Figure 3-19. The objects used in the RSVPv1 version as described in [RFC2205] are briefly introduced in Appendix A. The main difference between the objects for IPv4 and IPv6 is the C-type and the length of the fields. When the IPv6 addresses are used, then the IPv6 version of the object is different than the IPv4 version of the object. Some commonly used RSVP objects are:

• SESSION: This contains the IP destination address, the IP protocol id, a flags field and a destination port.

• RSVP_HOP: This objects carries the IP address of the node that sends this message and the interface from which the message originated.

• TIME_VALUES: This object contains the refresh period R as it is used by the creator of the message. This object is the same for the IPv4 and IPv6 versions.

• STYLE: This defines the reservation style and style-specific information. This object is the same for the IPv4 and IPv6 versions.

• FLOWSPEC: This defines the desired QoS in a RESV message by specifying the token bucket rate, token bucket size, peak data rate, minimum policed unit and maximum packet size. This object is the same for the IPv4 and IPv6 versions.

• FILTERSPEC: This defines a filter on source IP address and port for which data packets should receive the desired Qos as specified by the FLOWSPEC object.

• SENDER_TEMPLATE: This object defines the IP address and port of the sender. Its definition is the same as the FILTERSPEC object.

• SENDER_TSPEC: This defines the traffic characteristics of a sender’s data flow in PATH messages. Its definition is the same as the FLOWSPEC object.

• ERROR_SPEC: This object specifies an error in a PATHerr, RESVerr or a confirmation in a RESVConf message.

• SCOPE: This object carries a list of IP addresses to which the information in the message is to be forwarded. It can be used in RESV, RESVerr or RESVtear messages.

32

Common Header: The common object used in all RSVPv1 messages is the “Common Header “ part (see Figure 3-19). Its format is identical for both IPv4 and IPv6 versions.

Vers Flags Msg Type RSVP Checksum

Send_TTL (Reserved) RSVP Length

0 7 15 23 31

Figure 3-19: RSVP Common Header format

• The fields used in the “Common Header” part, as shown in Figure 3-19, are as follows: • Version: 4 bits - the RSVP Version used. • Flags: 4 bits - Reserved, no flag bits are defined yet. • Msg Type: 8 bits - There are 7 RSVP messages defined, i.e. PATH, RESV, PATHtear,

RESVtear, PATHerror, RESVerror, RESVConf. • Send_TTL: 8 bits - The IP TTL value with which the message was sent. • RSVP Length: 16 bits - The total length of this RSVP message in bytes, including the common

header and the variable-length objects that follow. • RSVP Checksum: 16 bits – checksum of the RSVP message

Mismatch between RSVP Send_TTL and IP TTL fields in RSVPv2 In RSVPv2 the interior nodes do not support standard RSVP resource reservation messages, but the edge nodes do. The nodes outside the RMD domain use RSVP for resource reservation. RSVP keeps a Send_TTL field in the RSVP packet to be able to detect RSVP unaware nodes in the communication path. The IP TTL field is decremented in every node in the communication path, but the RSVP TTL field only in RSVP aware nodes. The nodes outside the RMD domain should not notice that the interior nodes have processed the RSVP messages as PHR messages only. Therefore, the egress node has to decrement the RSVP Send_TTL field with a value equal to the number of interior nodes plus one (the egress itself). The egress node can calculate the number of interior nodes in the communication path by subtracting the RSVP TTL with the IP TTL.

3.2.2.3 Comparison between the format of the RSVPv2 messages based on the IPv4 and IPv6 specifications

The design of RSVPv2 based on the IPv4 specification (see [ReKa02], [Shi02]) is using two approaches in defining the format of the RSVPv2 messages:

• “RMD in IP option” : this approach keeps the same format as in the first version of the RMD prototype [JaOo02], [Jaco01], while using the RSVP message format instead of UDP. In other words, the PHR/PDR information is carried within an IP option. The main advantage of this method is that it provides a hierarchical structure of the information carried by a RSVP message. In this way, the only information that will be checked and used by the interior nodes is the PHR information. It is therefore, expected that the processing time of PHR information in the interior nodes will not severely change compared to the current RMD prototype implementation.

• “RMD in IP payload” : in this approach the RMD information is included in an object that has the same format as an RSVPv2 object. This RMD object is located in the IP payload and after all the RSVPv2 objects. One main advantages of this approach is that the size of the RMD information does not have strict limitations. Another advantage is that its design is independent on the used IP version. The main disadvantage is related to the delay that is imposed to an interior node when reading the RMD information from the RSVP message.

3.2.2.3.1 Similarities and differences between “RMD in IP Option” approaches based on IPv4 and IPv6 specifications

The RMD in IP option keeps the RMD message either in the IPv4 Option of the IP header or in the IPv6 Hop by Hop header field.

33

RMD in IP option based on IPv4 The PHR message format is exactly the same as the description used in the RODA protocol ([WeJa03b]). The PHR protocol messages are inserted in an IP header Options field, as defined in the [RFC791], when IPv4 is used. This IPv4 option header field has the following format (see Figure 3-20).

0 31+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| Option Type | Option Length |P-LEN| P-ID |S|M| C |T|Unused|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Requested Resources | Delta T | Shared % |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-. .. PDR encapsulated data .. Variable length field used to .. encapsulate PDR messages .| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Figure 3-20: PHR Option field in the IPv4 Option header field

Option Type: 8-bit identifier of the type of option. The semantics of this field are specified in [RFC791]. Option Length: 8-bit field. This is specified in [RFC791] and represents the length of the Option-Data field of this option, in octets. The option data field consists of all fields included in the option field of the IPv4 header and are placed after the "Option Length" field. P-LEN (PHR length): 3-bit field. This specifies the length in octets of the specific PHR information data included in the "Option-Data" field. This information does not include the encapsulated PDR information. The value "0" specifies that this IP option field contains only PDR information that starts after the "Requested Resources" field. P-ID (PHR type): 4-bit field. This specifies the PHR type. For RODA this field must be set to one. S (Severe Congestion): 1-bit field. The sender MUST set the "S" field to 0. This field is set to 1 by an interior or edge node when a severe congestion situation occurs. M (Marked): 1-bit field. The sender MUST set the "M" field to 0. This field is set to 1 by an interior or edge node when the node cannot satisfy the "Requested Resources" value. C (Message type): 3-bit field. This field specifies the type of the PHR message. T (TTL active): 1-bit field. The sender MUST set the "T" field to 0. This field is set to 1 by an interior or edge node when the node will have to include the TTL value from the header of the IP packet into the PDR message. Requested Resources: 16-bit field. This field specifies the requested number of units of resources to be reserved by a node. The unit is not necessarily a simple bandwidth value. It may be defined in terms of any resource unit (e.g., effective bandwidth) to support statistical multiplexing at message level. Delta T: 8 bit field. The value of this field MAY be set by any ingress node into (only) "PHR_Resource_Release" messages. It specifies a percentage that represents the ratio between a time lag, say T_lag, and the length of the refresh period, say T_period. Where, T_lag represents the difference between he departure time of the previous sent "PHR_Refresh_Update" message and the departure time of the "PHR_Resource_Release" message. T_period represents the length of the refresh period. This information MAY be used by any node during an explicit release procedure. When any node receives a "PHR_Release_Request" message it MUST identify the DSCP and estimate the refresh period where it last signaled the resource usage (where it last processed a "PHR_Refresh_Update"). This MAY be done by giving the opportunity to an ingress node to calculate the time lag, say ∆t, between the last sent "PHR_Refresh_Update" message and the "PHR_Release_Request" message. The value of this time lag (∆t), is first normalized to the length of the refresh period, say T_period. In other words the ratio between this time lag, ∆t, and the length of the refresh period, T_period, is calculated. This ratio is then introduced into the "Delta T" field of the

34

"PHR_Release_Request". When a node receives this "PHR_Release_Request" message it will have to store its arrival time. Then it will calculate the time difference, say Tdiff, between this arrival time and the start of the current refresh period, T_period. Furthermore, this node will have to derive the value of the time lag, ∆t, from the "Delta T" field. This can be found by multiplying the value included in the "Delta T" field with the length of the refresh period, T_period. If the derived time lag, ∆t, is smaller than the calculated time difference, T_diff,, then this node MUST decrease the PHB reservation state with the number of resource units indicated in the "Requested Resources" field of the "PHR_Release_Request" message, but not below zero. Shared % (Shared percentage): 8 bit field: This value specifies if a load sharing situation occurred on a communication path or not. The ingress node sets this value to 100. If load sharing occurred in a node then the node will have to divide the shared percentage value to the number of equal cost paths. PDR encapsulated data PDR encapsulated information data. This field is only processed by the edge nodes. The PDR message can be carried either inside the PHR IP option or somewhere else in the IP packet. Figure 3-21 shows an example of a PDR message format based on the IPv4 version.

0 31+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| PDRID |MsgType|S|M|B| Unused |F-Type |EP-Type| PDR-TTL |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Reverse Requested Resources | Shared % |Dropping rate %|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Ingress (Egress) Address (IPv4) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || Flow-ID (length varies) || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || Variable length field || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3-21: PDR message structure when IPv4 is used PDRID: 4 bits. A value that identifies the PDR protocol. Must be zero for this experimental protocol. MsgType: 4 bits. The type of PDR message. See below for a table of recognized values. S (Severe Congestion): 1 bit. The severe congestion flag was set in the PHR Reserve Request or PHR Refresh Request message. This flag only applies to PDR Reserve Report and PDR Refresh Report messages. M (Marked): 1 bit. The marked flag was set in the PHR Reserve Request or the PHR Refresh Request message. This flag only applies to PDR Reserve Report and PDR Refresh Report messages. B (Bi-directional): 1 bit. The request is Bi-directional. This flag only applies to PDR Reserve Request, PDR Refresh Request and PDR Release Request messages. F-Type: 4 bits. The Flow-ID type identifier. Defined by the PDR protocol. It tells the ingress and egress nodes what kind of data is contained in the Flow-ID and its length. Every edge node MUST be configured to understand the F-Types. EP-Type: 4 bits. Identifies the external protocol. Defined by the PDR protocol. It tells the ingress and egress nodes what kind of external protocol (EP) data is contained in the Variable length field. Every edge node MUST be configured to understand the EP-Type. If this field is 0000 then the Variable length field can be used for other purposes, i.e., future specifications.

35

PDR-TTL: 8 bits. The TTL value introduced by a node that could not admit or process a PHR request. Reverse Requested Resources: 16 bits. This field specifies the requested number of units of resources that have to be reserved by a router in the reverse direction when bi-directional reservation functionality is supported. The unit is not necessarily a simple bandwidth value: it may be defined in terms of any resource unit (e.g., effective bandwidth) to support statistical multiplexing at packet level. This field is can not be used with this PDR. Shared % (Shared percentage): 8 bit field: This value specifies if a load sharing situation occurred on a communication path or not. The ingress node sets this value to 100. If load sharing occurred in a node then the node will have to divide the shared percentage value to the number of equal cost paths. Dropping rate % (Dropping rate percentage): 8 bit field: This value specifies the dropping rate percentage and is used during severe congestion. The ingress node will use this rate as a blocking probability, to terminate the particular flow. Ingress (Egress) Address: 32 bits. When the PDR message goes from ingress to egress this field represents the ingress address. In the other direction this field represents the egress address. Flow-ID: Length depends on F-Type. This part is dependent on the F-Type. For example this may be the normal RSVP Flow-ID consisting of destination IP address, protocol ID and destination port. The length would then be 7 bytes in the IPv4 case. Sometimes it may only be necessary to use the Flow-ID to match replies with flows. In that case it is enough if the Flow-ID is a 16 bits number. Variable length field: This field can be used for different purposes. For example it can be used either for including external protocol data or for future specifications. Length depends on EP-Type. This field is used when tunnelling external protocol data between the ingress and egress. Any kind of data may be placed here, but it must be specified by the PDR for each valid EP-Type. When using SEP, this is the simplified token bucket specifier defined by the SEP. It consists of Token Bucket Rate, Token Bucket Size and Maximum Packet Size. MsgType Description Sent with PHR message

0 Reserved 1 PDR_Reservation_Request PHR_Resource_Request 2 PDR_Refresh_Request PHR_Refresh_Update 3 PDR_Release_Request PHR_Resource_Release 4 PDR_Reservation_Report 5 PDR_Refresh_Report 6 PDR_Release_Report 7 PDR_Request_Info PHR_Resource_Request OR PHR_Refresh_Update OR PHR_Resource_Release 8 PDR_Congestion_Report 9-16 Unused

Figure 3-22: Table of valid message types

The PDR request messages are sent from the ingress towards the egress with the receiver host’s IP address but not forwarded to the next hop beyond the egress node. The PDR report messages are sent in the reverse direction from an egress node to the ingress node. In this situation, the IP address of the ingress node is used as destination address.

36

RMD in IP option based on IPv6 Figure 3-23 shows the PHR message format used in the RMD in IP option based on the IPv6 version.

0 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Option Type | Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P-LEN|P-ID |S|M| C |T| U | Requested Resources | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unused | Delta T | Shared % | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . PDR encapsulated data . . Variable length field used to . . encapsulate PDR messages . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3-23: PHR message format located in IPv6 Hop-by-Hop Options header

Next Header (8-bit selector): This is specified in [RFC2460] and identifies the type of header immediately following the Hop-by-Hop Options header. Hdr Ext Len (8-bit field): This is specified in [RFC2460] and represents the length of the Hop-by-Hop Options header in 8-octet units, not including the first 8 octets. Option Type (8-bit identifier) of the type of option: The semantics of this field are specified in [RFC2460]. Opt Data Len (8-bit field): This is specified in [RFC2460] and represents the length in octets of the Option Data field of this option. The option data field consists of all fields included in the Hop-by-Hop header option and placed after the "Opt Data Len" field. P-LEN (3-bit field): The semantics of this field (PHR length) are identical to the field in the IPv4 option. Just as for IPv4, the value 0 specifies that this IP option field contains only PDR data and no PHR data. The PDR data MUST begin on the next 32-bit word boundary after the P-LEN field (after the first "Requested Resources" field). In this case, the sender MUST set the "S", "M", "C", "unused", and "Requested Resources" fields to 0. The P-ID MUST have the value 1. If a receiver receives a packet with a P-LEN value of 0, it MUST ignore the values in the "S", "M", "C", and "unused" fields. U (3-bit field) that is currently unused. Reserved for future PHR extensions. UNUSED (16-bit field) that is currently unused. Reserved for future PHR extensions. PDR encapsulated: a variable length field that contain PDR Data: encapsulated information data. This field is only processed by the edge nodes. The PDR message can be carried either inside the PHR IP option or somewhere else in the IP packet. Figure 3-24 shows an example of a PDR message format based on the IPv6 version. Note that the only difference between the IPv4 and IPv6 version is the Ingress Address field, i.e., in IPv6 is this 128 bits long, while in IPv4 32 bits long.

37

0 31+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| PDRID |MsgType|S|M|B| Unused |F-Type |EP-Type| PDR-TTL |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Reverse Requested Resources | Shared % |Dropping rate %|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || || Ingress (Egress) Address (IPv6) || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || Flow-ID (length varies) || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || Variable length field || |

Figure 3-24: PDR message structure for IPv6

3.2.2.3.2 Similarities and differences between “RMD in IP Payload” approaches based on IPv4 and IPv6 specifications

In this approach the RMD information is included in an object that has the same format as the RSVPv2 object. This RMD object is located in the IP payload and behind all the RSVPv2 objects. RMD in IP Payload based on IPv4 There are two possibilities of implementing this approach.:

• the PDR and PHR information is encapsulated into one single RSVP object. The format of this object is shown in Figure 3-25, where on top of the RMD specific information the three (standard) RSVPv1 object fields (see Section 3.2.2.2) are used, i.e., Length, Class-Num and C-type. The encapsulated PDR information is identical to the one depicted in

• Figure 3-21. 0 31+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Length(bytes) | Class-Num | C-Type |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| Unused |P-LEN| P-ID |S|M| C |T|Unused|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Requested Resources | Delta T | Shared % |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-. .. PDR encapsulated data .. Variable length field used to .. encapsulate PDR messages .| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Figure 3-25: Combined PHR/PDR Object format

• the PDR and PHR information is encapsulated into two different RSVP objects. The PHR object is depicted in Figure 3-26. The variable length field can be used for future specifications. The format of the PDR object is shown in Figure 3-27. On top of the RMD specific information of the PHR and PDR objects, the three (standard) RSVPv1 object fields (see Section 3.2.2.2) are used, i.e., Length, Class-Num and C-type.

The latter encapsulation type, i.e., separated PHR and PDR objects, is more efficient and more flexible then the first one, i.e., combined PHR/PDR object, due to the fact that future specifications can be easily introduced since both the PHR and PDR objects include a Variable length field.

38

0 31+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Length(bytes) | Class-Num | C-Type |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| Unused |P-LEN| P-ID |S|M| C |T|Unused|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Requested Resources | Delta T | Shared % |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-. ... Variable length field.| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Figure 3-26: PHR Object format

0 31+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Length(bytes) | Class-Num | C-Type |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| PDRID |MsgType|S|M|B| Unused |F-Type |EP-Type| PDR-TTL |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Reverse Requested Resources | Shared % |Dropping rate %|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Ingress (Egress) Address (IPv4) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || Flow-ID (length varies) || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || Variable length field || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3-27: PDR Object format

Below is an example given that shows how an RSVP message and a PHR/PDR message are integrated together. We denote the integrated messages by inserting a “*” after the message name. <RSVP PATH* message> = <Ipv4 header> <Common Header> [<INTEGRITY>] <SESSION> <RSVP_HOP> <TIME_VALUES> [<POLICY_DATA>] [<Sender Descriptor>] <PHR/PDR Object(s)> Design of composing, reading and decomposing of the RMD information When “RMD in IP payload” approach in IPv4 is used then, compared to the RMD in IP option based on IPv4, additional functions have to be implemented (see [Shi02]). The additional functions that have to be designed and implemented are:

• Message composing (MsgCompose) module (see [Shi02]), where the integration of RSVP and RMD information is provided. This function modifies the Total length field of the IP packet that carries the RSVPv2 information by adding the length of the RMD message to it, without updating the RSVP Length field of the Common Header part (see Section 3.2.2.2). Note that this function is implemented within the RSVPv2 ingress daemon of an ingress node or the RSVPv2 egress daemon of an egress node.

• Message reading (Get_PHR_Ipv4) module (see [Shi02]), where only the “Common Header” and RMD information is read, without processing any other RSVPv2 object. This module is mainly using the information included in the Total length field of the IP packet (that is carrying the RSVPv2 message), the IP Header length and the information included in the RSVP length field of the Common Header object of the RSVPv2 message. By subtracting the sum of the IP Header length and RSVP length from the IP Total length, the starting point of the RMD information

39

(within the RSVPv2 message structure) can be found. Note that this function is implemented in all nodes in the PHR functionality available in the Linux kernel space. The message reading module supports an important concept, which is the RSVP objects contained within the RMD/RSVP (RSVPv2) integration message will not be processed in the interior nodes of the RMD domain. The RMD functionality in the interior nodes it is only processing the PHR/PDR information contained in the RMD object(s) contained in any RSVPv2 message.

• Message decomposing (MsgDecompose) module (see [Shi02]), where the RMD information is deleted from the RSVPv2 message such that only RSVP objects are left. This module, similar to Get_PHR_Ipv4, is mainly using the information included in the Total length field of the IP packet (that is carrying the RSVPv2 message), the IP Header length and the information included in the RSVP length field of the Common Header part of the RSVPv2 message. By subtracting the sum of the IP Header length and RSVP length from the IP Total length, the starting point of the RMD information (within the RSVPv2 message structure) can be found. In this way the RMD information is deleted and left with the RSVPv2 information is left over. Note that this function is implemented within either the RSVPv2 ingress daemon of an ingress node or the RSVPv2 egress daemon of an egress node.

The functionality of the ‘RMD in IP payload” approach can be briefly explained as follows. When one RSVP message is generated and arrives at the ingress node of RSVPv2 prototype, the ingress node will first check if it should include the PHR/PDR information into this message. If it is necessary, the ingress node will decide which PHR/PDR message should include. Then the MsgCompose module is called to integrate the RSVPv2 message and RMD messages. The PHR functionality in the ingress node needs to call the Get_PHR_Ipv4 function to retrieve the PHR/PDR information from the packet that was send towards the destination end host. Based on this information, the PHR functionality can perform the resource reservation and the management of the PHR reservation state. Subsequently, this IP packet containing this RMD/RSVP (RSVPv2) integration message is sent through the RMD domain. Interior nodes will also need to call the Get_PHR_Ipv4 function to retrieve the PHR/PDR object information from the packet. The node is then able to perform the PHR resource reservation. When the RMD/RSVP integration message arrives at egress node, the complete RSVPv2 message (that includes the RMD information) will be processed by the RSVPv2 egress daemon and subsequently, the PHR/PDR Object information will be totally removed from the RMD/RSVP integration message by the MsgDecompose module. RMD in IP Payload based on IPv6 Similar to the RMD in IP Payload based on IPv4, there are also two possibilities of implementing this approach.:

• the PDR and PHR information is encapsulated into one single RSVP object. The format of this object is shown in Figure 3-28, where on top of the RMD specific information the three (standard) RSVPv1 object fields (see Section 3.2.2.2) are used, i.e., Length, Class-Num and C-type. The encapsulated PDR information is identical to the one depicted in Figure 3-24. 0 31+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Length(bytes) | Class-Num | C-Type |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| Unused |P-LEN| P-ID |S|M| C |T|Unused|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Requested Resources | Delta T | Shared % |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-. .. PDR encapsulated data .. Variable length field used to .. encapsulate PDR messages .| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Figure 3-28: Combined PHR/PDR Object format

• the PDR and PHR information is encapsulated into two different RSVP object. The PHR object is depicted in Figure 3-29. The variable length field can be used for future specifications. Note that the format of this PHR object is identical to the one depicted in Figure 3-26. The format of

40

the PDR object is shown in Figure 3-30. On top of the RMD specific information of the PHR and PDR objects, the three (standard) RSVPv1 object fields (see Section 3.2.2.2) are used, i.e., Length, Class-Num and C-type.

The latter encapsulation type, i.e., separated PHR and PDR objects, is more efficient and more flexible then the first one, i.e., combined PHR/PDR object, due to the fact that future specifications can be easily introduced since both the PHR and PDR objects include a Variable length field.

0 31+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Length(bytes) | Class-Num | C-Type |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| Unused |P-LEN| P-ID |S|M| C |T|Unused|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Requested Resources | Delta T | Shared % |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-. ... Variable length field.| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Figure 3-29: PHR Object format

0 31+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Length(bytes) | Class-Num | C-Type |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| PDRID |MsgType|S|M|B| Unused |F-Type |EP-Type| PDR-TTL |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Reverse Requested Resources | Shared % |Dropping rate %|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || || Ingress (Egress) Address (IPv6) || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || Flow-ID (length varies) || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || Variable length field || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3-30: PDR Object format

Below is an example given that shows how an RSVP message and a PHR/PDR message are integrated together. We denote the integrated messages by inserting a “*” after the message name. <RSVP PATH* message> = <Ipv6 header> <Common Header> [<INTEGRITY>] <SESSION> <RSVP_HOP> <TIME_VALUES> [<POLICY_DATA>] [<Sender Descriptor>] <PHR/PDR Object(s)> Design of composing, reading and decomposing of the RMD information When the IPv6 version of the “RMD in IP payload” approach is used, compared to the RMD in IPv4 approach, certain modifications have to be introduced. The main differences will be related to the implementations of the main RMD Linux modules and the RSVP/RMD user daemons.

41

In this section we will only emphasize the modifications that will have to be implemented in order to compose, read and decompose the RMD information for the IPv6 version of the “RMD in IP payload” approach (versus the IPv4 version). This is due to the fact that the IPv6 header does not contain the “Total Length” field used in Ipv4, that is the length of whole packet, i.e., the sum of the length of the IPv4 header length and the length of the IPv4 payload, but it is only containing the length of the IPv6 payload, i.e., “Payload length” field. The composing, reading and decomposing functions have to be implemented in the following way:

• Message composing (MsgCompose) module, where the integration of RSVP and RMD information is provided. This function modifies the “Payload length” field of the IPv6 packet that carries the RSVPv2 information by adding the length of the RMD message to it, without updating the RSVP Length field of the Common Header part (see Section 3.2.2.2). Note that this function is implemented within the RSVPv2 ingress daemon of an ingress node or the RSVPv2 egress daemon of an egress node.

• Message reading (Get_PHR_Ipv6) module, where only the “Common Header” and RMD information is read, without processing any other RSVPv2 object. This module is mainly using the information included in the “Payload field” of the IPv6 packet (that is carrying the RSVPv2 message), the IPv6 Header length and the information included in the RSVP length field of the Common Header object of the RSVPv2 message. By subtracting the “RSVP length” of the Common Header part of the RSVP packet from the “Payload length” of the IPv6 message, the starting point of the RMD information (within the RSVPv2 message structure) can be found. Note that this function is implemented in all nodes in the PHR functionality available in the Linux kernel space. The message reading module supports an important concept, which is the RSVP objects contained within the RMD/RSVP (RSVPv2) integration message will not be processed in the interior nodes of the RMD domain. The RMD functionality in the interior nodes it is only processing the PHR/PDR information contained in the RMD object(s) contained in any RSVPv2 message.

• Message decomposing (MsgDecompose) module, where the RMD information is deleted from the RSVPv2 message such that only RSVP objects are left. This module, similar to Get_PHR_Ipv6, is mainly using the information included in the “Payload length” field of the IPv6 packet (that is carrying the RSVPv2 message), and the information included in the “RSVP length” field of the Common Header part of the RSVPv2 message. By subtracting the sum of the IP Header length and RSVP length from the IP Payload length, the starting point of the RMD information (within the RSVPv2 message structure) can be found. In this way the RMD information is deleted and the RSVPv2 information is left over. Note that this function is implemented within either the RSVPv2 ingress daemon of an ingress node or the RSVPv2 egress daemon of an egress node.

Selected solution The “RMD in IP payload” approach, compared to the “RMD in IP option” approach has certain advantages. One main advantage of this approach is that the size of the RMD information does not have strict limitations. Another advantage is that its design is independent of the used IP version. The main disadvantage is related to the delay that is imposed to an interior node when reading the RMD information from the RSVP message. However, as shown above, certain optimizations are possible where not all the RSVP objects have to be read, but only the RMD information. Therefore, the “RMD in IP payload” approach is chosen in the design of the RSVPv2 protocol.

3.2.3 RSVPv2 protocol components This section describes the protocol components that are used in the design of the RSVPv2 protocol. The following sections describe the protocol components used in an ingress, interior and egress node separately, but a single node should be able to support all three functions at the same time. Also the structure in which the components are placed should be the same for both IPv4 and IPv6. The design consists of two parts: the control plane and the data plane.

42

3.2.3.1 Ingress node This section describes the RSVPV2 protocol components (see Figure 3-31) used in an ingress node. The ingress node has to support per flow reservations for RSVP (Intserv) and per DSCP reservations for RMD (PHR functionality based on Diffserv).

RMD/RSVP Daemon (ingress)

RSVP filter/ Policing

Tc_index filter

Packet scheduler

PHR filter

data

RSVP signaling

RSVP/RMD signaling

data

Figure 3-31: RSVPv2 protocol components in an ingress node

The following components are used in the ingress:

• RMD/RSVP (or RSVPv2) Daemon: intercepts RSVP packets arriving from outside of the RMD domain and RSVP packets containing RMD objects from within the RMD domain. The packets from outside the RMD domain contain the router alert option. As this is a RSVP daemon, it should follow the message processing rules from [RFC2209]. When a RSVP PATH arrives it should keep a RSVP state in a Path State Block (PSB) that includes information from the SESSION and SENDER_TEMPLATE objects (see Section 3.2.2.2), like the previous hop address, remaining TTL and sender traffic specification. Then it has to send a RSVP Path message with RMD objects. This message should not contain the router alert option, because interior nodes should not try to find an RSVP daemon to handle the message. When a RSVP RESV message returns from the egress node, the daemon has to store the flow information in a Reservation State Block (RSB). The information to be kept in the RSB includes the next hop address, session-, filter- and flow specification. A RSVP filter should be installed and data packets should be policed. A RESV message, with router alert on, has to be sent to the previous hop. Now arriving data packets will get the requested Quality of Service. When a RSVP PATHtear messages arrives from the previous hop a RSVP PATHtear message with RMD objects is sent towards the egress node to remove the reservation from the RMD domain. The PSB and RSB have to be removed and the RSVP filter is uninstalled. It is also possible the destination wants to remove the reservation. A RSVP RESVtear arrives from the next hop (the egress node). In this case the PSB has to be kept and only the RSB has to be removed and the RSVP filter uninstalled.

• RSVP(v2) filter/policing: filters packets based on characteristics that uniquely describe a RSVP flow: source address, source port, destination address, destination port and protocol (TCP/UDP). The policing is accomplished using a token bucket filter.

The ingress node can operate as an interior node on all internal interfaces (network interfaces inside the domain). The components used for this functionality, Tc_index filter, PHR filter and Packet scheduler, are described in Section 3.2.3.2.

43

3.2.3.2 Interior node This section describes the RSVPV2 protocol components (see Figure 3-32) used in an interior node. The interior node has to support per DSCP reservations for RMD (PHR functionality based on Diffserv).

Tc_index filter

Packet scheduler

PHR filter

data

RSVP/RMD signaling

RSVP/RMD signaling

data

Figure 3-32: RSVPv2 protocol components in an interior node

The following protocol components are used in the interior node: • Tc_index filter: is used in combination with the dsmark queuing discipline (See [Alme01]). The

dsmark qdisc is used to get and set the DSCP field in an IP packet. The tc_index filter selects the appropriate traffic classes based on the DSCP value.

• PHR filter: is dependent on the chosen PHR protocol. In the case of RODA the number of reserved units is managed here. Severe congestion is detected and signaled to the egress node. When a reservation fails, when not enough resources are available, the IP TTL value of the packet is signaled to the edges, which is used during the partial release procedure.

• Packet scheduler: manages the de-queuing of packets sent out through the network interface. It selects the class that is allowed to send the next packet based on its priority. Several classes and queuing disciplines with different properties can be connected together to get precise control over the priorities that are assigned to the different packets. Some possibilities (see [tc-man] and [tc-howto]) are:

o PRIO (priority queuing) is a simple classful queuing discipline that can contain a number of classes of differing priority. The classes are de-queued in descending order of priority.

o CBQ (Class Based Queueing) is a classful queuing discipline that can be used to implement a hierarchy of classes of different priorities. Each class is assigned a given amount of bandwidth. It is also possible to let classes borrow bandwidth from each other.

o FIFO (First In First Out) is a simple queue that inserts packets at the tail of a list when they are en-queued. A de-queued packet is taken from the head of the list and when the list is full packets are dropped. This can be used for EF traffic.

o RED (Random Early Detection): is a classless queuing discipline that starts to drop packets with a configurable probability when the queue reaches a certain average length. The probability increases as the queue grows bigger. This can be used to implement AF (Assured Forwarding) traffic.

44

3.2.3.3 Egress node This section describes the RSVPV2-IPv6 protocol components (see Figure 3-33) used in an egress node. The egress node has to support per flow reservations for RSVP (Intserv) and per DSCP reservations for RMD (PHR functionality based on Diffserv).

RMD/RSVP Daemon (egress)

RSVP filter

Tc_index filter

Packet scheduler

data

RSVP/RMD signaling

RSVP signaling

data

Figure 3-33: RSVPv2 protocol components in an egress node

The following components are used in the egress: • RMD/RSVP (or RSVPv2) Daemon: intercepts RSVP packets arriving from outside of the

RMD domain and RSVP packets containing the RMD objects from inside the RMD domain. The packets from outside the domain contain the router alert option. As this is a RSVP daemon, it should follow the message processing rules from [RFC2209]. When a RSVP PATH, including RMD objects, arrives the RMD/RSVP daemon should keep a RSVP state in a Path State Block (PSB) that includes information from the SESSION and SENDER_TEMPLATE objects (see Section 3.2.2.2), like the previous hop address, remaining TTL and sender traffic specification. When packets are marked a release has to be send to the ingress node. Otherwise it has to send a RSVP Path message without RMD objects towards the end host (outside the RMD domain). This message should contain the router alert option. When a RSVP RESV message returns from the next hop, the daemon has to store the flow information in a Reservation State Block (RSB). The information to be kept in the RSB includes the next hop address, session-, filter- and flow specification. A RSVP filter should be installed. A RESV message, containing the RMD objects, has to be sent to the ingress node (previous hop). When a RSVP PATHtear messages containing RMD objects arrives from the previous hop (ingress node) the reservation is removed from the RMD domain and a RSVP PATHtear message is sent towards the next hop. The PSB and RSB have to be removed and the RSVP filter is uninstalled. It is also possible the destination wants to remove the reservation. In that case a RSVP RESVtear arrives from the next hop and only the RSB has to be removed and the RSVP filter uninstalled. The information in the PSB has to be kept.

The descriptions of the Tc_index filter and the Packet scheduler protocol components are given in Section 3.2.3.2. The RSVP(v2) filter operates similar to the one described in section 3.2.3.1 except of the policing part, which is not necessary in the egress node.

45

4 Prototype Implementation This chapter describes the prototype implementations of the enhanced RMD versions. In section 4.1 the traffic control available in the linux implementation environment is described. Section 4.2 gives a description of the bi-directional prototype implementation. An existing RMD implementation (see [Jaco01]) is used and where needed modified. Section 4.3 gives a description of the RMD and RSVP protocol integration protocol implementations based on the IPv4 and IPv6 specifications. However, more focus has been given to the IPv6 version of this implementation. The RMD and RSVP protocol integration is denoted in this thesis as RSVPv2, while the RMD and RSVP protocol integration that is based on the IPv6 specification is denoted in this thesis as RSVPv2-IPv6. Due to time constraints, the bi-directional and the severe congestion with proportional marking features (see Chapter 2 and Chapter 3) are not implemented into the RSVPv2 prototype, but the PHR marking feature is.

4.1 Linux implementation environment Linux is a UNIX-like open source operating system that supports a number of advanced networking features that are based on IPv4 and IPv6 specifications. Furthermore, good developing tools are available, like compilers, editors, debugger, etc.,. The kernel of the Linux operating system has extensive support for Quality of Service networking, including a flexible framework for packet classification and scheduling, (see [Alme01], [Radh99]) as well as Intserv and Diffserv features. Furthermore, the original version of RMD [Jaco01], [JaOo02] is implemented in Linux. For these reasons, Linux is a good candidate for prototyping network protocols, such as the RSVPv2-IPv6 protocol. The Linux kernel is implemented in a stepwise manner in several implementation series. Compared to previous Linux kernel implementation series, e.g., Linux kernel 2.2, the current Linux kernel implementation serie, i.e., Linux kernel 2.4, has experienced main modifications with respect to traffic control and the firewalling code (netfilter) (see e.g., [Linux]).

4.1.1 Traffic control The Linux kernel offers several traffic control features. It provides support for the Integrated Services (Intserv) as well as the Differentiated Services (Diffserv) QoS architectures. See [Alme01] for an implementation overview. Figure 4-1 shows how the traffic control (that is a part of the Linux kernel) processes the data traffic that is received from the network.

Figure 4-1: Processing of network data

After a data packet arrives on an input buffer, it can be policed. This means that non-conformant data traffic, e.g. data traffic that is arriving too fast, can be discarded. Then packets can be either passed up to higher layers in the protocol stack (e.g., when the device that processes the traffic is an end host) or forwarded through the network (e.g., when the device that processes the data traffic is a router). The upper layers can also send data to the lower layers. This data is then forwarded through the network. Forwarding includes selection of the output buffer, selection of the next hop, encapsulation, etc. Then packets are queued on the respective output buffer. This part of traffic control can decide whether packets are queued or dropped (e.g. if the queue has reached some length limit, traffic exceeds a rate limit). Certain flows can be given higher priority. Packets that are associated to these flows can be processed earlier than packets that are associated to flows with a lower priority. After the traffic control releases the packet, the device driver picks it up and sends it through the network.

46

There are several queuing disciplines (qdisc’s) available in the Linux kernel that specify how packets are treated. In a qdisc there can be filters to select between different classes of packets. However, a class can also uses a separate qdisc to store packets. In Figure 4-2 there is a qdisc with three filters, which separates (filters) the data traffic into two classes. One class can be given priority over the other class. The two classes can also use different and separate qdisc’s. If a data packet does not match any of the filters, it can be attributed to a default class.

Figure 4-2: Queuing discipline with multiple classes

Some important queuing disciplines are: CBQ Class Based Queuing is a qdisc that implements a rich link sharing hierarchy of classes.

It contains shaping elements as well as prioritizing capabilities. Shaping is performed using link idle time calculations based on the timing of dequeue events and underlying link bandwidth.

DSMARK The DSCP marker/remarker changes the DSCP of a packet according to specified rules. FIFO simple first-in-first-out (packet (p-FIFO) or byte (b-FIFO)). p-FIFO is the standard

queuing discipline in Linux. Up to some maximum of packets (or bytes) are stored and then forwarded.

RED random early detection discards packets even when there is space in the queue. As the queue length increases, the drop probability also increases. This can be used for congestion avoidance.

SFQ stochastic fairness queuing does not shape traffic but only schedules the transmission of packets, based on 'flows'. The goal is to ensure fairness so that each flow is able to send data in turn, thus preventing any single flow from drowning out the rest.

TBF token bucket filter is a pure shaper and never schedules traffic. It may throttle itself, although packets are available, to ensure that the configured rate is not exceeded.

There is a user space program (i.e., program located out of the Linux kernel), called tc, that is used in combination with the traffic control part (implemented in the kernel). It is used to perform additional features that are associated with some parts of the header and/or payload information carried by a data packet. See [tc-man] for a user manual of the tc program and several qdisc’s. The tc program uses the rtnetlink interface to interact with the kernel. Rtnetlink is a binary interface between the kernel and a user space program (See [Linux]). It is actually an extension of the netlink socket (see e.g., [DhSu99]).

47

4.2 Bi-directional prototype implementation The original RMD prototype implementation (see [Jaco01], [JaOo02]) does not include the implementation of the bi-directional feature. This feature is necessary when RMD has to be used as a resource reservation protocol in the IP-based UTRAN (see Section 1.1). The bi-directional implementation was accomplished by extending the original RMD prototype implementation presented in [Jaco01] and [JaOo02]. The goal of this prototype implementation is to show that the implementation of the bi-directional feature is feasible. The implemented functionality blocks that are not affected by the bi-directional functionality remain exactly the same. For example, the Simple External Protocol (SEP) is still used without modifications. However, SEP does not support bi-directional reservations, and therefore in this implementation it was chosen to always interpret a SEP reservation as bi-directional one. Figure 4-3 shows the communication paths for both the forward and reverse flows in the network, in the case of bi-directional reservations. The forward and reverse flows have to pass through the same ingress and egress nodes, but not necessarily through the same interfaces on those nodes. This is required, because a reverse reservation request that is received by the ingress node it also contains the PDR reservation report for the forward flow. The forward and reverse flows do not have to pass through the same interior nodes. This is because the routing protocol defines the forward and reverse paths and different interior nodes might be located in the forward and reverse paths.

source

Ingress/Egress Edge1

Ingress/Egress Edge1

interior

interior

destination

Egress/Ingress Edge2

Egress/Ingress Edge2

forward path reverse path

interior

Figure 4-3: Bi-directional communication paths

48

4.2.1 Signaling messages As the bi-directional implementation prototype of the RMD protocol is based on the original RMD implementation, it is considered that an egress and an ingress daemon are running on every edge node. The format of the PHR and PDR messages is given in [WeJa03b]. Note that it is assumed that the reservation for the forward direction travels from edge1 to edge2 and for the reverse direction from edge2 to edge1. All possible message that can be received or sent by the different ingress and egress daemons and kernel modules on the edges and the interior nodes are listed in Table 4-1. This table shows whether the RMD processing or forwarding of a message is needed. Another possibility shown in the table is the need for inter-process communication between egress and ingress daemons on the same edge node. Section 4.2.6 gives a more detailed description of the processing of these messages in the ingress and egress daemons and kernel modules.

Messages Edge1_Ingress Edge1_Egress interior Edge2_Ingress Edge2_Egress2 Rec. Send Rec. Send Rec. Send Rec. Send Rec. Send SEP reserve X X - - SEP release X X - - PHR_Res_Req(forward) (PDR_Res_Req(bi-forward))

X X X * X *

PHR_Res_Req(forward-M) (PDR_Res_Req(bi-forward)

X X * X *

PHR_Res_Req(reverse) (PDR_Res_Req(reverse)

* X * X X X

PHR_Res_Req(reverse-M) (PDR_Res_Req(reverse)

* X * X X

PHR_Ref_Upd(forward) (PDR_Ref_Upd(bi-forward))

X X X X

PHR_Ref_Upd(reverse) (PDR_Ref_Upd(reverse))

X X X X

PHR_Rel_Req(forward) (PDR_Rel_Req(bi-forward)

X X X * X *

PHR_Rel_Req(reverse) (PDR_Rel_Req(reverse)

* X * X X X

PDR_Reservation_Report (bi-forward-M)

X X

X = Process message - = Forward message * = Send to ingress/ receive from egress

Table 4-1: Signaling messages for bi-directional reservations

4.2.2 Implementation overview An overview of the queuing structures and their location is given in Figure 4-4. Edge1 is the node that processes the data traffic that enters the RMD domain and it is associated with the forward flow. Edge2 is the node that processes the data traffic that outgoes the RMD domain and it is associated with the forward flow. Note that an edge node has to support both ingress and egress functionality (see Chapter 3). The ingress/PHR functionality is located on the output buffer towards the RMD domain. The egress/PHR functionality is located on the output buffer leading out the RMD domain. All functionality is located at the output buffers and the interface configuration has been completely mirrored for edge1 and edge2. For the interior node there are no changes compared to the original RMD implementation described in [Jaco01]. The PHR functionality is located in the output buffers of all interfaces in the RMD domain. Mostly the same queuing disciplines as in the original RMD implementation are being used. See Section 4.2.3 for a description of the ingress node, Section 4.2.4 for the interior node and Section 4.2.5 for the egress node. Note that the description of the RMD user daemons, i.e., user space programs, is given in the same sections.

49

PHR

/egr

ess

PHR

/egr

ess

Ingr

ess/

PHR

PH

RIn

gres

s/PH

Rda

tada

ta

Edg

e1E

dge2

Inte

rior

PH

R

Ingr

ess

Dae

mon

prev

ious

hop

next

hop

to

egre

ssfr

omin

gres

sE

gres

sD

aem

on

sign

alsi

gnal

user

spac

e

kern

el s

pace

ingr

ess

qdis

c+

SE

P f

ilter

egre

ss q

disc

+ S

EP

filte

r

PH

Rqd

isc

stan

dard

inte

rfac

e

Ingr

ess

Dae

mon

Egr

ess

Dae

mon

to egre

ssfr

omin

gres

s

PHR

/egr

ess

PHR

/egr

ess

Ingr

ess/

PHR

PH

RIn

gres

s/PH

Rda

tada

ta

Edg

e1E

dge2

Inte

rior

PH

R

Ingr

ess

Dae

mon

prev

ious

hop

next

hop

to

egre

ssfr

omin

gres

sE

gres

sD

aem

on

sign

alsi

gnal

user

spac

e

kern

el s

pace

ingr

ess

qdis

c+

SE

P f

ilter

egre

ss q

disc

+ S

EP

filte

r

PH

Rqd

isc

stan

dard

inte

rfac

e

Ingr

ess

Dae

mon

Egr

ess

Dae

mon

to egre

ssfr

omin

gres

s

Figure 4-4: Implementation overview

4.2.3 Ingress functionality The ingress functionality of an edge node does scheduling and policing per flow, while the PHR functionality and the Diffserv packet scheduling is done per Diffserv class. Figure 4-5 shows the traffic control inside the linux kernel and the communication with the daemons. Components The kernel space part consists of existing kernel modules executed inside the Linux kernel and kernel modules written for RMD [Jaco01]. Section 3.1.3.1 describes the components that are used in this prototype implementation. The following two components are not described in Section 3.1.3.1, but they are used in the bi-directional prototype implementation. Note that these two components were also used in the original RMD implementation (see Figure 4-5):

- Pipe Queuing Discipline: provides a direct connection between two queuing disciplines after each other.

- Device Filter: filters packets based on the interface they arrive on. An ingress node uses it to differentiate between packets entering or leaving the RMD domain.

50

Signaling packets in forward direction The RMD ingress daemon located in Edge1 listens for SEP signaling packets containing the IP router alert option [RFC2113]. The amount of resources for both the forward and reverse directions is calculated from the parameters included in the SEP message. Note that the SEP message contains the reservation request only for one direction. To show that the RMD protocol can operate when the reservation request for forward and reverse directions is different it is considered that the reverse direction reserves half the resources that are reserved by the forward direction. When a new flow in the forward direction can be admitted, the ingress daemon creates a PDRingress queue and a TBF for that specific flow. The parameters given to the PDRingress queue include the number of resource of the reverse direction. The communication between user space and kernel space is done using the rtnetlink interface (See section 4.1.1). The PDRingress queuing discipline sends a message towards the destination, containing PHR and PDR messages to request resources in the RMD domain. The PDR report that is contained in the PHR request for the reverse direction arrives at the egress daemon at Edge1. The ingress daemon at the same node is notified by using a socket connection for inter process communication and the SEP filter is set to enqueue packets from the new flow to the corresponding PDRingress queue. The source and destination can start sending data traffic in the forward and reverse direction that will get the requested Quality of Service. Signaling packets in reverse direction The functionality of the ingress daemon and the PDRingress queuing discipline is different for forward and reverse directions. Therefore, the differences will be described separately. A bi-directional reservation in the forward direction is handled at Edge2 by the egress functionality. The Edge2 egress daemon forwards the information needed for the reverse reservation to the Edge2 ingress functionality using a socket connection. The Edge2 ingress functionality handles the reservation request in the same manner as when a SEP message arrives. The main differences are that the reverse request is not considered as bi-directional request and a PDR reservation report has to be included in the message to signal the ingress daemon at Edge1 that the reservation was successful. Furthermore, a SEP filter has to be added that puts data packets for the reverse direction in the correct DSCP. Data packets For data packets the functionality behavior for the forward and reverse directions is the same. Therefore, this does not need to be described separately. Arriving data packets from outside the domain will enter the queuing structure at the left side of Figure 4-5. The description is identical for both the forward and reverse directions. If the device filter intercepts packets that are arriving from inside the domain, only the PHR functionality is needed and the ingress functionality is not used. When packets are arriving from outside the domain, the SEP filter classifies them and they are enqueued on a PDRingress queue if they belong to a reserved flow. If there is no matching flow, they are classified as best effort traffic. The PDRingress queues perform policing on the traffic by using a token bucket filter (TBF). After marking the data packets in the correct DiffServ Code Point (DSCP), the packets are sent on to the right part of Figure 4-5 that contains the interior functionality. This is described in Section 4.2.4.

51

FIFO device

TBF

pdringress

SEP

filter on

flowid TBF

pdringress

FIFO

CBQ

ingress functionality

SEP functionality PDR functionality

Unreserved Traffic

Ingress daemon

SEP Reserve SEP Release

SEP Response SEP Tear Down flow

PHR FIFO

FIFO traffic

PRIO

PHR FIFO

GRED traffic

PRIO

FIFO Best Effort

CBQ

PIPE

interior functionality

PHR functionality PHB implementation

Kernel space

User space

dsmark

TCINDEX EF

TCINDEX AF1x

EF.local.PHR TCINDEX

TCINDEX EF.local

TCINDEX AF1x.local TCINDEX

AF1x.local.PHR

Egress daemon

PDR_Reservation Report

Figure 4-5: Ingress functionality

The ingress daemon is informed about marked reports and timeouts by the PDRingress queuing discipline. The ingress daemon can react by tearing down the flow and notifying the sender with a SEP Tear Down Flow packet or a SEP Reservation Rejected packet when a request for a new flow was rejected. The SEP filter and PDRingress queuing disciplines are removed, so the data traffic will be placed in the best effort queue. The only classes used in the implementation where the best effort class and the EF (Expedited Forwarding) class, which where configured to use a fixed amount of bandwidth.

4.2.4 Interior node A representation of the traffic control in an interior node is given in Figure 4-6. The interior functionality is also present in the ingress node as described in Section 4.2.3. In the original RMD implementation the queuing structures used in the interior node where exactly the same as the queuing structures used for the interior functionality used in an ingress node. The device filter is used bypass the ingress functionality if the packets where already inside the domain. Effectively the behavior is the same as if only the interior functionality was implemented. A disadvantage of using the device filter component is that there is some processing involved in determining if a packet has to go through the ingress functionality or not. In order to minimize design errors and minimize the required implementation time, the design of the interior functionality used in the original RMD implementation has been also kept for the bi-directional implementation. The interior node is not aware of bi-directional reservations. These reservations are seen as two uni-directional reservations. The only difference is that the interior functionality must now be present on both interfaces, instead of only the outgoing interface for the forward communication path. The interior node operates similarly to a standard Diffserv node that performs packet scheduling for every DSCP. As can be seen in Figure 4-6 a PHR filter is added to make it possible to dynamically modify the resource allocated to each DSCP using the RODA PHR protocol. First packets are classified and put in the correct traffic class (EF or AF) according to the DSCP value. The PHR filter separates signaling packets from data packets. Data packets are put in a queue that has the properties of the corresponding traffic class. E.g. a FIFO queue for EF traffic and a GRED queue for AF traffic. The signaling packets get a higher priority than the data packets and are used to update the PHR reservation state. The sliding window algorithm (See [Jaco01]) is used to maintain the reservation state in a traffic class and mark packets when needed. If a refresh is not received in time, the reservation has to be released.

52

PHR FIFO

FIFO traffic

PRIO

PHR FIFO

GRED traffic

PRIO

FIFO Best Effort

CBQ



dsmark

Kernel space

User space

TCINDEX EF

TCINDEX AF1x


TCINDEX EF.local


AF1x.local.PHR

Figure 4-6: Interior functionality

4.2.5 Egress functionality The egress functionality provides PHR functionality as well as per-flow functionality. The queuing structure is given in Figure 4-7. For a description of the used components see Section 3.1.3.3. The left part of Figure 4-7 contains the PHR functionality, which is identical to the functionality used in the interior node. The right part contains the egress functionality and the two parts are connected using the pipe queuing discipline just like in the ingress queuing structure. The SEP filter classifies packets just like in the ingress node, but here no policing is necessary as the external protocol used is SEP. When there are no reservations yet, there is only a PHRegress queue containing a FIFO buffer. Note that a FIFO buffer is used, although this really should depend on the external protocol used. All traffic without reservations passes this queue and will get a best effort priority. Signaling packets in forward direction When an unmarked PHR resource request arrives at the PHRegress queue, the egress daemon located at Edge2 will be notified. This daemon then does admission control and, when successful, it adds a PDRegress queue containing a FIFO buffer for that flow. After updating the SEP filter, all PHR and PDR messages and all data traffic belonging to that flow are sent through this PDRegress queue. PDR and PHR messages are not send on towards the destination, but discarded. On a successful forward reservation the egress daemon sends the information needed to set up the reverse flow to the ingress daemon located in the same node (Edge2) using a socket connection. No PDR report is send back to Edge1, because the ingress daemon at Edge2 takes care of that (see Section 4.2.3). In the case of a uni-directional reservation this queue sends a notification to the egress daemon. As bi-directional reservations that have a marked packet on the forward flow are treated just like uni-directional messages, for this case also the egress daemon is notified. The egress daemon (located at Edge2) then sends back a PDR report message to the ingress daemon (located at Edge1). When a flow is released or times out, this queue and FIFO buffer are removed from the queuing structure and the SEP filter is updated. The egress functionality does not need to generate SEP messages, as they are forwarded through the domain separate from the PHR messages.

53

Signaling packets in reverse direction The processing of the reservation for the reverse direction by the egress functionality at Edge1 is almost the same as for the forward direction. As reverse reservations do not have the bi-directional flag set, they are handled as uni-directional reservations by the queuing structure. Because a PDR Report message is encapsulated in the PHR message, the egress daemon deduces that it is the reverse part of a bi-directional reservation. The egress daemon at Edge1 uses the same socket connection to get the PDR Report message to the ingress daemon also running at Edge1. Data packets After the SEP filter has been set up for a flow, the data packets associated with that flow are sent through the correct PDRegress queuing structure and FIFO buffer. The DSCP value is set back to zero and the packets outgo the RMD domain.

SEP functionality PDR functionality


PIPE

PHR FIFO

FIFO traffic

PRIO

PHR FIFO

GRED traffic

PRIO

FIFO Best Effort

CBQ


FIFO

pdregresss

SEP

filter on flowid

FIFO

pdregresss

FIFOO

CBQ

phregresss

Best effort plus new PHR messages

FIFO SEP?

PRIO

Kernel space

User space

PDR_Reservation Report PDR_Refresh_Report PDR_Congestion_Report

SEP Request to next hop

dsmark

TCINDEX EF

TCINDEX AF1x


TCINDEX EF.local


AF1x.local.PHR

Egress daemon

Ingress daemon

egress functionality

PDR_Reservatioin Report

Figure 4-7: Egress functionality

54

4.2.6 Signaling message processing This section describes the processing of the signaling messages that are used in the bi-directional prototype implementation as described in Section 4.2.1. Message processing is done partly in the ingress and egress daemons and partly in the kernel modules. The SEP messages are intercepted using the router alert option in the IP packet. Message sent inside the RMD domain have the DSCP value set according to the reservation request. Uni-directional reservations are still supported and processed the same as in the original RMD implementation (see [Jaco01]). Therefore, only the processing of bi-directional messages is described. Every edge node consists of ingress and egress functionality. Note that it is assumed that the reservation for the forward direction travels from edge1 to edge2 and for the reverse direction from edge2 to edge1. Due to the time constraints the bi-directional functionality required to handle bi-directional refresh messages is not implemented. This would require complex modification of the kernel modules. However, a similar implementation to the bi-directional reservation request implementation is required. In this prototype implementation it is assumed that the bi-directional refresh procedure consists of two uni-directional refresh procedures. One uni-directional refresh procedure that operates in the forward direction and the other one that operates in the reverse direction. Edge1 ingress functionality when a SEP reserve arrives When a SEP reserve message arrives at the Edge1 ingress functionality from outside the RMD domain it is intercepted by the ingress daemon by using the router alert option in the IP packet. The mapping of SEP reservation parameters to PHR units and a DSCP class is done for both directions. A PDRingress queuing discipline is installed that sends a PHR_Res_Req(forward) with an encapsulated PDR_Res_Req(bi-forward) message towards the destination end host. The PDR message has the “B” bit set and also carries the requested resources for the reverse direction. Edge1 ingress functionality when a SEP release arrives When a SEP release message arrives at the Edge1 ingress functionality from outside the RMD domain it is intercepted by the ingress daemon by using the router alert option in the IP packet. The ingress daemon tries to match the SEP message with a previous reservation. If a match is not found the message is discarded. If the flow ID, represented by the source IP address, source port and protocol type is the same as for an existing flow, the PDRingress queuing discipline and the SEP filter for this flow are removed and a PHR_Rel_Req(forward) with a PDR_Rel_Req(bi-forward) message encapsulated is sent towards the destination end host. The PDR message has the “B” bit set and also carries the resources to be released for the reverse direction. Edge1 ingress functionality when a PHR_Res_Req(reverse) arrives The needed information is forwarded by the egress daemon that is running on the same node that received this message. When a PHR_Res_Req(reverse) message arrives, the “M” bit signals whether the reservation was successful in the entire domain and in both directions. If the “M” bit is not set the SEP filter is installed. Otherwise the partial release procedure is started by sending a PHR_Rel_Req(forward) with the TTL field in the IP header set with the value from the PDR_TTL value of the PDR message. Edge1 ingress functionality when a PHR_Rel_Req(reverse) arrives The needed information is forwarded by the egress daemon that is running on the same node that received this message. The flow state is removed from the egress daemon and the SEP filter and PDRingress queuing discipline are uninstalled. Edge1 ingress functionality when a PDR_Reservation_Report(bi-forward-M) arrives This message is received from the egress functionality running on Edge2. It signals that the forward reservation was unsuccessful and therefore a partial release is performed with the TTL field in the IP header set with the value from the PDR_TTL value of the PDR message. Also the PDRingress queuing discipline and the state for the flow are removed.

55

Edge2 ingress functionality when a PHR_Res_Req(forward) arrives The needed information is forwarded by the egress daemon that is running on the same node that received this message. If the “M” bit is not set, a PHR_Res_Req(reverse) with an encapsulated PDR_Res_Req(reverse) is sent. The PDR message does not have the “B” bit set and no PDR_Reservation_Report message is sent. The ingress address in the PDR message is the address of the ingress at Edge1 and is copied from the forward message. The number of reserved units in the PHR message is copied from the Reverse_resources field in the PDR message. If the ”M” bit is set, a partial release procedure is started. The TTL field in the IP header is set with the value from the PDR_TTL value of the PDR message. Also the PDRingress queuing discipline and the state for the flow are removed. Edge2 ingress functionality when a PHR_Rel_Req(forward) arrives The needed information is forwarded by the egress daemon running on the same node that received this message. A PHR_Rel_Req(reverse) is sent towards the source IP address and the SEP filter, PDRingress queuing discipline and flow state are removed. The TTL value of the IP packet has to be set to the value as received in the PDR message to enable the partial release procedure. Interior node functionality when a PHR message arrives The interior node does not have to do any special processing with respect to the bi-directional feature. In other words, it has to do normal admission control by using the sliding window algorithm located into the PHR queuing discipline. When a message is marked, i.e., the “M” bit is set, no processing should take place and the message will just be forwarded towards the destination IP address of the IP packet. Edge1 egress functionality when a PHR_Res_Req(reverse) arrives When the Edge1 egress functionality receives this message, a check is performed for the “M” bit. If the message was not marked the state for the reverse flow is stored in the Edge1 egress daemon and a SEP filter is installed to separate data packets by flow and set the DSCP value back to zero. If the message was marked the message must be handled as a bi-directional reservation, so both forward and reverse reservations in all nodes can be partially released as needed. Then the ingress daemon running on the same node is notified of the result of the reservation, such that it can terminate the reservation or perform the partial release. Edge1 egress functionality when a PHR_Rel_Req(reverse) arrives When the Edge1 egress functionality receives a PHR_Rel_Req(reverse) message, the SEP filter and the state associated with that flow are removed. The ingress daemon running on the same node is notified that the reservation in the entire domain has been released. Edge2 egress functionality when a PHR_Res_Req(forward) arrives When a PHR_Res_Req(forward) message arrives at the Edge2 egress functionality, a check is performed for the “M” and “B” bits. If the “B” bit is not set, this is a uni-directional reservation for which the normal processing rules as in the first implementation are used. If the “B” is set, the “M” bit signals whether the reservation was successful in the forward path. If the message was marked, it is processed as a uni-directional message, assuming that only reservations for one direction exist. A PDR_Reservation_Report is sent back to Edge1. If the message was not marked a SEP filter is installed that separates the data packets by flow and sets the DSCP value back to zero. The information needed for the reverse reservation is copied into the ingress daemon running on the same node. Edge2 egress functionality when a PHR_Rel_Req(forward) arrives When a PHR_Rel_Req(forward) message arrives at the Edge2 egress functionality, the ingress daemon running at the same node is notified with the needed information. This includes the TTL value of the original message that can be used during a partial release procedure. Further the SEP filter, PDRegress queuing discipline and the state, associated with the respective flow, are removed.

56

4.3 RSVPv2 prototype implementation Existing designs and implementations of the RMD and RSVP protocols have been studied, such as the original RMD implementation [Jaco01], the ISI RSVP implementation [ISI-RSVP] and the design steps of the RSVP and RMD integration that focuses on the IPv4 specification [Shi02]. Both IPv4 and IPv6 versions of the RMD and RSVP protocol integration are implemented using the Linux operating system, the Python and the C and C++ programming languages. However more focus has been given to the IPv6 version of this implementation. The RMD and RSVP protocol integration is denoted in this thesis as RSVPv2, while the RMD and RSVP protocol integration that is based on the IPv6 specification is denoted in this thesis as RSVPv2-IPv6. The RSVPv2 prototype implementation (see Figure 4-10) uses the same setup for every external interface (outside the RMD domain). Also every internal interface (inside the RMD domain) uses identical queues. Every edge node has at least one external and one internal interface. Every interior node has at least two internal interfaces. RSVPv1 messages from the Intserv domain and RSVPv2 messages from the Diffserv domain need to be intercepted in the kernel for processing by the user space RSVPv2 daemon. A main difference between RSVPv1 and RSVPv2 is that the RSVPv2 protocol is sender initiated instead of the receiver initiated RSVPv1.

4.3.1 Signaling messages All RSVPv1 messages that are sent by the daemons should be rebuild from the information in the PSB and RSB instead of just being forwarded. This is to avoid message synchronization as every node can send messages at its own random time as is specified in [RFC2209]. Note that every edge node can be an ingress and an egress node at the same time. Therefore all messages mentioned here have to be supported in every edge node. The format of the PHR and PDR messages is given in Section 3.2.2. In Section 4.3.9 a more detailed description is given of the processing of these messages in the RSVPv2 daemon and kernel modules. Messages tailed by a * contain the PHR/PDR information, the other messages are standard RSVPv1 messages. Note that the messages explained and denoted in the following text as RSVP can be interpreted as RSVPv2 (RSVP-RMD) messages. Moreover, the messages that are processed outside the RMD domain can be interpreted as RSVPv1 messages. Ingress node There are several signaling messages that can arrive in the Ingress Node. Note that the messages that arrive from outside the RMD domain do not contain any PHR/PDR information. These are:

- RSVP PATH - RSVP PATHtear - RSVP RESVconf - RSVP RESVerror

From inside the RMD domain the following message that may carry PHR/PDR information can arrive in the Ingress Node:

- RSVP PATHerror* carrying (PDR_Reservation_Report(marked)) or PDR_Congestion_Report) - RSVP RESV* carrying (PDR_Reservation_Report) or PDR_Refresh_Report) - RSVP RESVtear

The ingress node can send out the following signaling messages, which do not carry any PHR/PDR information to outside the RMD domain:

- RSVP RESV - RSVP PATHerror - RSVP RESVtear

The messages that can be sent into the RMD domain by the ingress node are:

- RSVP PATH* carrying (PHR_Resource_Request(PDR_Request_Info)) - RSVP PATH* carrying (PHR_Refresh_Update(PDR_Request_Info)) - RSVP PATHtear* carrying (PHR_Resource_Release(PDR_Request_Info)) - RSVP RESVerror - RSVP RESVconf

57

Interior node The following signaling messages can arrive and leave an interior node. Only messages with a PHR object are being processed.

- RSVP PATH* carrying (PHR_Resource_Request(PDR_Request_Info)) - RSVP PATH* carrying (PHR_Refresh_Update(PDR_Request_Info)) - RSVP PATHtear* carrying (PHR_Resource_Release(PDR_Request_Info)) - RSVP RESVtear - RSVP RESV* carrying (PDR_Reservation_Report) or (PDR_Refresh_Report) messages - RSVP RESVerror - RSVP PATHerror* carrying (PDR_Reservation_Report (marked)) or (PDR_Congestion_Report) - RSVP RESVconf

Egress node The messages that can arrive from inside of the RMD domain are:

- RSVP PATH* carrying: (PHR_Resource_Request(PDR_Request_Info)) - RSVP PATH* carrying:(PHR_Refresh_Update(PDR_Request_Info)) - RSVP PATHtear* carrying: (PHR_Release_Request (PDR_Request_Info) - RSVP RESVerror - RSVP RESVconf

The messages that arrive in the egress node from outside the RMD domain are: - RSVP RESV - RSVP RESVtear - RSVP PATHerror

The messages that an egress node can send outside of the RMD domain are:

- RSVP PATH - RSVP PATHtear - RSVP RESVconf

The egress node can generate the following messages that are sent into the RMD domain:

- RSVP PATHerror* carrying (PDR_Reservation_Report (marked)) or (PDR_Congestion_Report) - RSVP RESV* carrying (PDR_Reservation_Report) or (PDR_Refresh_Report) messages - RSVP RESVtear - RSVP RESVerror

4.3.2 Message interception alternatives The RSVPv2 messages listed in Section 4.3.1 have to be intercepted, as they need to be processed by the daemons. Normally packets that are not destined to a host are forwarded. Several solution to this issue exist:

• Router alert: packets that contain the router alert option are sent to the user space daemon that registered a socket with the router alert option. This solution cannot be used, since the RSVPv2 messages from inside the domain do not contain the router alert option. (See also section 3.2.3.1).

• Netlink sockets: packets can be intercepted by using firewall filters. Netlink sockets have no ports, which makes it difficult to differentiate between different packets that have been redirected by different firewall filters or when multiple processes or threads are involved.

• RT netlink is based on netlink and is used to read and alter the kernel routing tables, queuing disciplines, traffic classes and packet classifiers. It can be used to send information from kernel to user space, but this involves adding message specifications into the kernel. This gets quite complicated as there are also certain alignment requirements for messages.

• Raw sockets can be used to intercept the traffic by checking their protocol number. This solution cannot be used by the RSVPv2 daemon, because the user space program gets a copy of the packet and the packet is routed to the next hop.

58

• Libpcap can be used to intercept the traffic by checking the used interface. For Ethernet the interface can be put in promiscuous mode to get a copy of every packet. Packets are always sent on to the next hop and therefore this cannot be used by the RSVPv2 daemon.

• Divert sockets: packets can be intercepted by using firewall rules. For every rule the traffic can be forwarded to different ports. A user space process can listen on a specific port and thus get all the traffic corresponding to one or more firewall rules. This solution is a very simple one that can use standard sockets mechanisms to get packets from the kernel.

Selected Solution The Divert sockets mechanism compared to the other mechanisms is easy and simple, because it can use standard sockets mechanisms to get packets from the kernel. It is also possible to forward packets if there is no process listening on a socket associated with certain traffic. Therefore, Divert sockets will be used to intercept RSVPv1 messages from the Intserv domain and RSVPv2 messages from the Diffserv domain.

4.3.3 RSVP and RMD integration alternatives It is estimated that the major implementation work on the RSVP/RMD integration prototype will be needed on the ingress/egress nodes and minor modifications (i.e. PHR filter) will be required in the interior nodes. A number of RSVP - RMD prototype implementation solutions are possible: Solution_1: The Ingress/Egress nodes implementation makes use of the existing ISI RSVP daemon functionality [ISI-RSVP] for processing and routing of RSVP messages. The concept of this solution is depicted in Figure 4-8.

RSVP Daemon PDR Ingress Daemon Inter-process Communication

Kernel Traffic Control

Figure 4-8: Concept of Solution_1

Solution_2: The Ingress/Egress nodes implementation contains in the Ingress/Egress daemons the reduced RSVP daemon functionality for processing and routing of the RSVP signaling messages. The concept of this solution is depicted in Figure 4-9.

PDR Ingress Daemon

Kernel Traffic Control

RSVP Daemonfunctionality

RSVP messages

Figure 4-9: Concept of Solution_2

59

4.3.3.1 Implementation design requirements The two solutions on RSVP - RMD prototype implementation design impose a set of requirements on the current implementations of the ISI RSVP daemon and RMD daemons. Each of these requirements is described in the following Sections. Solution_1 In Solution_1 the Ingress/Egress nodes makes use of the RSVP daemon functionality for processing and routing of the RSVP messages, while the admission control will be done in a RMD manner. Solution_1 requires:

• Inter-process communication between RSVP daemon and Ingress Daemon • Inter-process communication between RSVP daemon and Egress Daemon • Replacements of the SEP functionality with the RSVP functionality • Encapsulation and De-capsulation of RMD messages into RSVP messages in the Ingress/Egress

daemons • Generation of local RSVP messages, i.e. RSVP RESVerror*(local) • Generation of RSVP Error (RSVP PATHerror, RSVP RESVerror) messages from the RSVP

daemon as a result of erroneous situation in the RMD domain. • Forwarding of standard RSVP messages outside RMD domain • Mapping of RSVP Tspec parameters into RMD parameters, i.e. Intserv Services to Diffserv

Services [Rexh00] and bandwidth rate into resource units. • Format of the RSVP (*) messages used in the RMD domain. • The interior node is a Diffserv node, using the dsmark queuing discipline that together with the

tcindex filter extract the Diffserv Code Point (DSCP) from the Type of Service (TOS) field in the IP-header of the packet. The DSCP indicates which traffic class the packet belongs to and the second tcindex will place the packet into the correct queue based on the DSCP. However the RSVP messages have no TOS field in the format, thus the TOS field in the IP header will have to be used for this purpose.

• Changes to the PHR filter Solution_2 In Solution_2 the Ingress/Egress nodes do not use of the ISI RSVP daemon functionality for processing and routing of the RSVP messages. Instead in the ingress/egress daemon the SEP modules and functionality is replaced with the reduced RSVP daemon functionality (i.e., no multicast, single filter style) defined in RFC2209. This means that the generation and processing of the RSVP messages and the related data structures with reduced functionality (i.e., no multicast, single filter style) will be implemented in the RMD Ingress/Egress daemons. Solution_2 will require:

• Replacements of the SEP functionality with the RSVP functionality • Routing/Processing of the RSVP signaling messages in the standard way This means that a set of

data structures with limited functionality defined in [RFC2209] will need to be implemented. The data structures that need to be implemented are:

o PSB (Path State Block) that keeps the path state for each (session, sender) pair defined by SESSION AND SENDER_TEMPLATE objects received in a PATH message.

o RSB (Reservation State Block) that keeps a reservation state for each request of RESV message for the triple (session, NEXT HOP, filter_spec list). In our case the filter_spec list would be a single FILTER_SPEC, i.e. Fixed Filter (FF) style

o BSB (Blockade State Block) contains elements of blockade state and is related to refresh messages

o TCSB (Traffic Control State Block) keeps the reservation specification for each reservation request parsed tot he traffic control for a certain outgoing interface. The traffic control will need to be performed on RMD manner.

• Encapsulation and de-capsulation of RMD messages into RSVP messages, that needs to be done in the Ingress/Egress daemons

• Generation of local RSVP messages, i.e. RSVP RESVerror* (local) message • Generation of RSVP Error (RSVP PATHerror, RSVP RESVerror) messages as a result of an

erroneous situation in the RMD domain. • Forwarding of standard RSVP messages outside RMD domain

60

• Mapping of RSVP Tspec parameters into RMD parameters, i.e. Intserv Services to Diffserv Services [see Rexh00] and bandwidth rate into resource units.

• Format of the RSVP (*) messages used in the RMD domain. • The interior node is a Diffserv node, using the dsmark queuing discipline that together with the

tcindex filter extract the Diffserv Code Point (DSCP) from the Type of Service (TOS) field in the IP-header of the packet. The DSCP indicates which traffic class the packet belongs to and the second tcindex will place the packet into the correct queue based on the DSCP. However the RSVP messages have no TOS field in the format, thus the IP header field will be used for this purpose.

• Changes to the PHR filter

4.3.3.2 Comparison of solutions Based on the above given solution requirements the following comparison criteria are defined:

• C1: usage of RSVP daemon functionality • C2: changes to the RMD daemons • C3: the implementation complexity related to each of the solutions and considering the time

constraints Using the above criteria, a comparison between the two implementation solutions is accomplished. Solution_1: Criterion C1: Solution_1 requires the usage of the ISI RSVP daemon and also extensive modifications to it in order to:

• communicate with the RMD daemons • generate RSVP PATHerror* and RSVP RESVerror* messages in a standard RSVP manner.

This will require knowledge on definition of Error Codes of RSVP [RFC2205] and on implementation of this functionality in RSVP daemon.

Criterion C2: Solution_1 requires the following changes to RMD (ingress, egress) Daemons:

• removal of SEP functionality • introduction of RSVP functionality, with conformance between the PDR state and the RSVP

Flow ID • encapsulation of PHR/PDR messages into RSVP messages • generation of RSVP/RMD messages • generation of local RSVP messages, i.e. RSVP RESVerror* (local) message • generation of RSVP Error (RSVP PATHerror, RSVP RESVerror) messages as a result of

erroneous situation in the RMD domain. • forwarding of standard RSVP messages outside RMD domain • mapping of RSVP Tspec parameters into RMD parameters, i.e. Intserv Services to Diffserv

Services [Rexh00] and bandwidth rate into resource units. Criterion C3: Solution_1 requires inter-process communication between ISI RSVP daemon and Ingress and Egress daemons. In the RSVP - RMD interoperability scenario this inter-process communication is done via SEP, that is the ISI RSVP daemon talks to the Ingress daemon as if it was a SEP client. This requires modifications in both RSVP daemon and Ingress daemon, such that they send/accept SEP packets through the Unix socket interface. This will also require changes to the Egress daemon as well. However, this inter-process communication between the ISI RSVP daemon and RMD daemon can not be used anymore, as the SEP functionality in the ISI RMD daemon will have to be replaced with the RSVP functionality. One possible solution would be to parse the RSVP messages to and from RMD daemons respectively using Unix sockets. In any case this would require extensive and complex modification of both ISI RSVP and RMD (Ingress, Egress) daemons. Solution_2 Criterion C1: Solution_ 2 does not require the usage of the ISI RSVP daemon. Criterion C2: Solution_2 requires the following changes to RMD (ingress, egress) Daemons:

61

• removal of SEP functionality • introducing of RSVP functionality into the RMD daemons for generating/processing and routing

of the RSVP signaling messages in the standard way. This means that the data structures with limited functionality defined in RFC2209 will need to be implemented. The data structures that need to be implemented are:

o PSB (Path State Block) that keeps the path state for each (session, sender) pair defined by SESSION AND SENDER_TEMPLATE objects received in a PATH message [RFC2209]

o RSB (Reservation State Block) that keeps a reservation state for each request of RESV message for the triple (session, NEXT HOP, filter_spec list). In our case the filter_spec list would be a single FILTER_SPEC, i.e. Fixed Filter (FF) style [RFC2209]

o BSB (Blockade State Block) contains elements of blockade state and is related to refresh messages [RFC2209]

o TCSB (Traffic Control State Block) keeps the reservation specification for each reservation request parsed tot he traffic control for a certain outgoing interface [RFC2209]. The traffic control will need to be performed on RMD manner.

• introduction of RSVP functionality, with conformance between the PDR state and the RSVP

Flow ID • encapsulation of PHR/PDR messages into RSVP messages • generation of RSVP/RMD messages • generation of local RSVP messages, i.e. RSVP RESVerror* (local) message • Generation of RSVP Error (RSVP PATHerror, RSVP RESVerror) messages as a result of

erroneous situation in the RMD domain. • Forwarding of standard RSVP messages outside RMD domain • Mapping of RSVP Tspec parameters into RMD parameters, i.e. Intserv Services to Diffserv

Services [Rexh00] and bandwidth rate into resource units. Criterion C3: Solution_2 requires no usage of the RVSP daemon, thus no need for inter-process communication between the between RSVP daemon and Ingress and Egress daemons. But instead the RSVP daemon functionality needs to be implemented from scratch into the RMD daemons. Implementation of this functionality would require implementation of all the generic data structures defined in RFC2209 although with a limited set of functions, which is quite a difficult task that will require first extensive knowledge of the RFC2205, RFC2209 and also of the current ISI RSVPd implementation. Selected Solution Based on the above comparison between Solution_1 and Solution_2, it can be concluded that Solution_2 is the one that requires the least amount of modifications and no usage of the ISI RSVP Daemons. Therefore, Solution_2 is the selected solution.

4.3.4 Implementation Overview Figure 4-10 shows the overview of the implementation of the ingress, interior and egress functionality in all nodes. The RSVPv2 daemon, running in user space, used on both nodes is the same and all functionality is mirrored, i.e., it does not matter from what side the reservation originates. As opposed to the original implementation of RMD, now all processing of signaling messages on the edges is done in the RSVPv2 daemon, i.e., in the user space. One reason for this modification is that the prototype implementation is less dependent on the used operating system. The functionality that is implemented in the Linux kernel can only be used on Linux operating systems. While the functionality that is implemented in the user space can also run on other operating systems. Furthermore, adjustments to the code are easier and less error prone, since programming errors affect only the program itself and not the rest of the machine. This makes it also easier to create and debug the code. However, a disadvantage of this modification might be that the implementation on the edge nodes becomes slower, as more often a switch to user space has to be made. The divert sockets functionality for IPv4 as represented by IPPROTO_RSVP, was patched into the linux 2.4.19 kernel. (See [Bald03]). The IPv4 divert socket functionality was extended to support divert sockets with IPv6 also.

62

Each edge node has one or more external interfaces and one or more internal interfaces. The external interface is the interface that connects the edge node to the external RSVP part of the network, outside of the RMD domain. The internal interface is the interface that connects either the edge node to an internal node or two internal nodes. Each external and internal interface uses one input and one output buffer. The ingress functionality is located on the input buffers of the external interfaces. The interior functionality is located on the output buffers of the internal interfaces and the egress functionality is located on the output buffers of the external interfaces.

In particular, the RSVP filter (i.e. RSVPv2 filter) and policing functionality, which are part of the ingress functionality, are located at the input buffer of the edge node. In the original RMD implementation the ingress functionality was located at the output buffer of the internal interface of the edge node. An advantage of using the input buffer is that the interior functionality can be exactly the same on all interfaces, including the interfaces of the edge nodes. There is no need to have ingress functionality located on the same output buffer, as can be seen from Figure 4-10. This simplifies the implementation and allows for easier modification of the queuing structure of the interior node. It is also no longer needed to find the route a message was coming from, in order to know whether it was coming from inside or outside the RMD domain. This component is implemented by using the ingress qdisc that is standard in the linux kernel. Policing is supported using a Token Bucket Filter (TBF). The egress functionality is located at the output buffer of the external interface of the edge nodes. When additional functionality is needed, it is also possible to use the intermediate queuing device [IMQ] that is available as a patch to the kernel. Using this queuing device it is possible to attach all standard egress queuing disciplines on input buffers, instead of on output buffers. When a packet travels from left (bottom) to right (top) of Figure 4-10 it first passes the ingress functionality located at the input buffer of the external interface of edge1. Then it goes through the interior functionality at the output buffer of the internal interface of edge1 and interior nodes. Then it passes the egress functionality located at the output buffer of the external interface of edge2 and it leaves the RMD domain.

According to the RMD specification, the interior functionality should also be implemented at the output buffer of the external interface of the egress node (edge2). Due to time constraints this functionality has not been implemented in that node, however the QoS requirements at the moment could be satisfied as RSVP is used for traffic control on that interface. There are situations where interior functionality would be needed at the output buffer of edge2 as well, e.g. in the case of multi-domain reservations. A node could then be an interior node for one domain and an edge node for the other domain, but this is beyond the scope of this thesis. For easier understanding it is assumed the reservation originates from the left side (lower part) of Figure 4-10. The handling of signaling messages and data packets will be described separately in Section 4.3.5, Section 4.3.6 and Section 4.3.7 for the ingress node, interior node and egress node, respectively. The functionality of the RMD/RSVP (i.e., RSVPv2) daemon is described in Section 4.3.8.

63

ingressegress ingress

egressPHR PHRPHR

data data

Edge1 Edge2Interior

PHR

RSVP/RMD Daemon

previoushop

nexthop

to egress

fromingress

RSVP/RMD Daemon

IPPROTO_RSVPexternal


IPPROTO_RSVPinternal


signal signal

user space

kernel space

ingress qdisc + rsvp filter

divert socket

egress qdisc + rsvp filter

PHR qdisc

standard interface


egressPHR PHRPHR

data data

Edge1 Edge2Interior

PHR

RSVP/RMD Daemon

previoushop

nexthop

to egress

fromingress

RSVP/RMD Daemon





signal signal

user space

kernel space


divert socket


PHR qdisc

standard interface

External interface Internal interface External interfaceInternal interfaceInternal interface Internal interface


egressPHR PHRPHR

data data

Edge1 Edge2Interior

PHR

RSVP/RMD Daemon

previoushop

nexthop

to egress

fromingress

RSVP/RMD Daemon





signal signal

user space

kernel space


divert socket


PHR qdisc

standard interface


egressPHR PHRPHR

data data

Edge1 Edge2Interior

PHR

RSVP/RMD Daemon

previoushop

nexthop

to egress

fromingress

RSVP/RMD Daemon





signal signal

user space

kernel space


divert socket


PHR qdisc

standard interface

External interface Internal interface External interfaceInternal interfaceInternal interface Internal interface

Figure 4-10: Implem

entation overview

64

4.3.5 Ingress node The kernel space implementation of the ingress node is given at the left side (or lower side) of Figure 4-10. The ingress functionality that contains the ingress qdisc and the rsvp filter components has been expanded to Figure 4-11. The ingress functionality is located at the input interface, while the processing of messages is done in the daemon as describes in section 4.3.8. The required RSVPv2 functionality for processing signaling and data packets is described in the following paragraphs. The rsvp filter component used in the implementation of the ingress functionality in the IPv4 version of RSVPv2 is different then the same component that is used in the implementation of the ingress functionality in the IPv6 version of RSVPv2. However, all the other components used in the implementation of the ingress functionality are the same for both versions, i.e., IPv4 and IPv6.

external interface

ingress ffff

rsvp filter police

reclassify

rsvp filter

unreserved traff ic

police

tc_index

reclassify

tc_index

ingress

external interface

ingress ffff

rsvp filter police

reclassify

rsvp filter

unreserved traff ic

police

tc_index

reclassify

tc_index

ingress

Figure 4-11: Ingress queuing disciplines at an external interface

Signaling packets When a RSVP PATH signaling message arrives at the external interface of Edge1, it is intercepted by a diverting rule that is performed by the functional block “IPPROTO_RSVP external” . The RSVP/RMD (i.e., RSVPv2) Daemon processes the message and sends a PATH toward the destination with the correct DSCP (e.g. EF) and the requested number of resource units. This depends on the mapping function that should be implemented according to the Service Level Agreement (SLA). Also the PHR and PDR objects are introduced into the RSVP message (see Section 4.3.8 for more details). When the PDR report, contained in a RESV message, returns at Edge1 the message is intercepted by a diverting rule and sent to user space with Divert sockets. This is performed by the functional block “IPPROTO_RSVP internal” . The RSVPv2 Daemon adds a rsvp filter at the ingress qdisc, it removes the PDR object and sends the RESV message to the previous hop (see Section 4.3.8 for more details). The reservation is now made in the entire domain and data packets can make use of the requested Quality of Service.

65

Data packets When a data packet arrives at Edge1, it is first checked if any of the rsvp filters match the flow ID. If a matching filter is found, policing is done using a token bucket filter (TBF). When the packet passes the policing procedure, the tc_index field is set, corresponding to the mapping between the RSVP guaranteed service and the Diffserv class. If the packet does not pass policing procedure, it is checked if any other filter matches the flow (reclassification). If that is the case then the traffic is processed and the tc_index field is set, corresponding to the mapping between the RSVP guaranteed service and the Diffserv class. Otherwise, the last filter that always can match the traffic is the Best Effort filter. Thus policed data is not dropped, but sent on as Best Effort traffic.

4.3.6 Interior node As can be seen in Figure 4-10 the implementation of the interior node is located at the output buffer. The reservations are still managed using the sliding window protocol just like in the original RMD implementation (see [Jaco01]). Because the “RMD in IP payload” alternative is used (see Section 3.2.2.4 and [Shi02]), some modifications have to be made to the existing encapsulation method (i.e., the one that is described in [Jaco01]). The function get_phr_roda was modified to locate the PHR object in the RSVP message. This function is used when an interior or ingress node needs to retrieve PHR information from the RSVP message. The location of RSVP objects in the IP packet is not defined, thus the objects may be presented in random order. To make it possible to locate the RMD objects in the RSVP message without processing all RSVP objects, they are added to the end of the packet. For IPv4, the function gets the header length of the message from the total length field in the IP header. For IPv6 the length of the message is calculated from the payload length field in the IPv6 header and the fixed length of the header itself (see Chapter 3 for more details). Figure 4-12 shows a coding example. This is the only location where the interior node functionality differs between IPv4 and IPv6. The further implementation of the interior node functionality was kept the same as in the first RMD prototype implementation. A description of the compose and decompose functionality is given in section 3.2.2.3 and section 4.3.8. In Figure 4-13 a more detailed view of the interior node, including EF and AF classes, is given.

if (protocol != RSVP) return NULL; // no rsvp packet rsvp_len = get_rsvp_len(payload); phr_object = iph + rsvp_len; if (!((*(phr_object + 2) == RSVP_CLASS_RMD_PHR_RODA) && (*(phr_object + 3) == 1))) return NULL; // No PHR packet phr = (phr_object + 4); if (phr->id != PHR_ID_RODA) return NULL; //No PHR RODA packet return phr;

Figure 4-12 Locating the PHR information in the RSVP message

66

Signaling packets Inside the RMD domain the PHR functionality maintains the resource reservations. Note that the output buffer of the internal interfaces of each edge and interior nodes are identical. The packet travels through the PHR qdisc at the output buffer of the internal interface of the edge or interior node. The correct PHR qdisc is selected by the DSCP field in the header of the ip packet by the tc_index filters. The PHR signaling messages get priority over the data packets, by using a local DSCP. This is done because Diffserv does not allow re-ordering of packets belonging to the same DSCP. The PHR qdisc finds the PHR object in the RSVP packet and processes it. When enough resources are available a Diffserv reservation is made and the packet is send to the next hop. Otherwise the request is marked and send to the next hop. When a RESV message arrives from the egress node, the interior nodes do not process the PDR information in the RSVP messages, as this is a PDR report only. Data packets Inside the RMD domain, the internal interfaces of Edge1 and Core nodes are set up identical for data packets also. The packet travels through the PHR traffic qdisc at the internal interface of the edge or core node. The correct PHR qdisc is selected by the DSCP field in the header of the ip packet and the tc_index field. In Figure 4-10 there is a EF and a AF class, but more can be added in a similar manner. When leaving the dsmark qdisc the DSCP is set to the correct value when needed (marking) and the packet is send to the next node.

internal interface

cbq 20:0

dsmark 1:0

PHR fifo200:1

fifo200:2

tc_indexEF

prio 20:200

PHR fifo

fifo

prio

fifo20:21

tc_indexEF local

tc_indexEF local PHR

tc_indexAF1x

tc_indexAF1x local

tc_indexAF1x local

PHR

ingress / internal

traff ic

traff ic

tc_indexBest effort

internal interface

cbq 20:0

dsmark 1:0

PHR fifo200:1

fifo200:2

tc_indexEF

prio 20:200

PHR fifo

fifo

prio

fifo20:21

tc_indexEF local

tc_indexEF local PHR

tc_indexAF1x

tc_indexAF1x local

tc_indexAF1x local

PHR

ingress / internal

traff ic

traff ic

tc_indexBest effort

Figure 4-13: Queuing disciplines on interior node including AF

67

4.3.7 Egress node The kernel space implementation of the egress node is given at the right side (or top side) of Figure 4-10. The egress functionality, that is the part containing the rsvp filter and fifo queue, has been expanded to Figure 4-14. The structure of the queues is similar to the structure used in an ISI RSVP daemon for a guaranteed service. The required RSVPv2 functionality for processing signaling and data packets is explained below. The rsvp filter component used in the implementation of the egress functionality in the IPv4 version of RSVPv2 is different then the same component that is used in the implementation of the egress functionality in the IPv6 version of RSVPv2. However, all the other components used in the implementation of the egress functionality are the same for both versions, i.e., IPv4 and IPv6. Signaling packets When entering Edge2 the RSVP message is intercepted by a diverting rule and it is sent to the user space through a specific port using the Divert sockets. The functional block “ IPPROTO_RSVP internal” provides this functionality. The RSVP/RMD (i.e., RSVPv2) Daemon processes the RSVP message and it adds a qdisc and a rsvp filter. Then a PATH message without PDR or PHR objects is sent towards the destination with the DSCP field set to 0, i.e. a default value. When Edge2 receives a RSVP RESV message at its external interface, it is intercepted by a diverting rule and sent to user space through a specific port using Divert sockets. The functional block “ IPPROTO_RSVP external”provides this functionality. The RSVP/RMD (i.e., RSVPv2) Daemon processes the message, it inserts a PDR Reservation report object in the packet and it sends a RESV message to the previous hop with the correct DSCP set. Data packets At Edge2 the data packet matches the rsvp filter that corresponds to its flow ID. The DSCP is set to 0, i.e., default value, and the packet outgoes the RMD domain.

external interface

cbq 30:0

rsvp filter fifo6001:

unreserved traff ic

dsmark 1:0



egress

external interface

cbq 30:0


unreserved traff ic

dsmark 1:0



egress

Figure 4-14 Egress queuing disciplines at an external interface

68

4.3.8 RMD/RSVP (RSVPv2) daemon The RMD/RSVP (RSVPv2) daemon was written from scratch in the object-oriented programming language python (see [Python]). Most functionality that was implemented in kernel modules in the first prototype is now located in the RSVPv2 daemon. This makes the software flexible and extendible, without the need to recompile the code after making changes. Also there are no longer separate daemons for ingress and egress functionality, but these are integrated into one daemon. The daemon operates as an ingress and an egress daemon at the same time, without the need to do any configuration. The ingress or egress functionality in the daemon is selected by the interface a message arrives from and the type of the message. E.g. when a PATH message arrives from an external interface, the ingress functionality is used and when a PATH message arrives from an internal interface the egress functionality is selected. See Figure 4-15 for an overview of the functional block used in the RMD/RSVP daemon.

RSVP_Server

IPv4 IPv6 RSVP_Socket

socket

Traffic Control List (TCL)

IPv4_address IPv6_address

IF_Link

= inheritance


TC_Link


TC_Flow


TC_Link_RMD

IPv4_address IPv6_address TC_Flow_RMD

RSVP_Request

RMD_Message

RSVP_Message

PSB RSB

RSVP_State

Figure 4-15: RMD/RSVP daemon functional blocks

69

The main functional blocks of the RMD/RSVP daemon are:

• RSVP_Message: defines all possible RSVP objects. The RMD objects are included in the RMD_Message object.

• RSVP_Request: handles all requests, arriving through the RSVP_Sockets or typed by the user • RSVP_Server: this is the main container object that holds all other objects • RSVP_Socket: the specification of the input and output sockets and their options, based on the

statndard socket object. • RSVP_State: this object keeps the state of RSVP flows in the PSB and RSB • TC_Flow_RMD: this installs the flows on traffic control links (TC_Link_RMD) according to the

reservations as signaled by the RSVP_Request handler • TC_Link_RMD: this specifies traffic control on interface links (IF_Link)

In the implementation of the daemon inheritance is used as much as possible, to avoid recoding the same functionality multiple times. Note that all blocks (and files also) starting with a capital letter where newly implemented. The main functional block is the RSVP_Server. All objects inside this block can make use of the methods it provides. For example, the socket object has a sub block RSVP_Socket which is divided in an IPv4 and IPv6 part. All other objects can make use of the RSVP_Socket object without needing to know whether IPv4 or IPv6 is used. The object provides all functionality for the IP version it was instantiated with. There is the RSVP_Request object that processes all messages that arrived through the RSVP_Socket and update the state maintained in the RSVP_State object (PSB and RSB) through the Traffic Control List (TCL) object. It contains a general RSVP_Message object and the RMD_Message object derived from that. The TCL maintains for every interface the Traffic Control (TC_Link_RMD) used on that link and the flows that are present (TC_Flow_RMD). Here the queues for data and signaling packets are installed and uninstalled when needed The daemon can be configured using command line parameters. Several scripts are provided which set useful combinations of parameters. The RMD/RSVP daemon can be configured to support IPv4, IPv6 or both version of the IP protocol. The main implementation differences can be seen in Figure 4-15. All objects provide the same functions, but where needed a different version exists for IPv4 and IPv6. An object is instantiated for IPv4 or for IPv6. When a function from that object is used it is automatically the version needed for the correct IP version. There are several roles the RSVPv2 daemon can have:

• RSVP: the daemon behaves as a standard RSVP daemon • RSVP_FORK: two RMD/RSVP daemons behave as one single RSVP router. There can be more

nodes in between but there does not need to be any kind of traffic control between those two edges.

• RSVP_SNIF: the daemon does not do any processing of RSVP packets, it only displays the received RSVP packets and transmits them to the next hop unmodified.

• RSVP_LOOP: the daemon responds to every PATH message it receives with a corresponding RESV message. This is meant to function at the end host, where every resource reservation is accepted.

• RSVP_FGEN: the RSVPv2 daemon generates random RSVP flows for which the duration and rate are determined using a random exponential distribution.

Further the mode of the RMD/RSVP daemon can be set to sender initiated or receiver initiated. This only makes sense in combination with the RSVP and RSVP_FORK roles of the daemon.

70

Also the traffic controls to be used by the daemon can be specified. This is only useful in combination with the RSVP_FORK role of the daemon.

• TC_NONE: This is the framework for other traffic control mechanisms, no traffic control is actually done.

• TC_TC: This is used for adding and removing standard linux traffic control elements from the interfaces. This is only here to show it is possible to add other kinds of traffic control.

• TC_RMD_TC: This is the RMD traffic control that is used in the implementation. There are several commands that can be given while running the RMD/RSVP daemon. The “STATUS” command prints the contents of the Path State Block (PSB) and Reservation State Block (RSB). The “STOP” command halts the flow generator, while the daemon keeps running. This is useful when the daemon has to keep responding to PATH messages sent by another daemon (RSVP or RMD/RSVP). Because the RMD/RSVP daemon supports both ingress and egress functionality it has to keep track of where a message originated from and whether it is incoming or outgoing. Also a differentiation is made between internal and external, thus inside and outside of the RMD domain. The following terminology is used, when differentiating between sockets:

- II: Input Internal - IE: Input External - OI: Output Internal: this socket has to correctly set the DSCP value to the DSCP assigned to the

flow associated to the signaling message that has to be sent (set the tos field to 0xb8 for the EF class).

- OE: Output External: this socket has the router alert option set as this is used by all RSVP daemons outside the RMD domain.

When the RMD/RSVP Daemon is started first all links, from the configuration file, that are going to be used are setup. In the configuration file the IPv4 and/or IPv6 addresses of the interfaces are specified. Also the specified traffic control mechanism is setup on the links. Then the daemon sets up rules for the divert sockets mechanism and opens four sockets for every IP version it has to support and starts listening for RSVP messages from the sockets. As the daemon should rebuild all RSVP messages using the information in the PSB and RSB, encode and decode functions have been implemented, that are based on the composing and decomposing functions described in section 3.2.2.3. It is not allowed to just add the RMD PHR and PDR objects to the message, but the daemon has to rebuild the entire message from its objects. This is a generic solution that encodes all RSVP objects, including the PHR and PDR objects when needed, into the IP packet. The encode function sorts all RSVP messages on their RSVP class number and adds them one by one to the RSVP message. The decode function finds and extracts all RSVP objects in the message. The RMD objects have got a class number (253 and 254) that is higher than all other RSVP objects and they therefore are included at the end of the RSVP message. The compose and decompose functionality both are achieved using first the decode function followed by the encode function with the needed RSVP objects (including or excluding the RMD objects).

4.3.9 Signaling message processing This section describes the processing of the signaling messages that are used in the RSVPv2 integration prototype implementation and are given in Section 4.3.1. All message processing is done in the RMD/RSVP daemon. The method used to get a RSVP message into the daemon is described in Section 4.3.2. Most of the objects contained in the RSVP messages do not need to be changed and have to be forwarded as they are. Messages sent outside the RMD domain contain the IP router alert option, while message sent inside the RMD domain the DSCP value set. The processing of standard RSVP messages follows the rules as defined in [RFC2209]. The extra processing required for the RMD protocol is described below. Note that the ingress and egress node functionality is implemented in one single daemon.

71

Ingress node functionality when a PATH arrives When a PATH message arrives in the RSVPv2 daemon, information from all objects included in the message (see Section 3.2.2.2) are stored in the Path State Block (PSB). Note that when a message corresponding to a certain flow has to be sent outside the ingress node, the stored information from the PSB associated with the same flow, has to be included into this message. The RSVPv2 daemon has to determine whether this message corresponds to a new flow or it is a refresh message for an existing flow. On a new message the RSVPv2 daemon will initiate an admission control function. For each new flow a RSVP filter and a TBF for policing will be installed. This is however, done only when the PDR report corresponding to the reservation request has been received. The RSVPv2 daemon is responsible for generating RSVP PATH* messages, that are including the PHR_Resource_Request and PDR_Request_Info objects, which will be sent towards the egress node. This RSVP PATH* message does not contain the IP router alert option. The mapping of the RSVP Guaranteed Service into the Diffserv EF class is done by the RSVPv2 daemon by setting either the TOS field in the IPv4 header or the traffic class field in the IPv6 header. Other mappings can be specified to get approximately the same Quality of Service inside and outside of the RMD domain. For example, the RSVP Controlled Load service could be mapped onto the Diffserv AF class. The RSVP service is specified in the c field of the SENDER_TSPEC object (see Appendix A). The following token bucket parameters that are also contained in the SENDER_TSPEC object of the RSVP PATH message specify the reservation request:

- Token Bucket Rate(r) - Token Bucket Size (b) - Peak Data Rate (p) - Minimum Policed Unit (m) - Maximum Packet Size (M)

The above RSVP reservation request parameters have to be mapped into the PHR resource units parameter. This is done in an identical way as in the original RMD prototype implementation. The flow ID that uniquely identifies an RSVP sessions can be found by combining the information from the SENDER_SEMPLATE object (source IP address and port) with the SESSION object (destination IP address, port and protocol). The refresh timeout is controlled by the RSVPv2 daemon as the external protocol also supports the soft state principle. The lifetime and refresh period of a flow is taken from the LPATH and RPATH parameters of the TIMES_VALUES object (see Appendix A). The RPATH and LPATH parameters and their calculation are described in [RFC2205]. In the current implementation the refresh period is chosen to be the same as the default refresh period of RSVP, namely 30 seconds. The refresh period in the entire RMD domain must be the same and if there is a difference the RMD/RSVP daemon should use the different values for inside and outside the RMD domain. Then a timer should be introduced that sends out PATH* messages containing a PHR refresh object every 30 seconds to prevent the reservation from timing out or duplicating inside the domain. When a PATH message is a refresh, i.e. a state for this flow already exists in the RSVPv2 daemon, a PATH*(PHR_Refresh_Update(PDR_Request_Info)) message is generated. Ingress node functionality when a PATHtear arrives When a PATHtear message arrives, the RSVPv2 daemon will try to match this message to one of the existing flows by searching for PSBs with the same SESSION and SENDER_TEMPLATE objects. If a match is found a RSVP PATHtear* (PHR_Resource_Release(PDR_reqInfo)) message is generated and sent towards the destination of the flow. All the existing PSB and RSB states that are associated to this flow have to be removed. The message does not contain the IP router alert option in the IP header. Moreover, the RSVPv2 daemon has to map the RSVP guaranteed service into the corresponding Diffserv class by marking the corresponding DSCP. After this message is sent to the next Interior Node, the RSVP filter and the TBF for policing are removed from the queuing structure of the interface. Ingress node functionality when a RESV* message arrives When a RESV* message arrives into the RSVPv2 daemon, the daemon has to match this message with a PSB that has been generated by a PATH message. If this information is found and a PDR_Reservation_Report is included into the RESV message then the information from all objects included in the message (see Section 3.2.2.2) is stored in a RSB. This means that this message is a new reservation request for which an RSVP filter and TBF for policing need to be installed. After this, the data traffic associated with this flow can be sent through the domain and the correct DSCP value can be set. If the received RESV message contains a PDR_Refresh_Report message, then the RESV message is a

72

refresh message for which the state must be updated. In both cases a RESV message has to be generated and sent on to the previous hop that is specified in the PSB state, with the router alert option set in the IP header. No RSVP messages containing PHR or PDR objects will outgo the domain. Ingress node functionality when a RESVtear message arrives A RSVP RESVtear message (sent by the egress node) that arrives at the RSVPv2 Daemon of the Ingress Node does not contain any PHR or PDR objects. Similar to the functionality that is used when a PATHtear arrives, also in this case an existing RSB state is removed and the RSVP filter and TBF are uninstalled. Additionally a RESVtear message has to be sent to the previous hop as listed in the PSB state. Ingress node functionality when a PATHerror* message arrives A RSVP PATHerror* message (sent by the egress node) that arrives at the RSVPv2 Daemon of the Ingress Node may contain a (PDR_Reservation_Report (marked)) or a (PDR_Congestion_Report). In both cases the RSVPv2 daemon will send a PATHtear* message with the TTL value corresponding to the number of nodes that successfully performed the reservation. Also a PATHerror message is generated and sent towards the next hop, outside the RMD domain. The information used to fill all the objects is taken from the PSB state. An appropriate error code, as defined in [RFC2205] has to be used in the ERROR_SPEC object, e.g. error code 02 for admission control failures. The source IP address of the PATHerror message is the IP address of the interface used to send the message out the RMD domain. Similar to the functionality that is used when a PATHtear arrives, also in this case the existing PSB and RSB states are removed and the RSVP filter and TBF are uninstalled. Ingress node functionality when other RSVP messages arrive When a RESVconf or RESVerror message arrives, the ingress node will not use it at all. This message will just be forwarded by the routing protocol towards the receiver end host. Interior node functionality when a PATH* arrives When a RSVP PATH* message arrives at the interior node it is first classified by the tc_index filter into an appropriate traffic class. Then the PHR filter is used to separate the signaling messages containing PHR information from the data packets. If the message contains an PHR_Resource_Request, admission control is provided by using the sliding window algorithm (see [Jaco01]). After accepting the request the PHR reservation state for the corresponding DSCP is updated with the value of the requested resources. The message will then be enqueued and forwarded towards the destination end host. If the request is not accepted it is marked and the PDR time to live value is adjusted to enable the partial release mechanism. The message is then enqueued for forwarding to the egress node that is in the communication path to the end host. If a marked reservation is received by an interior node no admission control is done and the reservation state is not updated. If the message contains a PHR_Refresh_Update object, the PHR reservation state is updated by using the sliding window algorithm, the message is put in the correct queue and forwarded toward the destination end host. Interior node functionality when a PATHtear* arrives When an RSVP PATH TEAR* message arrives at the interior node it is first classified by the tc_index filter into an appropriate traffic class. Then by the means of the PHR filter it will check whether this message is an RSVP signaling message carrying a PHR object. If the PHR object is a PHR_Resource_Release message, then the interior node releases the number of units as specified in the requested resources field of the message. The sliding window algorithm is used to decrease the number of resources included in the PHR reservation state. Then the message is forwarded to the next interior (or edge) node in the communication path.

73

Interior node functionality when other RSVP messages arrive When a RSVP RESVtear, RSVP RESV*, RSVP RESVerror, RSVP PATHerror* or RSVP RESVconf message arrives, the interior node will not use it at all. This message will just be forwarded by the routing protocol towards the end host. Egress node functionality when a PATH* arrives A RSVP PATH* message that arrives at an egress node can carry either a PHR_Resource_Request or a PHR_Refresh_Update object. The RSVPv2 daemon stores the information from all objects in the message in the PSB state. The flow ID of the RSVP session is determined by combining the information included in the SENDER_TEMPLATE and SESSION objects of the RSVP message. Similar to the situation when the PATH message arrives at the ingress node, the refresh period inside and outside of the domain can be unequal and the RSVPv2 daemon should handle the difference. In the implementation the default refresh period of RSVP, 30 seconds, is used in and outside of the RMD domain. To avoid the erroneous detection of a non RSVP router in the communication path, the Send_TTL value in the common header of the PATH message has to be adjusted as described in Section 3.2.2.2. When a PHR_Resource_Request object is found in the RSVP message, the “M” bit signals whether the reservation was successful in entire domain. If the message was not marked (“M” bit not set) an admission control function is used to check whether there are enough free resources for the RSVP flow. A RSVP filter and a FIFO queue is installed that separates the data packets by flow and sets the DSCP value back to zero. A PDR_Reservation_Report is created and sent with an RESV* message towards the ingress node. The RSVP PATH message is generated from the information stored in the PSB state and sent outside the RMD domain. If the message was marked (“M” bit set) a RSVP PATHerror* carrying a PDR_Reservation_Report is generated and sent towards the ingress node. The PDR_Reservation_Report specifies that the reservation was not successful and it contains the TTL value that locates the interior node in the communication path that did not accept the PHR_Resource_Request. The PATH message is not sent on towards the destination end host. When a PHR_Refresh_Update message is detected in the RSVP message, the “S” bit signals a severe congestion situation. If the message is not marked (“S” bit not set) a PDR_Refresh_Report is created and sent with an RESV* message towards the ingress node. Then the RSVP PATH message has to be forwarded outside the RMD domain with the IP router alert option present. If the message was marked (“S” bit set) the RSVPv2 daemon will have to generate a RSVP PATHerror* message carrying a PDR_Refresh_Report object. The PDR_Refresh_Report object again contains the TTL value that is used for the partial release functionality. The PATH message is not sent on towards the destination end host Egress node functionality when a PATHtear* arrives This message arrives from inside the RMD domain. The RSVPv2 daemon relates the message to one of the PATH states and flow Ids that it is maintaining. If a match is found, the RSVP filter and FIFO queue associated with this flow are uninstalled. A PATHtear message is generated and sent towards the next hop outside the RMD domain. Also any existing PSB and RSB (when present) states corresponding to this flow have to be removed. Egress node functionality when other RSVP messages arrive When a RESV, PATHerror, RESVerror, RESVtear or RESVconf message arrives, the egress node will not use it at all. This message will just be forwarded by the routing protocol towards the end host.

74

75

5 Experimental Results This chapter describes the experiments and the demonstration that were accomplished using the RMD prototype implementations. One of the main objectives of this assignment was to emphasize that the bi-directional feature described in [WeJa03] can be implemented into the Linux environment. Another main objective of this assignment was to emphasize that the integration between the RSVP and RMD protocols is achievable and implementable into the Linux environment. The experiments and the demonstration have been performed to verify the functionality of the prototype implementations. This chapter introduces the network setup, the configuration of the performed experiments. Furthermore, this chapter presents the experiments results and their analysis. Finally, the accomplished demonstration is described.

5.1 Bi-directional reservation experiments

5.1.1 Network setup This section describes the setup of the network as used in the bi-directional experiments. The logical network structure consisting of RSVP routers and the RMD Diffserv domain, is given in Figure 5-4. The Server and Client nodes use the SEP protocol (See [Jaco01]), the edge nodes and the interior node use RMD. All edge nodes in the RMD domain are running both ingress and egress daemons. The hardware is all PC based, running Linux kernel 2.4.16 and the links between nodes are 100 Mbps Ethernet connections.

Server Client

RMD domain SEP SEP

Edge1 Edge2 Interior

Figure 5-1: RMD network configuration for bi-directional experiments

The successful bi-directional reservation is described in section 5.1.2 while section 5.1.3 details the unsuccessful reservation scenario.

5.1.2 Successful Reservation functionality experiments This section describes the functionality experiments used to verify the operation of the bi-directional reservation during a successful reservation. In this experiment, the sender end host initiates one bi-directional reservation. The entire process is depicted in Figure 5-2, where left side of the figure represents edge1 and the right side of the figure edge2. The screenshots, i.e., graphs in Figure 5-2, are taken from the daemon interface, since this emphasizes the bi-directional functionality most clearly. The communication between all daemons goes clockwise, starting in the upper left corner. The interior node, located between edge1 and edge2 is not shown, since it is operating exactly the same as in the original RMD implementation [Jaco01]. The top of each sub screen lists the flows that are successfully registered in the daemon. The middle part shows the events as they arrive in the daemon. In the bottom part commands can be entered, e.g. to add or delete flows or quit the daemon. The ingress daemon at edge1 receives a SEP message on which a new flow is initiated. The IP address, port, protocol and the SEP parameters for the flow are listed:

76

New flow: saddr=195.169.97.179 sport=5000 ipproto=17 r=12000 b=7500 M=1500 The r, b and M parameters are token bucket specifiers, that are mapped into units for the RMD domain. The parameters for the reverse reservation are not printed in this screen, but are send with the message towards the destination. The egress daemon on edge2 receives a new reservation request, which is bi-directional reservation request as shown in the event window: New flow: saddr=195.169.97.179 sport=5000 ipproto=17 bi-directional reserve The ingress daemon at edge2 receives a message from the egress daemon and it initiates a new reservation in the opposite direction with the corresponding IP source address and port. The TTL value is copied from the forward message and is also printed on the screen: message from egress on rmdsock: reservation on rmdsock New flow: bi-directional: saddr=195.169.97.215 sport=6000 ipproto=17 ttl=60 daddr=195.169.97.179 dport=5000 rev_units=24 The egress at edge1 receives the message and notifies the ingress daemon. New flow: saddr=195.169.97.215 sport=6000 ipproto=17 Now the reservation for both the forward and reverse directions is completed and the flows are listed in the upper part of the screens. The number of units reserved is different for the two directions as can be seen from the r=12000 (for forward reservations) and r=24000 (for reverse reservations) values listed in the active flows part of the window. Several functionality experiments, similar to this one have been accomplished. All these functionality experiments showed that the operation of the bi-directional reservation feature, during a successful reservation, operates satisfactorily.

saddr=195.169.97.179 sport=5000 r=12000.0 b=7500.0 M=1500 XxxxxxxxxxxxxxxxxxxxxxxxxxIngress Functionality eth1=0xxxxxxxxxxxxxxxxxxxxxxxxxxx New flow: saddr=195.169.97.179 sport=5000 ipproto=17 r=12000 b=7500 M=1500 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx >

saddr=195.169.97.215 sport=6000 r=24000.0 b=7500.0 M=1500 xxxxxxxxxxxxxxxxxxxxxxxxxxxEgress Functionality eth0=0xxxxxxxxxxxxxxxxxxxxxxxxxx New flow: saddr=195.169.97.215 sport=6000 ipproto=17 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx >

saddr=195.169.97.215 sport=6000 r=24000.0 b=7500.0 M=1500 xxxxxxxxxxxxxxxxxxxxxxxxxxIngress Functionality eth1=0xxxxxxxxxxxxxxxxxxxxxxxxxx message from egress on rmdsock: reservation on rmdsock New flow: bi-directional: saddr=195.169.97.215 sport=6000 ipproto=17 ttl=60 daddr=195.169.97.179 dport=5000 rev_units=24 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx >

saddr=195.169.97.179 sport=5000 r=12000.0 b=7500.0 M=1500 xxxxxxxxxxxxxxxxxxxxxxxxxxEgress Functionality eth0=0xxxxxxxxxxxxxxxxxxxxxxxxxx New flow: saddr=195.169.97.179 sport=5000 ipproto=17 bi-directional reserve xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx >

Edge1 Edge2

Figure 5-2: screenshots showing a successful bi-directional reservation

77

5.1.3 Unsuccessful Reservation functionality experiments This section describes the functionality experiments used to verify the operation of the bi-directional reservation during an unsuccessful reservation. In this experiment another bi-directional reservation is made in addition to an already existing reservation that is accomplished as explained in Section 5.1.2. The requested resources for the reverse flow where set to be higher than the allowed maximum of 60 units. The interior node marks the reverse flow, after which both the forward and reverse flows are deleted up to the interior node that marked the reservation. In Figure 5-3 again screenshots of all ingress and egress daemons at both edge1 and edge2 are shown. The forward reservation for the second flow is identical to the successful reservation experiment. The egress daemon on edge1 is the first to detect the marked reservation. The following line is then printed: Message marked! Send reply back The ingress daemon matches the reply it received from the egress with the bi-directional reservation: Got marked reservation report message - sharedp=100 find rev_flowspec: saddr: 195.169.97.179 sport: 5001 protocol: 17 found matching reverse flowspec Then it sends a bi-directional release message towards the destination end host with the ttl set to the correct value for the partial release procedure: Rejected flow (internal router marked packet): saddr=195.169.97.179 sport=5001 ipproto=17 ttl=3 Releasing flow on interface eth1 - ttl 3 The egress daemon on edge2 deletes the flow and notifies the ingress running on the same node: Delete flow: saddr=195.169.97.179 sport=5001 ipproto=17 bi-directional release The ingress daemon on edge2 releases the flow and also prints the ttl value. In this case the ttl value equals one and thus the interior functionality on only one node will process the release. message from egress on rmdsock: Release flow: saddr=195.169.97.215 sport=6001 ipproto=17 ttl=1 There is still room for 48 units in the forward direction and 36 units in the reverse direction. If a new bi-directional reservation stays below those values, it can be accepted. Note that only the procedure of marking the reverse flow of a bi-directional reservation is shown in this example. However, after additional experiments it has been observed that the procedure of marking the forward flow of a bi-directional reservation works satisfactorily. Several functionality experiments, similar to this one have been accomplished. All these functionality experiments showed that the operation of the bi-directional reservation feature, during an unsuccessful reservation, operates satisfactorily.

78

saddr=195.169.97.179 sport=5000 r=12000.0 b=7500.0 M=1500 xxxxxxxxxxxxxxxxxxxxxxxxxxIngress Functionality eth1=0xxxxxxxxxxxxxxxxxxxxxxxxxx New flow: saddr=195.169.97.179 sport=5000 ipproto=17 r=12000 b=7500 M=1500 New flow: saddr=195.169.97.179 sport=5001 ipproto=17 r=12000 b=7500 M=1500 Got marked reservation report message - sharedp=100 find rev_flowspec: saddr: 195.169.97.179 sport: 5001 protocol: 17 found matching reverse flowspec Rejected flow (internal router marked packet): saddr=195.169.97.179 sport=5001 ipproto=17 ttl=3 Releasing flow on interface eth1 - ttl 3 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx >

saddr=195.169.97.215 sport=6000 r=24000.0 b=7500.0 M=1500 xxxxxxxxxxxxxxxxxxxxxxxxxxxEgress Functionality eth0=0xxxxxxxxxxxxxxxxxxxxxxxxxx New flow: saddr=195.169.97.215 sport=6000 ipproto=17 Message marked! Send reply back xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx >

saddr=195.169.97.215 sport=6000 r=24000.0 b=7500.0 M=1500 xxxxxxxxxxxxxxxxxxxxxxxxxxIngress Functionality eth1=0xxxxxxxxxxxxxxxxxxxxxxxxxx message from egress on rmdsock: reservation on rmdsock New flow: bi-directional: saddr=195.169.97.215 sport=6000 ipproto=17 ttl=60 daddr=195.169.97.179 dport=5000 rev_units=24 message from egress on rmdsock: reservation on rmdsock New flow: bi-directional: saddr=195.169.97.215 sport=6001 ipproto=17 ttl=60 daddr=195.169.97.179 dport=5001 rev_units=40 message from egress on rmdsock: Release flow: saddr=195.169.97.215 sport=6001 ipproto=17 ttl=1 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx >

saddr=195.169.97.179 sport=5000 r=12000.0 b=7500.0 M=1500 xxxxxxxxxxxxxxxxxxxxxxxxxxxEgress Functionality eth0=0xxxxxxxxxxxxxxxxxxxxxxxxxx New flow: saddr=195.169.97.179 sport=5000 ipproto=17 bi-directional reserve New flow: saddr=195.169.97.179 sport=5001 ipproto=17 bi-directional reserve Delete flow: saddr=195.169.97.179 sport=5001 ipproto=17 bi-directional release xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx >

Edge1 Edge2

Figure 5-3: screenshots showing an unsuccessful bi-directional reservation

5.2 RSVPv2-IPv6 experiments

5.2.1 Network setup This section describes the setup of the network as used in the RSVPv2-IPv6 experiments. It is based on the setup used in the bi-directional experiments. It is actually the same setup as the one used during the bi-directional reservation experiments. However, a different configuration was necessary to support the IPv6 protocol in the linux environment as described in section 5.2.1.1. The logical network structure consisting of RSVP routers and the RMD Diffserv domain, is given in Figure 5-4. The Server and Client nodes use RSVP for QoS, the interior node uses RMD/RSVP and the two edge nodes are the interfaces between the RSVP only part of the network and the RMD domain. All nodes in the network, except the interior node, are running the RMD/RSVP prototype implementation running on a Linux 2.4.19 kernel. The interior node uses the PHR functionality, implemented in a kernel module. The hardware is all PC based and the links between nodes are 100 Mbps Ethernet connections. Of this bandwidth 1 Mbps was reserved for best effort traffic and 480 kbps for the EF traffic class. As one unit was defined as 1 kbps this equals 60 units.

79

Edge1 Client1 Client2

RMD domain RSVP RSVP

Edge2 Interior

Figure 5-4: RMD network configuration for RSVPv2-IPv6 experiments

There are two types of experiments performed. The first type of experiments are functionality experiments that are used to verify the functionality behavior of the RSVPv2-IPv6 protocol during successful and unsuccesful reservations. This is described in section 5.2.2 for successful reservations and Section 5.2.3 for unsuccessful reservations. The second type of experiments are performance experiments that are used to observe the performance behavior of the interior nodes. These performance experiments are described Section 5.2.4.

5.2.1.1 IPv6 numbering plan In the Ericsson lab there was no network configuration for IPv6. Thus, first an IPv6 numbering plan had to be defined. See Figure 5-5 for the hierarchical structure of the IPv6 network used in the experiments.

4000

adam

client2anya clientbuffy

dawnwillow gi les dns

tunn

el tunnel

hub4800

C000

2000

2800

2800280

0 2800

A00080

00

surfnet

internet

wmrtb.net

Server

tunn

el

4880

4000

adam

client2anya clientbuffy

dawnwillow gi les dns

tunn

el tunnel

hub4800

C000

2000

2800

2800280

0 2800

A00080

00

surfnet

internet

wmrtb.net

Server

tunn

el

4880

Figure 5-5: Hierarchical structure of an IPv6 network

A global address range with a prefix length of 48 bits was assigned from the Internet Service Provider (ISP). The address range is 2001:0610:1918::/48, which leaves 16 bits to define subnets and 64 bits for every host. See Table 5-1 for the subnets as they have been specified. All routers needed to be configured statically, but end hosts use auto configuration. This has been accomplished by using a routing advertisement daemon (See [Radvd]). As an extra complication the network was connected to the Internet

80

through an IPv4 only router, i.e., (adam). Therefore a tunnel was set up from the ISP, surfnet, to the first router behind the IPv4 router (adam). Also the connection to the fileserver (giles) and the DNS have to be tunnelled to provide them with IPv6 connectivity. For completeness, this is indicated in Figure 5-5, but this has not been done as these hosts are not needed for the prototype implementation and are still connected through IPv4. Names are not resolved by the DNS server although it is possible to query for IPv6 addresses over IPv4. A hosts file on all computers is used instead, as this has the further benefit that it reduces traffic and makes it easier to dump the contents of packets that are of interest. All other connections are through native IPv6.

Wmrtb.net v6 prefix Hex suffix Binary suffix Hostnames 2001:0610:1918::/48 A000 1010 0000 0000 0000 dns/adam 8000 1000 0000 0000 0000 giles/adam 4000 0100 0000 0000 0000 willow/adam C000 1100 0000 0000 0000 willow/adam 2000 0010 0000 0000 0000 dawn/adam 4800 0100 1000 0000 0000 buffy/willow 2800 0010 1000 0000 0000 dawn/client/client2/anya 4880 0100 1000 1000 0000 server/buffy

Table 5-1: IPv6 number plan

5.2.2 Successful Reservation functionality experiments This section describes the functionality experiments used to verify the operation of the RSVPv2-IPv6 protocol during a successful reservation. In this experiment, the server node sends several RSVP PATH messages towards the receiver end host. The receiver always sends a RSVP RESV message back, following the traffic characteristics as specified in the PATH message. The experiment was done for both IPv4 and IPv6 flows, with the same outcome, as expected. The right side of the screen of the graphs in Figure 5-6, Figure 5-7 and Figure 5-8, display the current reservations. The horizontal axis represents time and the vertical as represents either the number of flows for Figure 5-6 and Figure 5-8 or bandwidth in kb/s for Figure 5-7. The display refreshes at fixed intervals and the old reservation information shifts to the left. The bottom half shows some additional information, like the source IP address, source port number and the number of reserved units, about the current reservations. The PATH messages are sent using the ISI RSVP daemon [ISI-RSVP], by using the Real Time Application Program (RTAP) interface. The RESV replies from the receiver are generated by the RMD/RSVP daemon in a RSVP_LOOP role as described in Section 4.3.8. The reservations in the RMD domain are given in Figure 5-6, Figure 5-7 and Figure 5-8 for ingress, interior and egress functionality respectively. The screenshots where taken from the java based viewer that was already implemented for the first RMD prototype. In the left pane can be chosen which functionality should be displayed by selecting PHR, ingress or egress. In both edges the number of flows is displayed in the graph as well as for every flow the source IP address, the source port and the number of units reserved. As can be seen from the screenshot the experiment was a reservation for an IPv6 flow. The number of flows as displayed in both edges is not proportional to the number of units that is reserved. The interior node displays the units reserved in kb/s per interface.

81

Figure 5-6: screenshot showing successful reservations for the ingress functionality

Figure 5-7: screenshot showing successful reservations for the interior functionality

Figure 5-8: screenshot showing successful reservations for the egress functionality

Both edges correctly show the same information for all flows. First three reservations where made after each other for 10, 30 and 5 units from ports 5000 to 5002. Then the reservation for 30 units from port 5001 was released and two more reservations for 15 and 10 units where done, using port number 5003 and 5004. Figure 5-7 shows the interior node has reserved for the correct number of units (i.e., kb/s) according

82

to the reservations on interface eth0, which is the outgoing interface towards the receiver. For the opposite direction, also a reservation was made on interface eth1 as can be seen from the same figure. Similar graphs can be obtained for this case. Several functionality experiments, similar to this one have been accomplished. All these functionality experiments showed that the operation of the RSVPv2-IPv6 protocol, during a successful reservation, operates satisfactorily.

5.2.3 Unsuccessful Reservation experiments This section describes the functionality experiments used to verify the operation of the RSVPv2-IPv6 protocol during an unsuccessful reservation. In these experiments it is considered that a successful reservation of 40 requested units, similar to the one described in Section 5.2.2, has been performed. The behavior of the prototype in the case of unsuccessful reservations was verified for both IPv4 and IPv6, but as in section 5.2.2 only the results for IPv6 are shown. The maximum number of resource units that could be reserved in the EF traffic class, was set to 60, but this can be different for different interior nodes. The interior node display does not change as a new reservation for 40 units is attempted. The ingress edge1 shows the reservation with 40 units as it is reserved for, because it always shows reservations coming into the domain. The ingress functionality at edge1 does not know how many interior interfaces there are and how many resources are available. The interior functionality at the ingress edge1 marks the flow, because the sum of the number of requested resources and the number of the existing reserved resources is higher than the maximum number of available resources. This is shown in Figure 5-9 where the flow at the egress edge is listed with zero reserved units, to indicate that it is marked. After the next refresh of the state procedure, which is accomplished by the RMD/RSVP daemon, this flow is no longer shown.

Figure 5-9: screenshot showing unsuccessful reservations for the egress functionality

Several functionality experiments, similar to this one have been accomplished. All these functionality experiments showed that the operation of the RSVPv2-IPv6 protocol, during an unsuccessful reservation, operates satisfactorily.

5.2.4 Performance experiments As explained in Chapter 4, the RSVPv2-IPv6 implementation of the interior node is, except few minor modifications, identical to the original RMD implementation of the interior node. Therefore, it can be deduceed that the performance of an interior node implementation used in these two prototype implementations will be equal. Note that even when the RSVPv2 protocol is used, the interior node processes only the RMD information (i.e., RMD object). The RSVPv1 objects are not processed. The performance of the interior node in the original RMD implementation has been studied and presented in [Goer03]. Below we list some of the conclusions drawn in [Goer03]. Note that one of the goals of the work presented in [Goer03] was to compare the performance of a node used in RSVPv1 (as an RSVPv1 aware router) and the performance of a node used in RMD (as an interior node). “ In general, it can be concluded that the processing times of the PHR messages are very much smaller than the processing times of the RSVP messages. In particular, in an unloaded scenario the mean

83

processing time of a PHR_Resource_Request is a factor 327 smaller than the mean processing time of a RESV message. The PHR_Resource_Release is a factor 350 smaller than the RESVTEAR. Moreover, for RSVP reservations and releases, every node in the path also has to process a PATH message. When these message processing times are also accounted for, the mean processing time of a PHR reservation is a factor 466 smaller than the processing of an RSVPv1 reservation. Similar the mean processing time of a PHR release is now a factor 430 smaller than the mean processing time of a RSVP release. In a loaded scenario, i.e., when also user traffic is involved, the processing time of the RSVP messages increases when the QoS traffic is increased. In the same scenario the processing time of the PHR messages do not increase significantly when the QoS traffic is increased. The implemented policing feature used in the RMD protocol operates satisfactorily, since the measured link utilization is following and is approximating the reserved target link utilization.” , from [Goer03].

5.2.5 Demonstration Several demonstration scenarios have been realized to demonstrate the features of the RSVPv2 implementation. The demonstrations could be actually performed for both IPv4 and IPv6 versions of RSVPv2. The network setup used in these demonstrations is shown in Figure 5-4. Server and Client are both end nodes outside the RMD domain. Some of these demonstration scenarios were already described and demonstrated with screenshots in section 5.2.2 and section 5.2.3. The steps that are followed:

• Send a RSVP PATH message from Server to Client using the ISI-RSVP RTAP interface. The Client uses the same interface to send back a RSVP RESV message. This shows that the RMD/RSVP implementation is compatible with the standard ISI-RSVP daemon. Note that because the ISI-RSVP daemon as currently implemented in the linux environment does not support IPv6 for sending RESV messages, the automatic RESV functionality of the RMD/RSVP (RSVPv2) daemon (RSVP_LOOP) is used in case that IPv6 is used.

• While a reservation from Server to Client exists, send a RSVP PATH message from Client to Server using the ISI-RSVP RTAP interface. The Server node responds with a RSVP RESV message. This shows the ingress and egress functionality of the RMD/RSVP daemon works simultaneously.

• Initiate many reservations at the same time by using the Flow generator (see [Jaco01]) to send RSVP PATH messages from Server to Client. At Client the automatic RESV functionality is used to terminate the flows and send back RSVP RESV messages. At the same time do the same for the other direction. This shows the RMD/RSVP daemon can handle many reservations at the same time in all directions.

• Use the Robust Audio Tool (RAT) [BeCa98] audio application to generate traffic with real-time requirements. Also send other traffic that competes with the available bandwidth. The other traffic will be best effort traffic, as no reservation exists for it. The ingress functionality only maps traffic originating from the reserved host and port to the EF traffic class. The other traffic can be generated using Mgen [MGEN] or by using the ‘ping –f’ command. RAT has to be set up not to compensate for degraded network performance and to directly show when requested bandwidth is not available. Then a reservation is made for the audio traffic generated by RAT, the correct port numbers have to be selected.

84

•

85

6 Conclusions and future work This thesis is enhancing the RMD scheme prototype implementation presented in [Jaco01] and [WeOo02], by designing and implementing the protocol features that are currently not implemented and are needed with respect to the fulfillment of the IP-based UTRAN requirements. Furthermore, this has been accomplished by integrating the RSVP and RMD protocols, focusing on its IPv6 design and implementation.

6.1 Conclusions This thesis introduced existing IP based resource management schemes, such as the RSVP and RMD protocols. The original version of the RMD prototype implementation presented in [Jaco01] does not include the implementation of the bi-directional feature that is needed with respect to the fulfillment of the IP-based UTRAN bi-directional requirement. In the UTRAN, the RNC can initiate and manage the resource reservations for both directions, to and from the base station, at the same time. One of the main goals of this thesis is to enhance the original RMD prototype implementation by adding the design and implementation of the bi-directional feature. The implementation of this feature is accomplished on software using the Linux operating system, the Python and the C and C++ programming languages. Compared to the original RMD implementation, the implementation of the interior functionality is not modified. However, the implementation of the edge functionality had to be modified. The main modifications are related to the fact that the edge nodes have to distinguish a uni-directional reservation from a bi-directional reservation. Furthermore, the edge nodes have to initiate and maintain a bi-directional reservation. These requirements are fulfilled when each ingress and egress edge node combines for each bi-directional reservation the ingress and egress functionalities. The correctness of the implementation has been verified by using functionality experiments for the operation of the bi-directional feature during successful and unsuccessful reservations. The prototype implementation of the bi-directional feature shows that the implementation of the bi-directional feature in the Linux environment is feasible. Another main goal of this thesis is to study, design and implement the integration of the RMD and RSVP protocols, focusing on the IPv6 specification. Existing designs and implementations of the RMD and RSVP protocols have been studied, such as the original RMD implementation [Jaco01], the ISI RSVP implementation [ISI-RSVP] and the design steps of the RSVP and RMD integration that focuses on the IPv4 specification [Shi02]. Both IPv4 and IPv6 versions of the RMD and RSVP protocol integration are implemented using the Linux operating system, the Python and the C and C++ programming languages. However more focus has been given to the IPv6 version of this implementation. The RMD and RSVP protocol integration is denoted in this thesis as RSVPv2, while the RMD and RSVP protocol integration that is based on the IPv6 specification is denoted in this thesis as RSVPv2-IPv6. A main difference between RSVPv1 and RSVPv2 is that the RSVPv2 protocol is sender initiated instead of the receiver initiated RSVPv1. Furthermore, it is considered that a RSVP PATH message includes information that can be used to generate the resource units required by the RMD protocol. The main differences between the original RMD implementation and the RSVPv2 implementation are the following:

• The functionality required at the edges for the support of the SEP protocol is replaced by functionality that is required to support the RSVPv1 functionality. In particular, the edge node implementation contains in the Ingress/Egress daemons, i.e., in the RSVPv2 daemon, the reduced ISI RSVPv1 daemon functionality for processing and routing of the RSVPv1 signaling messages.

• The same RSVPv2 daemon can be used on the ingress and egress nodes. The RSVPv2 daemon functionality is mirrored, i.e. it does not matter from what side the reservation originates. As opposed to the original implementation of RMD, now all processing of signaling messages on the edges is done in the RSVPv2 daemon, i.e., in the user space.

• The structure in which the RSVPv2 implementation components are placed is the same for both IPv4 and IPv6 versions. The RSVPv2 daemon can be configured off line to generalize the version of IP (i.e., IPv4 or IPv6) used in the applied objects. In the original version of the RMD prototype this is not possible.

• The edge nodes using the Divert sockets intercept the RSVPv1 messages arriving from outside the RMD and the RSVPv2 messages arriving from inside the RMD domain. In the original RMD implementation the SEP packets are intercepted using the router alert option. Packets that

86

contain the router alert option are sent to the user space daemon that registered a socket with the router alert option.

• In RSVPv2 the ingress functionality is implemented on the input interface of the ingress node, while in the original RMD implementation the ingress functionality is implemented on the output interface of the ingress node.

• In RSVPv2 the RMD information is included into the payload of the IP packet, while in the original RMD implementation the RMD information is included into an IP Option. One main advantage of introducing the RMD information into the IP payload, is that the size of the RMD information does not have strict limitations. Another advantage is that its design is independent of the used IP version. The main disadvantage is related to the delay that might be imposed to an interior node when reading the RMD information from the IP payload. In the RSVPv2 implementation the RMD information is included into a RSVP object, that is located in sequence after all the RSVPv1 objects. In this way the impact of this disadvantage is minimized.

Major implementation work was needed during the realization of the ingress and egress nodes. However, minor modifications were needed for the implementation of the interior node. The modifications needed on the interior node where limited to the locating of the PHR information in the messages. The further implementation of the interior node has been kept exactly the same. The main differences between the IPv4 and IPv6 version based RSVPv2 implementations are the folllowing:

• the rsvp filter component used in the implementation of the ingress and egress functionalities in the IPv4 version of RSVPv2 is different from the same component used in the implementation of the ingress and egress functionalities in the IPv6 version of RSVPv2. However, all the other components used in the implementation of the ingress and egress functionalities are the same for both versions, i.e., IPv4 and IPv6.

• the get_PHR function used in the implementation of the interior functionality in the IPv4 version of RSVPv2 is different then the same component that is used in the implementation of the interior functionality in the IPv6 version of RSVPv2. However, all the other components used in the implementation of the interior functionality are the same for both versions, i.e., IPv4 and IPv6.

• the RSVPv2 (i.e., RMD/RSVP) daemon used in the design of the ingress and egress nodes in the IPv4 version of RSVPv2 is different then the same component that is used in the design of the ingress and egress nodes in the IPv6 version of RSVPv2. However, the implementation of the RSVPv2 daemon is accomplished in such a way that the objects used in the daemon can be used for both IP versions, i.e., IPv4 and IPv6.

The correctness of the implementation has been verified by using functionality experiments for the operation of the RSVPv2-IPv6 protocol during successful and unsuccessful reservations. The prototype implementation of the RSVPv2-IPv6 protocol shows that the implementation of this protocol in the Linux environment is feasible. Compared to the original RMD implementation, minor modifications were needed for the implementation of the interior node. It can therefore, be deduced that the performance of the interior node in terms of RMD processing delay is similar to the performance achieved by using the original RMD implementation.

6.2 Future Work As described in previous chapters, due to time constraints the realization of several design and implementation issues could not be completed. Therefore, it is recommended to complete these issues in the near future. The first issue is related to the implementation of the interior (i.e., PHR) functionality into the egress node. The second issue is related to the implementation of the severe congestion with proportional marking feature as part of the RSVPv2 protocol. The third issue is related to the design and implementation of the bi-directional feature as part of the RSVPv2 protocol. Furthermore, more extensive performance experiments are needed to verify the performance behavior of the edge nodes. Also more performance experiments are also needed to verify the performance behavior of RMD and RSVPv2 in the context of the IP based UTRAN. A method has to be specified such that the resource reservation mechanism used in the IP based UTRAN could interoperate with the resource reservation mechanism used in the ATM based UTRAN.

87

This means that a method has to be specified such that RMD and RSVPv2 protocols could interoperate with the Q2630 [ITU-Q2630] protocol that is used for resource reservation in the ATM based UTRAN. There are still open issues with RMD and RSVPv2 in general, such as extending the RMD applicability in multi-domains. Moreover, work has to be done on introducing the RMD concept into the NSIS (Next Steps in Signaling) protocol (see [NSIS]).

88

89

References

[3GGP] 3rd Generation Partnership Project, http://www.3gpp.org

[3GPP-25401] 3rd Generation Partnership Project, UTRAN Overall Description, TS 25.401, January 2001.

[3GPP-25933] 3rd Generation Partnership Project, IP transport in UTRAN, TR 25.933

[AlSa99] Almesberger, W., Salim, J.H., Kuznetsov A., Differentiated Services on Linux, Internet Draft draft-almesberger-wajhak-diffserv-linux-01.txt, June 1999.

[Bald03] Divert Sockets for Linux, http://sourceforge.net/projects/ipdivert.

[BeCa98] Bennett, R., Clark, L., Hasler, K., User Guide for RAT v4.2, http://www-mice.cs.ucl.ac.uk/multimedia/software/rat/, 1998

[BeCs00] Bergkvist, J., Cselényi, I., Ahlard, D., Boomerang – A simple Resource Reservation Framework for IP, Internet Draft, draft-bergkvist-boomerang-framework-01.txt, Work in Progress, November 2000.

[ChLe99] Chow, H., Leon-Garcia, A., A Feedback Control Extension to Differentiated Services, Internet Draft, draft-chow-diffserv-fbctrl-01.txt, Work in Progress, March 1999.

[DhSu99] Dhandapani, G., Sundaresan, A., Netlink Sockets - Overview, http://qos.ittc.ukans.edu/netlink/html/index.html, September 1999.

[Goer03] Goering, P., Performance comparison of Resource Management in Diffserv (RMD) and Resource Reservation Protocol (RSVP), Practical Training, Electrical Engineering, University of Twente, 2003.

[IMQ] The Intermediate Queuing Device, http://trash.net/~kaber/imq/.

[ISI-RSVP] RSVP implementation by USC Information Sciences Institute, http://www.isi.edu/rsvp.

[ITU-Q2630] ITU-T recommendation, Q.2630.2 Capability Set 2 - Connection Modification and Connection Redirection, 3/159 41-5/FCP103 3834

[Jaco01] Jacobsson, M., Resource Management in Differentiated Services – A Prototype Implementation, M.Sc. Thesis, Computer Science/TSS, University of Twente, June 2001.

[KaRe02] Karagiannis, G., Rexhepi, V., Jacobsson, M., Oosthoek, S., Westberg, L., de Kogel, M., Second phase solutions for the basic features Considered in the design of the Resource Management in Diffserv (RMD) scheme, Internal ericsson document, version PA7.

90

[Linux] The Linux Documentation Project, http://www.tldp.org.

[MGEN] MGEN User Guide, http://manimac.itd.nrl.navy.mil/MGEN/MgenUserGuide.html.

[NSIS] IETF NSIS Working Group, http://www.ietf.org/html.charters/nsis-charter.html

[PaKa02] Partain, D., Karagiannis, G., Westberg, L., Resource Reservation Issues in Cellular Access Networks, Internet Draft, Work in progress.

[PaSc98] Pan, P., Schulzrinne, H., YESSIR: A Simple Reservation Mechanism for the Internet, Proceedings NOSSDAV'98, 1998.

[Python] Python language website, http://www.python.org.

[Radh99] Radhakrishnan, S., Linux - Advanced Networking Overview Version 1, http://qos.ittc.ukans.edu/howto/index.html, August 1999.

[Radvd] Linux IPv6 Router Advertisement Daemon, http://v6web.litech.org/radvd/.

[ReKa02] Rexhepi, V., Karagiannis, G., de Kogel, M., Stienstra, A., Shi, N., Protocol design of RSVP/RMD integration (RSVPv2) scheme, internal ericsson (ELN) document 2002

[Rexh00] Rexhepi, V., Interoperability of Integrated Services and Differentiated Services Architectures, located at http://www.ub.utwente.nl/webdocs/ctit/1/00000040.pdf, October 2000.

[RFC768] Postel, J., User Datagram Protocol, IETF RFC 768, August 1980.

[RFC791] Postel, J., Internet Protocol, IETF RFC 791, September 1981.

[RFC1633] Braden, R., Clark, D., Shenker, S., Integrated Services in the Internet Architecture: an Overview, IETF RFC 1633, June 1994.

[RFC2113] Katz, D., IP Router Alert Option, IETF RFC 2113, February 1997.

[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S., Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification, IETF RFC 2205, September 1997.

[RFC2209] Braden, R., Zhang, L., Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules, IETF RFC 2209, September 1997.

[RFC2210] Wroclawski, J., The Use of RSVP with IETF Integrated Services, IETF RFC 2210, September 1997.

[RFC2401] Kent, S., Atkinson, R., Security Architecture for the Internet Protocol, IETF RFC 2401, November 1998.

91

[RFC2411] Thayer, R., Doraswamy, N., Glenn, R., IP Security Document Roadmap, IETF RFC 2411, November 1998.

[RFC2460] Deering, S., Hinden, R., Internet Protocol, Version 6 (IPv6) Specification, IETF RFC 2460, December 1998.

[RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, RFC 2474, December 1998.

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., Wiess, W., An Architecture for Differentiated Services, IETF RFC 2475, December 1998.

[RFC2597] Heinanen, J., Baker, F., Weiss, W., Wroclawski, J., Assured Forwarding PHB Group, IETF RFC 2597, June 1999.

[RFC2598] Jacobson, V., Nichols, K., Poduri, K., An Expedited Forwarding PHB, IETF RFC 2598, June 1999.

[RFC2638] Nichols, K., Jacobson, V., Zhang, L., A Two-bit Differentiated Services Architecture for the Internet, IETF RFC 2638, July 1999.

[RFC3175] Baker, F., Iturralde, C. Le Faucher, F., Davie, B., Aggregation of RSVP for IPv4 and IPv6 Reservations, IETF RFC, 2001.

[Shi02] Shi, N., Resource Management in Diffserv (RMD) and Resource Reservation Protocol (RSVP) Integration: A Prototype Implementation, M.Sc. Thesis, Electrical Engineering/TVS, Delft University of Technology, July 2002.

[StZh99] Stoica, I., Zhang, H., Venkitaraman, N., Mysore, J., Per Hop Behaviours Based on Dynamic Packet States, Internet Draft draft-stoica-diffserv-dps-02.txt, Work in Progress, October 2002.

[TC-HOWTO] Linux Advanced Routing & Traffic Control howto, http://www.lartc.org/howto.

[TC-MAN] Linux Advanced Routing & Traffic Control manual pages, http://www.lartc.org/manpages.

[WeCs02] Westberg, L., Császár, A., Karagiannis, G., Marquetant, A., Partain, D., Pop, O., Rexhepi, V., Szabó, R., Takács, A., Resource Management in Diffserv (RMD): A Functionality and Performance Behavior Overview, Seventh International Workshop on Protocols for High-Speed networks - PfHSN 2002, 22 - 24 April 2002.

[WeJa03a] Westberg, L., Jacobsson, M., Karagiannis, G., Oosthoek, S., Partain, D., Rexhepi, V., Szabo, R., Wallentin, P, Resource Management in Diffserv (RMD) Framework, draft-westberg-rmd-framework-03.txt, IETF Internet draft, work in progress.

92

[WeJa03b] Westberg, L., Karagiannis, G., Partain, D., Oosthoek, S., Jacobsson, M., de Kogel, M., Rexhepi, V., Resource Management in Diffserv On DemAnd (RODA) PHR, draft-westberg-rmd-od-phr-03.txt, IETF Internet draft, work in progress.

[WeHe02] Westberg, L., Heijenk, G., Karagiannis, G., Oosthoek, S., Partain, D., Rexhepi, V., Szabo, R., Wallentin, P., Hamad el Allali, Resource Management in Diffserv Measurement-based Admission Control PHR, draft-westberg-rmd-mbac-phr-00.txt, IETF Internet draft, work in progress.

[WeOo02] Jacobsson, M., Oosthoek, S., Karagiannis, G., Resource Management in Differentiated Services: A Prototype Implementation, Seventh IEEE Symposium on Computers and Communications, 01-04 July 2002.

[WhCr98] White, P.P., Crowcroft, J., A Dynamic Sender-Initiated Reservation Protocol for the Internet, Proceedings of HPN’98, 1998.

[ZhDe93] Zhang, L., Deering, S., Estrin, D., Shenker, S., Zappala, D., RSVP: A New Resrource ReSerVation Protocol, IEEE Network, September 1993.

93

Appendix A: RSVP Objects based on IPv4 and IPv6 This appendix describes the RSVPv1 objects based on the IPv4 and IPv6 versions. NULL A NULL object has a Class-Num of zero, and its C-Type is ignored. Its length must be at least 4 bytes, but can be any multiple of 4. A NULL object may appear anywhere in a sequence of objects, and its contents will be ignored by the receiver (see [RFC2205]). SESSION Contains the IP destination address (DestAddress), the IP protocol id, and some form of generalized destination port, to define a specific session for the other objects that follow (see [RFC2205]). It is required in every RSVP message. IPv4/UDP SESSION object: Class = 1, C-Type = 1

+-------------+-------------+-------------+-------------+ | IPv4 DestAddress (4 bytes) | +-------------+-------------+-------------+-------------+ | Protocol Id | Flags | DstPort | +-------------+-------------+-------------+-------------+

Figure A-1: Session object for RSVP based on IPv4

IPv6/UDP SESSION object: Class = 1, C-Type = 2

+-------------+-------------+-------------+-------------+ | | + + | | + IPv6 DestAddress (16 bytes) + | | + + | | +-------------+-------------+-------------+-------------+ | Protocol Id | Flags | DstPort | +-------------+-------------+-------------+-------------+

Figure A-2: Session object for RSVP based on IPv6

RSVP_HOP Carries the IP address of the RSVP-capable node that sends this message and a logical outgoing interface handle (LIH; see Section 3.3). This document refers to a RSVP_HOP object as a PHOP ("previous hop") object for downstream messages or as a NHOP (" next hop") object for upstream messages (see [RFC2205]). IPv4 RSVP_HOP object: Class = 3, C-Type = 1

+-------------+-------------+-------------+-------------+ | IPv4 Next/Previous Hop Address (4 bytes) | +-------------+-------------+-------------+-------------+ | Logical Interface Handle | +-------------+-------------+-------------+-------------+

Figure A-3: RSVP_HOP object for RSVP based on IPv4

94

IPv6 RSVP_HOP object: Class = 3, C-Type = 2

+-------------+-------------+-------------+-------------+ | | + + | | + IPv6 Next/Previous Hop Address (16 bytes) + | | + + | | +-------------+-------------+-------------+-------------+ | Logical Interface Handle | +-------------+-------------+-------------+-------------+

Figure A-4: RSVP HOP object for RSVP based on IPv6

TIME_VALUES Contains the value for the refresh period R used by the creator of the message. Required in every PATH and RESV message. Defines the reservation style plus style-specific information that is not in FLOWSPEC or FILTER_SPEC objects (see [RFC2205]). Required in every RESV message. TIME_VALUES Object: Class = 5, C-Type = 1

+-------------+-------------+-------------+-------------+ | Refresh Period R | +-------------+-------------+-------------+-------------+

Figure A-5: TIME_VALUES object for RSVP based on IPv4 or IPv6

STYLE Defines the reservation style plus style-specific information that is not in FLOWSPEC or FILTER_SPEC objects (see [RFC2205]). It is required in every RESV message. STYLE object: Class = 8, C-Type = 1

+-------------+-------------+-------------+-------------+ | Flags | Option Vector | +-------------+-------------+-------------+-------------+

Figure A-6: STYLE object for RSVP based on IPv4 or IPv6

FLOWSPEC Defines a desired QoS, in a RESV message (see [RFC2210]). The FLOWSPEC class is equal to 9. There are two types of FLOWSPEC objects:

• Reserved (obsolete) flowspec object: Class = 9, C-Type = 1 • Inv-serv Flowspec object: Class = 9, C-Type = 2

95

31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a) | reserved | 7 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 5 (c) |0| reserved | 6 (d) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 127 (e) | 0 (f) | 5 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(a) - Message format version number (0) (b) - Overall length (7 words not including header) (c) - Service header, service number 5 (Controlled-Load) (d) - Length of controlled-load data, 6 words not including per-service header (e) - Parameter ID, parameter 127 (Token Bucket TSpec) (f) - Parameter 127 flags (none set) (g) - Parameter 127 length, 5 words not including per-service header

Figure A-7: Controlled load FLOWSPEC object for RSVP based on IPv4 or IPv6

31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a) | Unused | 10 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 2 (c) |0| reserved | 9 (d) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 127 (e) | 0 (f) | 5 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | 130 (h) | 0 (i) | 2 (j) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 | Rate [R] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11 | Slack Term [S] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(a) - Message format version number (0) (b) - Overall length (9 words not including header) (c) - Service header, service number 2 (Guaranteed) (d) - Length of per-service data, 9 words not including per-service header (e) - Parameter ID, parameter 127 (Token Bucket TSpec) (f) - Parameter 127 flags (none set) (g) - Parameter 127 length, 5 words not including parameter header (h) - Parameter ID, parameter 130 (Guaranteed Service RSpec) (i) - Parameter 130 flags (none set) (j) - Parameter 130 length, 2 words not including parameter header

Figure A-8: Guaranteed service FLOWSPEC object for RSVP based on IPv4 or IPv6

96

FILTER_SPEC Defines a subset of session data packets that should receive the desired QoS (specified by a FLOWSPEC object), in an RESV message (see [RFC2205]).

IPv4 FILTER_SPEC object: Class = 10, C-Type = 1

+-------------+-------------+-------------+-------------+ | IPv4 SrcAddress (4 bytes) | +-------------+-------------+-------------+-------------+ | ////// | ////// | SrcPort | +-------------+-------------+-------------+-------------+

Figure A-0-9: FILTER_SPEC object for RSVP based on IPv4

IPv6 FILTER_SPEC object: Class = 10, C-Type = 2

+-------------+-------------+-------------+-------------+ | | + + | | + IPv6 SrcAddress (16 bytes) + | | + + | | +-------------+-------------+-------------+-------------+ | ////// | ////// | SrcPort | +-------------+-------------+-------------+-------------+

Figure A-0-10: FILTER_SPEC object for RSVP based on IPv6

IPv6 Flow-label FILTER_SPEC object: Class = 10, C-Type = 3

+-------------+-------------+-------------+-------------+ | | + + | | + IPv6 SrcAddress (16 bytes) + | | + + | | +-------------+-------------+-------------+-------------+ | /////// | Flow Label (24 bits) | +-------------+-------------+-------------+-------------+

Figure A-11: Flow-label FILTER_SPEC object for RSVP based on IPv6

97

SENDER_TEMPLATE Contains a sender IP address and perhaps some additional de-multiplexing information to identify a sender (see [RFC2205]). It is required in a Path message.

IPv4 SENDER_TEMPLATE object: Class = 11, C-Type = 1 Definition same as IPv4/UDP FILTER_SPEC object. IPv6 SENDER_TEMPLATE object: Class = 11, C-Type = 2 Definition same as IPv6/UDP FILTER_SPEC object. IPv6 Flow-label SENDER_TEMPLATE object: Class = 11, C-Type =3

Figure A-12: SENDER_TEMPLATE object for RSVP based on IPv6

SENDER_TSPEC Defines the traffic characteristics of a sender's data flow (see [RFC2210]). It is required in a PATH message. Intserv SENDER_TSPEC object: Class = 12, C-Type = 2

31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a) | reserved | 7 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 1 (c) |0| reserved | 6 (d) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 127 (e) | 0 (f) | 5 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(a) - Message format version number (0) (b) - Overall length (7 words not including header) (c) - Service header, service number 1 (default/global information) (d) - Length of service 1 data, 6 words not including header (e) - Parameter ID, parameter 127 (Token_Bucket_TSpec) (f) - Parameter 127 flags (none set) (g) - Parameter 127 length, 5 words not including header

Figure A-0-13: SENDER_TSPEC object for RSVP based on IPv4 or IPv6

98

ADSPEC Carries OPWA data, in a PATH message (see [RFC2210]). Intserv ADSPEC object: Class = 13, C-Type = 2

31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 (a) | reserved | Msg length - 1 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Default General Parameters fragment (Service 1) (c) | | (Always Present) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Guaranteed Service Fragment (Service 2) (d) | | (Present if application might use Guaranteed Service) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Controlled-Load Service Fragment (Service 5) (e) | | (Present if application might use Controlled-Load Service) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(a) - Message format version number (0) (b) - Overall message length not including header word (c, d, e) - Data fragments

Figure A-14: Basic ADSPEC object for RSVP based on IPv4 or IPv6

ERROR_SPEC Specifies an error in a PATHerr, RESVerr, or a confirmation in a RESVConf message (see [RFC2210]).

IPv4 ERROR_SPEC object: Class = 6, C-Type = 1

+-------------+-------------+-------------+-------------+ | IPv4 Error Node Address (4 bytes) | +-------------+-------------+-------------+-------------+ | Flags | Error Code | Error Value | +-------------+-------------+-------------+-------------+

Figure A-15: ERROR_SPEC object for RSVP based on IPv4

99

o IPv6 ERROR_SPEC object: Class = 6, C-Type = 2

+-------------+-------------+-------------+-------------+ | | + + | | + IPv6 Error Node Address (16 bytes) + | | + + | | +-------------+-------------+-------------+-------------+ | Flags | Error Code | Error Value | +-------------+-------------+-------------+-------------+

Figure A-16: ERROR_SPEC object for RSVP based on IPv6

POLICY_DATA Carries information that will allow a local policy module to decide whether an associated reservation is administratively permitted. May appear in PATH, RESV, PATHerr, or RESVerr message. The use of POLICY_DATA objects is not fully specified at this time; a future document will fill this gap. The POLICY_DATA object is identified by: Class = 14, C-Type = 1 The contents of this object are for further study. INTEGRITY Carries cryptographic data to authenticate the originating node and to verify the contents of this RSVP message. The use of the INTEGRITY object is described in [RFC2747]. SCOPE Carries an explicit list of sender hosts towards which the information in the message is to be forwarded. May appear in a RESV, RESVerr, or RESVtear message (see [RFC2205]).

IPv4 SCOPE List object: Class = 7, C-Type = 1

+-------------+-------------+-------------+-------------+ | IPv4 Src Address (4 bytes) | +-------------+-------------+-------------+-------------+ // // +-------------+-------------+-------------+-------------+ | IPv4 Src Address (4 bytes) | +-------------+-------------+-------------+-------------+

Figure A-17: SCOPE object for RSVP based on IPv4

100

IPv6 SCOPE list object: Class = 7, C-Type = 2

+-------------+-------------+-------------+-------------+ | | + + | | + IPv6 Src Address (16 bytes) + | | + + | | +-------------+-------------+-------------+-------------+ // // +-------------+-------------+-------------+-------------+ | | + + | | + IPv6 Src Address (16 bytes) + | | + + | | +-------------+-------------+-------------+-------------+

Figure A-18: SCOPE object for RSVP based on IPv6

RESV_CONFIRM Carries the IP address of a receiver that requested a confirmation. May appear in a RESV or RESVconf message.

IPv4 RESV_CONFIRM object: Class = 15, C-Type = 1

+-------------+-------------+-------------+-------------+ | IPv4 Receiver Address (4 bytes) | +-------------+-------------+-------------+-------------+

Figure A-19: RESV_CONFIRM object for RSVP based on IPv4

IPv6 RESV_CONFIRM object: Class = 15, C-Type = 2

+-------------+-------------+-------------+-------------+ | | + + | | + IPv6 Receiver Address (16 bytes) + | | + + | | +-------------+-------------+-------------+-------------+

Figure A-20: RESV_CONFIRM object for RSVP based on IPv6

Date post:	24-Feb-2018
Category:	Documents
Upload:	lycong
View:	221 times
Download:	3 times

IPv6 based – On Demand Resource Management in Diffserv · PDF fileIPv6 based – On...

Documents