QoS Provisioning in Mobile Internet Environment

Transcription

1 QoS Provisioning in Moile Internet Environment Salem Lepaja Reinhard Fleck, Nguyen Nam Hoang Vienna University of Technology, Institute of Communication Networks, Favoritenstrasse 9/388, A-1040, Vienna, Austria ABSTRACT In this paper, issues of QoS provisioning to the moile users in the moile Internet environment are discussed. In order to meet moile user s requirements for realtime applications, an extended RSVP protocol for QoS provisioning is proposed. The proposed protocol is ased on an existing flow transparent moile IP and RSVP integration concept and can e considered as its extension for meshed access network topologies. The asic idea of our proposal is to use the old access router as a nearest common router (NCR) for the old and the new added flow paths. Particularly, challenges concerning QoS signalling for seamless handover are investigated. 1INTRODUCTION Rapid growth of Internet and moile communications, particularly towards real-time multimedia and nonmultimedia service provisioning, is expected in the next few years. Furthermore, it is expected that more moile hosts than PCs will e connected to the Internet. Moile users are interested to get the same services on moile terminals as on fixed terminals. Therefore, providing quality-of-service (QoS) to moile user s applications is an imperative request to the next generation Internet. The M protocol provides transparency of host moility to transport and higher layer protocols ut does not provide QoS. In order to meet end-to-end quality for real-time applications, two Internet QoS architectures have een designed: Integrated services and Differentiated services. As these QoS architectures do not consider moile environments, extensions of the existing service architectures or new ones are needed. In this paper, we propose an extended RSVP protocol for QoS provision to moile hosts, which is ased on a flow transparency concept and can e considered as its extension for meshed access network topologies. The asic idea of our proposal is to use the old access router as a Nearest Common Router (NCR) for the old and the new added flow paths. If using the old access router as NCR does not satisfy QoS requirements, the new access router has to renegotiate the RSVP session through the next hop router. In the next section, we riefly descrie properties of the moile protocol. In Section 3, a rief discussion of the RSVP signalling protocol is presented. Section 4 rings an overview of proposed solutions for QoS provisioning to moile hosts. An existing flow transparent Moile IP and RSVP interworking scheme for QoS provisioning to moile users is descried in Section 5. In Section 6, we present an extended RSVP protocol for QoS provisioning to moile users. Conclusions are drawn in the last section. 2MOBILE IPV6 PRINCIPLES AND REQUIREMENTS FOR QOS PROVISION The moile protocol [1] enales a moile node to communicate with other nodes after changing its point of attachment from one IP sunet to another without changing its IP address. Without this feature the Moile Node () would not e ale to maintain transport and higher layer protocol sessions, which depend on a static IP address. The prolem is solved y assigning two IP addresses to a moile host: a permanent IP address, which is called IP home address, and an temporary IP address, named care-of-address (CoA), which is assigned each time the moile node is visiting a new foreign sunet. Home address is used for transport and higher layer sessions whereas CoA is needed to route packets correctly to the actual point of attachment. In this way, the impact of host moility is reflected only in the routing layer. home network HA moility ackone Moile Node HA Home Address CoA Care of Address Corresponding Node Figure 1: Moile CoA visited network As shown in Fig. 1, a moile node () is a node that can change its point of attachment to the Internet, whereas a correspondent node () is a host communicating with the. A home agent is a router in the s home network, handling the moility of the. Every time that the gets a new CoA, it has to register it to the home agent and the, y sending inding update (BU) messages. Packets of new calls are intercepted y the home agent and then tunnelled to the s CoA y using encapsulation, whereas packets elonging to active sessions are sent directly to CoA. Packets from the are sent to the through the Internet as usual. In asic Moile IP, each handover implies end-to-end signalling. This can take a consider-

2 ale time efore all the s and the home agent have received the BU messages. Packets sent to the old CoA during this time period are potentially lost. For local moility, several protocols have een proposed as extensions to Moile IP to enale seamless handover. 3RESOURCE RESERVATION PROTOCOL -RSVP RSVP is a signalling protocol for resource reservation [2]. It is a receiver-oriented simplex protocol i.e. reservation of resources is requested y the receiver and for each flow direction resources are reserved independently. RSVP signalling configures the QoS flow handling mechanism in RSVP-capale routers along the path of the traffic flow. There are several RSVP messages: path, reservation, error, reservation confirmation, and teardown. Each RSVP message consists of a common header and variale numer of ojects. The Path message is sent y the sender to set up the path state at the routers along the path from the sender to the receiver. Path messages are sent with the same source and destination address as the data, so that they will e routed correctly through non-rsvp networks. The Path message includes, esides other ojects: SENDER_TEMPLATE, to identify the sender of the flow, SENDER_TSPEC, to descrie the traffic characteristics of the flow generated y the sender, RSVP_HOP (PHOP), to identify the previous hop, which has sent this Path message, SESSION oject, which identifies the destination of the flow. Each RSVP router processes Path messages to create the path state for each sender. Also, it periodically scans the path states to create new Path messages and to forward them towards the receiver(s). The Resv messages are sent y each receiver along the reverse path from the receiver to the sender hop y hop to ask for resources. They create and maintain the reservation state in each node along the path. A Resv message contains, esides other ojects, the FLOW_SPEC and FILTER_SPEC. FLOW_SPEC defines a desired QoS, whereas FILTER_SPEC defines a suset of packets to receive the desired QoS. RSVP error messages (PathErr and ResvErr) signal errors to the sender of the message. PathErr is sent upstream to the sender that created the error, whereas ResvErr is sent to the receiver if the reservation is rejected at any router along the upstream. The reservation confirmation message ResvConf is sent to the receiver to acknowledge reservation request. Teardown messages, PathTear and ResvTear, are used to remove immediately path or reservation state, respectively. RSVP contains many features among which soft state, local repair and merging are the most important ones. RSVP uses soft states to manage the reservation in routers and hosts. Soft states are periodically refreshed y Path and Resv messages. Local repair provides fast adaptation to routing changes. Mergefunctionality is used to reduce signalling in forwarding reservation requests from all next hops (to which the data flow will e sent) to the previous hop. 4 RELATED WORK FOR QOS PROVISION TO MOBILE NODES In the moile Internet environment, real-time services require oth moility and QoS support. Several solutions addressing QoS provision to moile hosts have een proposed, which may e grouped into: Advance reservation schemes, Moile QoS extention schemes, RSVP and Moile interworking schemes. 4.1 Advance reservation of resources In order to provide quality of services to moile hosts (MH) applications in general resource reservation is needed. There have een many proposals to perform reservation in advance. The challenge for these schemes is how to predict the MH s movement so that in advance reservation may e done only in some of the potentially new cells. In [3], a moile RSVP (MRSVP) protocol is proposed, which allows a MH to make in advance reservation along the data flow paths to and from the cells it may visit during the lifetime of the connection According to MRSVP, a MH can make advance reservation from a set of cells, called Moility specification (MSPEC). For efficient use of resources, a moile sender makes an active reservation from its current cell and it makes passive reservation from the other cells in its MSPEC. Similarly a moile receiver makes an active reservation to its current cell and passive reservation to the other cells in its MSPEC. Passive reservations may e used from other moile users as well, whereas active reservations elong only to the moile user itself. However, the active and passive reservation model results in a very complex and expensive protocol QoS oject option This approach is ased on using a new extension header option called QoS OBJECT OPTION to forward QoS requirements of moile nodes to the routers along the connection path. A fast QoS handover signalling is achieved y sending QoS OBJECTs in the hop-y-hop extension header of the Binding Update (BU) or Binding Acknowledgement messages, depending on the packet stream direction. As these messages travel only up to the nearest regional moility agent that needs to update its route entry, end-to-end QoS OBJECT forwarding is avoided. QoS OBJECTs can e sent in any IP packet as well. Processing of QoS OBJECTs at intermediate networks is suject to the domain s QoS handling mechanisms. A simple comparison with a moility unaware RSVP approach (descried in Section 4.3) considering QoS handover-signalling delays is given in [4]. 4.3 Interworking of RSVP and Moile protocols Interworking of Moile IP and RSVP protocols is another approach for QoS provisioning to moile users. Based on this approach, several schemes are proposed. In [5], a comined scheme of RSVP and Moile is given. The asic feature of this scheme is that flow identification is ased on the s CoA. Each time that the changes the CoA during a session, an end-toend RSVP signalling etween the and the is needed. This results in waste of resources, signalling

3 overhead, and high QoS signalling latency during handover. The QoS signalling delay from the time packets using the new CoA are released into the network until the time QoS handling mechanisms are configured along the is one round trip delay when the is a sender and one and a half round trips when the is a receiver. In order to alleviate the aove-mentioned prolems, a more advanced scheme ased on RSVP and Moile protocols interworking is proposed [6,7], which will e descried in the following section. 5FLOW TRANSPARENCY CONCEPT OVERVIEW 5.1 Protocol description The flow transparency (FT) concept [6] is an interoperation scheme of Moile and RSVP protocols to provide seamless QoS handover y avoiding an end-to-end resource reservation renegotiation process. The idea of the FT concept (Fig. 2) is to keep host moility transparent to the network layer flow handling mechanism, similar to the Moile IP concept, which keeps host moility transparent to the transport layer protocols. This is achieved y identifying the flow address (source and destination addresses) with the s home address, regardless of the change of the s CoA. However, this has an impact on oth the RSVP and Moile protocols. as a receiver ackone common path of flow Path Resv PathReq of flow AR of flow AR Figure 2: Flow Transparency moility In order to keep the flow identity constant, Path and Resv messages use s home address to identify the flow. When the is a sender, the s home address will e written in the SENDER_TEMPLATE field of the Path message. Also the FILTER_SPEC field of the respective Resv message will carry the s home address. When the is a receiver, the flow destination will e identified with the s home address, written in the SESSION OBJECT field of RSVP messages. Certain modifications are required in RSVP routers (depending on M modifications) such as where the packet classifier should read the home address of the packets. When the in Moile, is a sender, CoA is used for the source address of the packets, whereas the s home address is carried in the destination option header. When the is a receiver, the s CoA is used as a destination address, whereas the s home address is carried in the routing header. Considering the flow transparent concept and the is a sender, modifications are needed in M for correct classification of packets in routers. The following solutions have een proposed: a. The Home address of the is used as source address, whereas the CoA is in the destination option header.. The CoA of the remains in the source address field, whereas the home address is in the hop-y-hop option header. c. A new header option called flow transparent route alert option is carried in hop-y-hop option header, whereas the s CoA and home address remain as they are in M. Solutions a and require the modification of M asic properties. Solution c can e considered as an extension of the M features, ecause only a router alert option field needs to e added. When the is a receiver its home address is hidden from intermediate routers. However, due to flow lael parameter of M, the flow handling mechanism can process packets according to the flow source and flow lael without examining the packet s flow destination. 5.2 Handover procedure For fast QoS signalling renegotiation due to handover, the merge and local repair features of RSVP at the Nearest Common Router (NCR) - the first common router on the old and of the flow- are exploited. For simpler explanation of handover procedures in cases where the is a sender and where the is a receiver are presented separately Moile node as a sender After the gets a new CoA, it sends first a BU message to the and the HA as usual. Immediately after that the sends a Path message with the same flow address as efore the handover ut with a different CoA and previous hop address. If a router oserves that Path message has the same flow address ut oth CoA and previous hop addresses are different from the ones already stored in the path state, it will identify itself as an Uplink NCR (UNCR). The UNCR immediately replies with a Resv message to reserve resources along the newly added path to the (local repair due to sender moility). In the common uplink flow path (from UNCR to ), the previously reserved resources will e used. Since the Path message traverses a shorter distance than the BU, QoS configuration of routers in the new added path is achieved efore packets with the new CoA are issued in the network, resulting in seamless handover Moile node as a receiver When the moile node acts as a receiver, handover operation is different from the sender case. After changing the CoA, the receiver sends a BU to the and HA. Because it cannot issue the Resv message efore it receives the Path message and instead of waiting for a Path message from the, the informs the Downlink NCR () of its moility to trigger the Path message from the. For this task, an additional RSVP message named PathReq is needed. The PathReq message will carry moility information in the moility oject (MO), which contains the home address and the current CoA of the. The home address will e used as flow destination whereas CoA will e used as

4 destination address of the susequent Path message sent y the. The MO can e also piggyacked in a Path message sent y the itself if the acts as oth sender and receiver. Upon receiving a PathReq message or a Path message with a MO sent from the, the RSVP router decides whether it is the y comparing the home address in the MO with the related information in the path state for the flow destined to the. If the router identifies itself as a then it sends a Path message to the s new CoA (local repair due to receiver moility) for the flow indicated y destination. 6 AN EXTENDED RSVP PROTOCOL FOR MOBILE USERS In this section, we present an extended RSVP protocol for QoS provisioning to moile users. The proposed protocol is ased on the Flow Transparency (FT) concept and can e considered as its complimentary for meshed access network topologies. The asic idea of our proposal is to use the old access router as a nearest common router (NCR) for the old and the new added flow path. If using the old access router as NCR does not satisfy QoS requirements, the new access router has to renegotiate the RSVP session through the next hop router. We propose to add the old s CoA to the moility information sent to the new access router, in addition to the home address and the new CoA. The protocol procedures for oth cases, when the is a receiver and when the is oth sender and receiver will e presented. 6.1 Moile node as a receiver When the moile node acts only as a receiver the moility oject, containing the moility information, is carried in the PathReq message. When the access RSVP router receives a PathReq message from the, it checks first if it is the, y comparing the s home address with the existing one in the path state information. The following two cases may e considered: accessed RSVP router is not a or it is. is a receiver a c k o n e New path oldar newar Access Network Figure 3: Extended RSVP with direct link moility 1. If the new access router is not a, then the router checks if it is an adjacent to the s old access router (ased on the old CoA carried in moility oject). 1.a. If it is adjacent (Fig. 3), then the new access router forwards the PathReq message to the old access router. Upon receiving the PathReq message, the old access router will respond with a Path message towards the s new CoA and will also send a PathTear message to the old s CoA to trigger the release of the old reserved resources. After receiving the Path message the sends a Resv message to reserve resources along the. The old reserved resources etween the old access router and the are reused. 1.. In the case that the new access router is not an adjacent to the old access router (Fig. 4.), then it forwards the received PathReq message to the next hop router. Each next hop router will repeat the procedures, explained aove (checking for ), until the resources in the new added path are reserved. 2. If the new access router is a, then the protocol procedures are the same as in the existing protocol explained in Section is a receiver a c k o n e New AR Old AR Access Network moility Figure 4: Extended RSVP without direct link 6.2 Moile node as a sender and receiver When the moile node acts as a sender and as a receiver, the moility oject is carried in the Path message sent from to. The new access router will first check the uplink and then the downlink direction Uplink direction When the new access router receives the Path message from the, it checks first if it is the UNCR y comparing the s home address, the new CoA, and the previous RSVP hop with the existing path state information for the uplink direction. Suject to the comparing results access router identifies itself whether it is the UNCR. 1. If the new access router is not a UNCR, then the router checks if it is adjacent to the s old access router. 1.a. If it is adjacent, the new access router sets up the path state and forwards the Path message to the old access router. Upon receiving the Path message, the old access router responds with Resv message towards the s new CoA to reserve resources in the new added path. The old access router will also forward the Path message to the next hop router to update moility information and it will at the same time send a ResvTear message to the old s CoA in order to release the old reserved resources. Whereas, the old reserved resources etween the old access router and are reused. 1.. If the new access router is not adjacent to the old access router, then it sets up the path state and it forwards the received Path message to the next hop

5 router. Each next hop router will repeat the same procedures explained aove (checking for UNCR), until the resources in the new added path are reserved. 2. In case that the new access router is a UNCR, than the protocol procedures are same as in the existing protocol explained in Section Downlink direction After processing the moility information for the uplink direction, the new access router will proceed to compare the same moility information, carried in the Path message, with the path state for the downlink direction. The protocol procedures are completely the same as for the case when moile node acts only as receiver (only the name of the message is Path instead of PathReq), which are explained in Section 6.1. The flow diagram of the messages when the moile host is sender and receiver is shown in Fig. 5 for the case when access router is not a NCR 5 9 Data newar oldar CoreRouter 1 BU 2 PATH(MO) 3 NewRouter Decisionfor UNCR 4 RESV( ) 5 RESV_TEAR_DOWN_OLD 6 NewRouter Decisionfor 7 PATH(MO) PATH ( ) 9. PATH_TEAR_DOWN_OLD 10. RESV ( ) 11. PATH_TEAR & RESV_TEAR ( ) 12. PATH_TEAR & RESV_TEAR ( ) Figure 5: Flow Diagram As conclusion of this protocol description we argue that the proposed protocol offers greater efficiency in terms of resource reservation for mesh topologies and seamless QoS handover than the existing protocol [6]. By using the old access router instead of the NCR fewer new QoS paths need to e estalished and faster release of the old reserved resources are achieved. It is particularly suitale for local moility when a moile user visits a previous sunet again. The protocol also encounters minimum extensions to the Moile and RSVP protocols, keeping the asic principles of the protocols unchanged. The moility oject carried in Path or PathReq messages is extended to carry the s old CoA in addition to the home address and the new CoA. As far as M is concerned, we propose the solution given in Section 5.1.c for address mismatch avoidance, as this is just an extension to MIPV6 and not the modification as offered y other proposals. 1 RSVP protocols, the so-called flow transparent concept, was adopted. Based on this concept we have proposed an extended RSVP protocol for meshed access networks topologies. The essential idea of this protocol is ased on using the old access router as a nearest common router (NCR) for the old and the new added flow path. We argue that the proposed protocol provides more efficient QoS handover, in terms of time and resource reservation, than the existing protocol. It is particularly suitale for short range moility when a moile user visits previous sunet again. However, the simulation results must show the claimed advantage, which is the next step in our further work. REFERENCES [1] D. Johnson and C. Perkins, Moility support in, IETF Internet draft <draft-ietf-moileip-ipv6-12.txt>, April [2] R. Braden, et al Resource reservation Protocol (RSVP), NWG RFC 2205, Septemer 1997.C. Q. [3] A. K. Talukdar, et al MRSVP: A Resource reservation Protocol for an Integrated Services Network with Moile Hosts, Wireless Networks, Vol. 7/1, Jan/Fe 2001, pp [4] H. Chaskar and R. Koodli A Framework for QoS Support in Moile, IETF Internet draft <draft-chaskar-moileip-qos-01.txt>, March [5] G. Chiruvolu, A. Agrawal, and M. Vandenhoute Moility and QoS support for -ased real-time wireless Internet traffic, 1999 IEEE Int. Conf. on Communications, Vol.1, Vancouver, BC, Canada, June 1999, pp [6] Shen at al, An interoperation framework for using RSVP in Moile Ipv6 Networks, IETF Internet draft <draft-s1hen-rsvp-moileipv6-interoip-00.txt>, July [7] Q. Shen, A. Lo and W. Seah, Performance Evaluation of Flow Transparent Moile and RSVP Integration, July CONCLUSIONS AND FURTHER WORK The issues of QoS provisioning to moile users applications, focusing particularly on seamless QoS handover, have een discussed. In order to meet actual and future requirements of moile user s real-time and non-real time applications, an integrated scheme of M and