Internet-Draft S. Hermann Expires: December 12, 2003 T. Chen G. Schaefer Technical University of Berlin C. Fan Siemens AG June 13, 2003 QoS Resource Allocation in Mobile Networks with CASP draft-hermann-casp-qos-mobility-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 12, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document discusses QoS resource allocation in mobile networks with Cross-Application Signaling Protocol [1].CASP separates signaling message delivery from the discovery of the next suitable CASP node. When the discovery is done by scout messages, it may introduce considerable latency in the (re-)registration procedure in handover cases. Therefore, advanced discovery mechanisms are recommended. Hermann, et. al. Expires December 12, 2003 [Page 1] Internet-Draft QoS Mobility CASP June 2003 To demonstrate the use of advanced discovery mechanisms, we enable access routers to provide the information of the aggregate QoS value, the next CASP node and optionally the price of provided services in advertisements in addition to network topology information. By this means, we can achieve seamless mobility and QoS provisioning in a mobile access network because a mobile node can select the most suited access point from several received advertisements for a (re- )registration procedure. In this document, we describe the mechanism and the message flows in both the case of general mobility management using Mobile IPv6 (MIPv6) and the case of micro-mobility management using Hierarchical MIPv6 (HMIPv6). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Enhanced Advertisements . . . . . . . . . . . . . . . . . . . 6 2.1 Message Propagation . . . . . . . . . . . . . . . . . . . . . 6 2.2 Considerations of the Routers in the Access Network . . . . . 7 2.3 Message Format . . . . . . . . . . . . . . . . . . . . . . . . 9 3. QoS Signaling and Registration Process with MIPv6 . . . . . . 14 4. QoS Signaling and (Re-)registration Processes with HMIPv6 in a Separate Signaling Manner . . . . . . . . . . . . . . . . . 17 5. QoS Signaling and Re-registration Processes with HMIPv6 in a Combined Signaling Manner . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 26 Hermann, et. al. Expires December 12, 2003 [Page 2] Internet-Draft QoS Mobility CASP June 2003 1. Introduction In high mobility scenarios, frequent handovers may result in a significant degradation of QoS provisioning if the access network is unable to provide enhanced solutions for prompt QoS re- establishments. Most of the current approaches for signaling protocols consider only the actions which have to be taken after a handover occurs. Some newly proposed protocols use various ideas to speed up the re-establishment of the reservation paths and handle the specific mobility related events, e.g. changes of the IP address of a mobile node. However, none of the protocols introduces mechanisms for the preparation of a handover. Several requirements have been identified for seamless handovers and the fast re-establishment of QoS reservations: o Bidirectional reservation. If the route is symmetric, it should be feasible to set up reservation in both directions with a single reservation message; if the route is asymmetric, a reservation message from the originator should trigger an independent signaling message from the responder. o Path repair and re-establishment of reservations. The paths in a mobility supporting access network usually change only partially after a handover. Therefore, the protocol should support partial repairs of the paths to avoid long distance end-to-end signaling message exchanges between corresponding nodes. o Reservation Range. The reservation range consists of a lower and an upper bounds of QoS parameters e.g. bandwidth. The upper bandwidth value represents the desired bandwidth while the lower value is the acceptable bandwidth. If the network is not able to satisfy the desired value, it can reserve as much as it can which is greater than the acceptable value. Thus, the mobile node is unnecessary to negotiate further with the network on the requested QoS as happens when only one value in a QoS request. o Modularity. The protocol should provide a modular architecture to enable different functionalities flexibly. o Endpoint identifier. The endpoint identifier must be independent from identifiers which may change due to mobility, e.g. the IP address. o Security model. The Security model must provide an efficient and secure solution. All the above mentioned requirements are satisfied by the Cross- Hermann, et. al. Expires December 12, 2003 [Page 3] Internet-Draft QoS Mobility CASP June 2003 Application Signaling Protocol [1] (CASP). The CASP protocol is split into two layers, a general purpose messaging layer (M-layer) and several client layers for signaling applications like QoS, MIDCOM etc. The messaging layer is used to establish session states with session identifiers. These identifiers are independent from the IP address of a node. Therefore they can be used to identify the sessions from a mobile node easily, even after a change of the care- of address due to a handover to another access router. CASP [2] itself deals with it already. As soon as the mobile node detects a route change due to mobility (e.g. based on a layer 2 trigger), it triggers mobility related protocols. The mobility component may trigger a CASP signaling message. In CASP, signaling and discovery message delivery are separated. The Scout protocol is used to discover the next suitable CASP node and the required soft-state refresh interval if the next CASP node is more than one network-layer hop away. It is only needed in case that no other suitable means of discovering the next CASP node are available. See [1] for reference. In environments with high mobility, however, the discovery process with scout will increase a considerable overall handover latency. Additionally, the price information is an important criterion for the handover decision especially in heterogeneous networks. To enable seamless QoS provisioning, we introduce the following new functionalities in our proposed signaling protocol: o Mobility supporting functions. To avoid the extra message exchanges for the discovery, each access routers broadcasts enhanced advertisements regularly, which contains the information about the next suited CASP nodes. o QoS information before handover. The enhanced advertisements contain information about the available resources in the network and a mobile node can the select the suited access router. This procedure demands an efficient and fast information distribution mechanism in the access network. o Price information before handover. If a mobile node receives advertisements from different access networks, its decision for the next access router may depend on the price of the offered service. Therefore, the enhanced advertisements also contain an optional field for the price information. In the following chapters, we describe the components of the CASP Mobility Client, which enables seamless QoS provisioning support for mobile nodes. We also explain the mechanism and the message flows in Hermann, et. al. Expires December 12, 2003 [Page 4] Internet-Draft QoS Mobility CASP June 2003 both the general mobility management (e.g. Mobile IPv6 (MIPv6)) case and the micro-mobility management (e.g. Hierarchical MIPv6 (HMIPv6)) case. Hermann, et. al. Expires December 12, 2003 [Page 5] Internet-Draft QoS Mobility CASP June 2003 2. Enhanced Advertisements Presently, the advertisement only includes the topology information of the access network. In MIPv6 case, mobile node can construct a new Care-of-Address (CoA) based on the advertised prefix information. Before performing a handover, mobile node may receive more than one advertisement from different access routers before the old advertisement expires. We introduce information about the available aggregated QoS of a path and about the price. A mobile node can access the most suited network which offers proper QoS and a reasonable price. 2.1 Message Propagation The foreign mobility agent (e.g. MAP in HMIPv6) of a network is responsible for its own discovery. Therefore it advertises its presence downstream in the access network. Every foreign mobility agent or intermediate router(IR) MUST be able to receive and propagate advertisement messages from its upstream nodes in the access network. Figure 1 shows how advertisement messages propagate in a hierarchical architecture. The router in level 2 sends its advertisement to the routers in level 1, including e.g. its prefix information, the bandwidth value it can provide and the price information. The routers in level 1 receives the advertisement and extracts the useful information from it. Then it composes its own advertisement which contains 1) the prefix information of the upper router and itself; 2) QoS parameters e.g. available bandwidth of the path; and 3) the applicable price information if any. Then it sends out its advertisement. In general, the advertisements from routers in level 1 are sent more frequently than those from routers in level 2. Hermann, et. al. Expires December 12, 2003 [Page 6] Internet-Draft QoS Mobility CASP June 2003 +------+ level 2 |router| | | /+------+\ Advertisement / \ Advertisement / \ v v +------+ +------+ level 1 |router| |router| | | | | +------+ +------+ \ / Advertisement \ / Advertisement \ / v v +------+ |mobile| | node | +------+ Figure 1: Advertisements propagate 2.2 Considerations of the Routers in the Access Network This section describes the required operations of the routers in an access network regarding the propagation of QoS and price information. Usually the information about available resources in a network varies more often than the price information. To reduce the signaling traffic in the network it is advantageous not to advertise the resources each time after a minimal change occurred. Therefore, the routers in the network can maintain threshold values. Apart from that all the values are soft states which are continuously sent by each router. The threshold values determine, under which condition a new advertisement MUST be sent out immediately. Each router (including intermediate router) maintains an upper and a lower threshold value. When the remaining total bandwidth at a router reaches the lower threshold value, the router will not insert the normal bandwidth value which it is providing to a session in its regular advertisements any longer. It sends immediately a new advertisement with a less bandwidth value in it, announcing that it will provide the new bandwidth for further sessions. It will use the new bandwidth value in its regular advertisement until the remaining total bandwidth reaches the upper threshold value. This strategy Hermann, et. al. Expires December 12, 2003 [Page 7] Internet-Draft QoS Mobility CASP June 2003 aims to serve more sessions with a degraded quality instead of providing the whole bandwidth to only some mobile nodes and rejecting the requests of others. When the remaining total bandwidth reaches the upper threshold value due to the bandwidth release from terminated sessions, the router advertises immediately the normal bandwidth since it has enough resources again to provide the normal bandwidth to each session. When the remaining total bandwidth fall in the range of the upper and lower threshold, no irregular advertisement is necessary to be sent out. Otherwise, there would be too many unnecessary advertisements being sent out when the remaining total bandwidth is oscillating around one threshold value due to the continuing process of resource releasing and reserving. In general, an advertisement must be sent if one of the following events occurs: o The router receives a new advertisement from another router. The router must add its own information and forward the advertisement downstream. o The available resources or the price for using the resources changes if there is no threshold values; or the change recommends the sending of an advertisement as described above. o The validity of the advertised information expires. All advertised information are soft state and must be regularly refreshed. If a router does not receive a refresh from another router for a certain period of time, the information expires. o The router receives a solicitation message. In some cases it will be useful for a mobile node to request information from routers via solicitation messages. o Registration or deregistration of a mobile node at a foreign agent (FA). If the FA receives a registration update from a mobile node which leaves an access network, the FA can release the reserved resources and it CAN (depending on the application of thresholds) send an advertisement to the routers in the network. The described process considers the available bandwidth only in the access network. It is not able to provide the QoS information outside the access network. Hermann, et. al. Expires December 12, 2003 [Page 8] Internet-Draft QoS Mobility CASP June 2003 2.3 Message Format An enhanced ICMPv6 Router Advertisement message is shown in Figure 2. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |vers=6 |Prio=15| Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length |Next Header=58 | Hop Limit =255| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Source Address = router or home agent's address | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Destination Address = mobile node's address* or All-Nodes | + multicast address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=134 | Code=0 | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cur Hop Limit |M|O| Reserved | Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retrans Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=3 | Length=4 | Prefix Length |L|A| Reserved 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | (Network-)Prefix | + + Hermann, et. al. Expires December 12, 2003 [Page 9] Internet-Draft QoS Mobility CASP June 2003 | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length=3 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | CASP node address | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length=1 |Flg| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Available Bandwidth | Price Reference Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * The mobile node's address is used as the destination address only when the advertisement corresponds to the mobile node's solicitation message. Figure 2. Message format of an enhanced advertisement The details of IPv6 header and ICMPv6 router advertisement refer in [6]and [7]. We describe only the fields of the enhanced features, which are the IPv6 address of the next CASP node, available bandwidth information, a price reference label. Next CASP node Option: Type TBD Length 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. The value is 3. Hermann, et. al. Expires December 12, 2003 [Page 10] Internet-Draft QoS Mobility CASP June 2003 Reserved This field is unused. Valid lifetime This value indicates the validity duration of the announced CASP node. CASP node address The IPv6 address of "the next CASP node". This address is used as the destination address for the CASP messages which are sent by the mobile node to reserve bandwidth in the access network. Bandwidth and Price Information Option: Type TBD Length 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. The value is 1. Flg A 2-bit flag to indicate the presence of the available bandwidth and the price reference label. 11 means the advertisement contains available bandwidth and price reference label information; 10 means only available bandwidth and no price reference label; 01 means only price reference label and no available bandwidth information. Available Bandwidth 16-bit unsigned integer represents the available bandwidth for each mobile node at the router. Price Reference Label 16-bit unsigned integer represents the price information in the administrative domain. The Next CASP node option is only demanded, if the access router itself can not handle the CASP messages from the mobile nodes. In this case, it advertises the address of another CASP node in the access network, which is suited to process the reservation requests from the mobile nodes. Another application area is the usage of brokers in the access networks. Hermann, et. al. Expires December 12, 2003 [Page 11] Internet-Draft QoS Mobility CASP June 2003 The Bandwidth and Price Information Option SHOULD be included in every advertisement. According to the available bandwidth information, mobile nodes can make decisions on 1) whether to perform a handover; and/or 2) which access router it should handoff to. Moreover, the additional 32-bit length of the Bandwidth Fields is trivial even for wireless channels. This value MAY be replaced by another value when a router at the lower level can provide only less bandwidth. Hence a mobile node can determine the aggregate bandwidth provided by the path when it receives an enhanced advertisement. A mobile node SHOULD be able to obtain the available bandwidth information by means of e.g. sending a solicitation message. To reduce the required number of bits in the price information field, a label is used in this field rather than the detailed price information. Each label specifies a charging model (e.g. 0,25 Euro per min for the first 3 mins and 0,10 Euro per min for every additional min). A mobile node can determine the price with the label based on the knowledge of the label defined in a price reference table. If a mobile node does not have the knowledge of the label or the price reference table, it can request the information from the access network by means of e.g. sending a solicitation message. The access network SHOULD answer each individual solicitation request with the meaning of the label by either unicast or anycast depending on a local policy unless it considers that it is under an attack with an excessive amount of such requests. Furthermore, mobile nodes SHOULD be able to authenticate and check the integrity of the price information presented in an advertisement. More details are discussed in the section of security considerations. Other issues of price information distribution are discussed in [3]. It MAY be necessary that the domain administrator refreshes the price reference table periodically. The refresh interval MUST be much larger than that of advertisement. When the service provider changes the charging model by replacing the old price reference label with a new one from the same price reference table, or it assigns a new charging model to a label, it MUST publicize the new charging model in the access network while taking the following considerations: o The access network SHOULD NOT spend a lot of bandwidth on distributing the detailed information; o A mobile node in the access network SHOULD be able to obtain the charging model information if he does not receive the information Hermann, et. al. Expires December 12, 2003 [Page 12] Internet-Draft QoS Mobility CASP June 2003 distributions. Therefore, when the access network needs to publicize the new charging model, it repeats the meaning of a price reference label in advertisements for e.g. five times. It includes the information in one advertisement e.g. every three advertisements. During the charging model publication period, the access network MAY or MAY NOT answer solicitation requesting the information. After the period, it SHOULD answer the solicitation with the information unless it considers that it is under an attack with an excessive amount of such requests. Hermann, et. al. Expires December 12, 2003 [Page 13] Internet-Draft QoS Mobility CASP June 2003 3. QoS Signaling and Registration Process with MIPv6 After the binding update is sent to the home agent (HA) every packet to the mobile node (MN) is routed via its home network. This Triangular routing between the HA, MN and correspondent node (CN) is removed after sending the first packet from the MN to the CN. Support for route optimization is a fundamental part of MIPv6 and available as an extension for MIPv4. Usually a reservation is initiated by the mobile node. If the correspondent node wants to reserve a path to the mobile node and if route optimization is not yet established, an appropriate error message should be generated by the mobile node or the HA. If the MN sends this message it can attach a binding update and the CN may then try to establish a reservation through the optimized route to the CoA of the MN. Figure 3 shows the message flow during a QoS resource reservation with CASP in a MIPv6 network. MN oAR nAR CR HA CN | | | | | | |( Router Sol. )| | | | |(--------------------->)| | | | | | | | | | |Router Adv. | | | | | |<-----------------------| | | | | | | | | | |Binding Upd.| | | | | |----------------------------------------------->| | | | | | | | | |Binding Ack| | | | |<-----------------------------------------------| | | | | | | | |( | | | | Data )| |( | | | Data |<----------)| |(<=======(Tunnel)===============================| )| | | | | | | |Binding Upd.| | | | | |------------------------------------------------------------>| | | | | | | | | | | Binding Ack | |<------------------------------------------------------------| | | | | | | |CASP-QoS QUERY/RESERVE/COMMIT* | | | |------------------------------------------------------------>| | | | | | | Hermann, et. al. Expires December 12, 2003 [Page 14] Internet-Draft QoS Mobility CASP June 2003 | | CASP-QoS SUCCESS* | | | |<------------------------------------------------------------| | | | | | | |Data, HAO** | | | | | |------------------------------------------------------------>| | | | | | | * The CASP-QoS message types are defined in [3]. The RELEASE message is sent only when the dead-branch-removal flag is set. ** Home Address Option (HAO) Figure 3: Message flows with advertisements in MIPv6 scenarios In inter-domain handover or power-up cases, a mobile node can obtain related information in the access network by either listening to Router Advertisements or performing Router Solicitation. Handover detection based on advertisements significantly contributes to handover latency. Alternatively, before registering with the access router the MN can send a solicitation message to all access routers near it. When MN receives an enhanced advertisement, it can start BU process without the help of scout messages. If an access network does not have this feature of enhanced advertisement, a mobile node MAY send out a scout message to locate its next suitable CASP-aware node as described in [1]. The approach of sending scout messages may introduce significant latency in a handover procedure. After sending the binding update to the home agent and receiving the Acknowledgement, the CoA of the MN is registered. If the MN wants to establish a reservation to a correspondent node, possible after receiving a data packet from it, it adds a Binding Update and a home address option to its next packet which is sent to the CN. This is followed by a CASP-QoS QUERY/ RESERVE/ COMMIT message. The CN replies with a SUCCESS message and a routing header to the MN if the reservation is successful. Otherwise it generates an error message, and the MN may retry its request with a partial reservation. Figure 4 shows a CASP QoS RESERVE message example. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Hermann, et. al. Expires December 12, 2003 [Page 15] Internet-Draft QoS Mobility CASP June 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | Option type | Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 |F|D|A| Reserved| Flow label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | MN Address | 5 | | 6 | | 7 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Address of the next CASP node | 9 | | 10 | | 11 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12 | MN-HoA* | 13 | | 14 | | 15 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16 | AR Address | 17 | | 18 | | 19 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20 |Object Type | Object Length | desired Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 21 |Object Type | Object Length | acceptable Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Home Address of MN (MN-HoA). It represents an global unique identification of the MN. This is relevant to charging. Figure 4: CASP QoS RESERVE message example [8] It is noted that the CASP-QoS information can be piggybacked to the binding-update packet even though the BU and the CASP signaling processes occur in series as shown in Figure 3. Hermann, et. al. Expires December 12, 2003 [Page 16] Internet-Draft QoS Mobility CASP June 2003 4. QoS Signaling and (Re-)registration Processes with HMIPv6 in a Separate Signaling Manner The following are some observations and requirements on intra-domain handover (micro-mobility): o After a handover from one access router to another, a bigger part of the reserved path stays unchanged. The crossover router (CR), where the old and the new path meet, is usually near the mobile node. o The duration of a handover and of the re-establishment of reservations should be short. o There is always a mobility entity in the visited domain to help the mobility management, e.g. foreign agent (FA) in MIPv4, mobility anchor point (MAP) in HMIPv6. o Handovers happen quite often. Due to these the QoS signaling is different from that after a route change or a normal change of the point of attachment to a network. According to the topology shown in Figure 5, Figure 6 shows the message exchanges in HMIPv6 scenarios. The upper part of the message flows shows how to establish a reservation; the lower part shows the re-establishment of the existing reservation after an intra-domain handover. +-----+ +------+ |home |---------------| MAP* | |agent| ____| |__________ +-----+ / +------+ \ | / | \ | / | \ +-------------+ +-----+ +-----+ |correspondent| | oAR | | nAR | | host | +-----+ +-----+ +-------------+ ^ \ v +------+ |mobile|-----> | node | +------+ * Mobility Anchor Point (MAP) Hermann, et. al. Expires December 12, 2003 [Page 17] Internet-Draft QoS Mobility CASP June 2003 Figure 5. HMIPv6 micro-mobility network topology. The MAP is a router located in the foreign domain. It is used by the MN as a local HA. It intercepts all packets addressed to registered Mobile Nodes and tunnels them to the corresponding LCoA. In an HMIPv6 intra-domain handover process, only the reservation on the new path between MN and MAP needs to be re-established. The message flows shown in Figure 6 occur in an HMIPv6 intra-domain handover with a separate signaling manner. MN oAR nAR MAP(CR) HA CN | | | | | | | | Advertisement from MAP | | | | |<------------------------------| | | | | | | | | | Adv. from oAR | | | | | |<---------------| | | | | | | | | | | | BU from MN to MAP as registration | | | |----------------------------------------------->| | | | | | | | | | | BA from MAP to MN | | | |<-----------------------------------------------| | | | | | | | | | BU from MN to HA as registration | | | |----------------------------------------------------------->| | | BU from MN to CN as registration | | | |----------------------------------------------------------------------->| | | | BA from HA to MN | | |<-----------------------------------------------------------| | | | | | BA from CN to MN | |<-----------------------------------------------------------------------| | | | | | | |CASP-QoS QUERY/RESERVE/COMMIT | | | | |----------------------------------------------------------------------->| | | | | | | | | | CASP-QoS SUCCESS | | |<-----------------------------------------------------------------------| |Existing Reservation | | | | |rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr>| | | | | | | | | Adv. from MAP regularly | | | | |<--------------|<--------------| | | | | | | | | | Adv. from nAR | | | | Hermann, et. al. Expires December 12, 2003 [Page 18] Internet-Draft QoS Mobility CASP June 2003 |<-------------------------------| | | | | | | | | | | BU from MN to MAP as re-registration | | | |----------------------------------------------->| | | | | | | | | | | BA from MAP to MN | | | |<-----------------------------------------------| | | | | | | | | |CASP-QoS QUERY/RESERVE/COMMIT | | | | |----------------------------------------------->| | | | | | | | | | | CASP-QoS SUCCESS | | | |<-----------------------------------------------| | | | | CASP-QoS RELEASE | | | | |<------------------------------| | | |Reservation route change | | | | |RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRrrrrrrrrrrrrrrrrrrrrrr>| | | | | | | | | intercept & tunnel packets | route packets | |<-------------------------------|<--------------|<----------------------| | | | | | | | Data | | | | | |----------------------------------------------------------------------->| | | | | | | Figure 6: QoS signaling and (re-)registration processes with HMIPv6 The details of the re-establishment of the existing reservation are discussed as follows. In Figure 6, it is assumed that the MAP is the cross-over router. After receiving an advertisement from nAR/ L2 Trigger, the mobile node sends a binding update request to the MAP of the network. After MN receives the binding acknowledgement, the connection to the foreign domain is reestablished. Afterwards the MN tries to rebuild the reservation to the CN. It sends a QoS CASP reservation message containing the IP address of the CN as the destination address. The CASP message propagates until it reaches the CR. MAP is assumed to be the first node which can identify the session according to the existing session ID. Due to the changes the access router and the link, the IP addresses in the flow-id are different. When the upstream of the CASP-QoS signaling process is successful, MAP replies a "CASP-QoS SUCCESS" message. If a dead-branch-removal flag is used, the old reservation can be deleted. If the message contains no flag, the old reservation should time out. The rest of the path to the CN remains the same and the CR can initiate the re- Hermann, et. al. Expires December 12, 2003 [Page 19] Internet-Draft QoS Mobility CASP June 2003 establishment of the upstream reservation. In case of "CASP-QoS FAILURE", MN either keeps the new connection without any QoS support or revokes the binding updates and stays in the old path. The integrated signaling procedure shown in the next section can avoid this dilemma. If there is only an upstream reservation, the reservation message can be discarded by MAP. Else, if there is also a downstream reservation, the CN needs to be informed about the handover. This can be done by sending an error message for the existing downstream reservation to the CN. Hermann, et. al. Expires December 12, 2003 [Page 20] Internet-Draft QoS Mobility CASP June 2003 5. QoS Signaling and Re-registration Processes with HMIPv6 in a Combined Signaling Manner In an access network the interaction between mobility management and QoS resource reservation should be very close. Combining both mechanisms is a valuable approach. This chapter describes a method by which QoS information is collected in the access routers and advertised to the mobile nodes, which may have the choice between different access points and may choose the most suited one based on the QoS information in advertisements [8]. In addition to the QoS and mobility considerations, the security issues, such as authentication, authorization and DoS attack protection should be taken into account. The success of the re-registration procedure in an intra-domain handover depends on two aspects: 1. the new path can provide e.g. at least the acceptable bandwidth; 2. the re-authentication and re- authorization (re-AA) checks pass. Figure 7 shows the combined signaling message flows for the intra- domain handover case in HMIPv6 scenarios [8] It is assumed that MN has a bidirectional QoS-enabled connection with CN before it starts an intra-domain handover. MN receives more than one enhanced advertisements from different ARs, it can select the most suitable AR as the handover target. When the handover is triggered, MN sends an re-registration request message to the target AR(nAR). When nAR receives the request, it starts the BU process. CASP is embedded in the BU packet. Each node along the path from nAR to MAP checks whether it can satisfy at least e.g. the acceptable bandwidth for either uni-direction or bi-direction. If yes, it reserves the requested resource. When MAP (which is assumed to be the CR) realizes that each node on the path can meet the request, it communicates with AAAL for a re-authentication and re-authorization (re-AA) check. If the re-AA passes, MAP sends back a BU ACK packet including CASP. While MAP sends the BU ACK packet, it initiates the reservation release process to tear down the path between oAR and MAP. In brief, the integration of BU process and CASP-QoS signaling is beneficial for intra-domain handovers in terms of the low-latency feature. Hermann, et. al. Expires December 12, 2003 [Page 21] Internet-Draft QoS Mobility CASP June 2003 MN oAR nAR MAP(CR) AAAL CN |Existing Reservation | | | | |rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr>| | | | | | | |Router Adv. | | | | | |<-----------------------| | | | | | | | | | |Re-registration req. | | | | |----------------------->| | | | | | |BU+CASP* | | | | | |---------->| | | | | | |re-AA | | | | | |<-------->| | | | |BU ACK + CASP** | | | | |<----------| | | | |BU ACK | | | | |<-----------------------| | | | | | CASP-QoS RELEASE | | | | |<----------------------| | | | | | | | Data | |( | Data | |<---------------------)| |(<=======(Tunnel)===================| | )| | | | | | | |Data, HAO***| | | | | |----------------------------------------------------------->| | | | | | | * the CASP message (QUERY/RESERVE/COMMIT) can be send in parallel to the BU message or may be combined and checked by each CASP node along the path. ** the CASP (SUCCESS) can trigger the downstream QoS signaling. *** Home Address Option (HAO) Figure 7: Message flows with the advertisements in HMIPv6 scenarios Hermann, et. al. Expires December 12, 2003 [Page 22] Internet-Draft QoS Mobility CASP June 2003 6. Security Considerations Security threats for NSIS are identified in [5]. NSIS AAA issues are included in [3]. There are additional security issues related to enhanced advertisements. Mobile nodes SHOULD be able to authenticate the source of an advertisement, and to check the integrity of QoS and price information in an advertisement. If a malicious node modifies the price distribution information or it advertises wrong information masquerading a legal AR, it can cause trouble or confusion to mobile users or to the service provider when mobile nodes do not perform the security checks. Details of a solution will be worked out in subsequent versions of this draft. Hermann, et. al. Expires December 12, 2003 [Page 23] Internet-Draft QoS Mobility CASP June 2003 References [1] Schulzrinne, H., "CASP - Cross-Application Signaling Protocol", Internet Draft draft-schulzrinne-nsis-casp-01.txt, March 2003. [2] Schulzrinne, H., "A Quality-of-Service Resource Allocation Client for CASP", Internet Draft draft-schulzrinne-nsis-casp- qos-01.txt, March 2003. [3] Tschofenig, H., "NSIS Authentication, Authorization and Accounting Issues", Internet Draft draft-tschnofenig-nsis-aaa- issues-01.txt, March 2003. [4] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", Request for Comments RFC 2104, February 1997. [5] Tschofenig, H., "Security Threats for NSIS", Internet Draft draft-ietf-nsis-threats-01.txt, January 2003. [6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", Request for Comments RFC 2460, December 1998. [7] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", Request for Comments RFC 2461, December 1998. [8] Chen, T., Hermann, S. and G. Schaefer, "Secure QoS-enabled Mobility Support for IP-based Networks", March 2003, . Authors' Addresses Sven D. Hermann Technical University of Berlin Sekr. FT 5-2, Einsteinufer 25 Berlin 10587 Germany Phone: ++49 30 314 28224 EMail: hermann@ee.tu-berlin.de URI: http://www-tkn.ee.tu-berlin.de/~hermann Hermann, et. al. Expires December 12, 2003 [Page 24] Internet-Draft QoS Mobility CASP June 2003 Tianwei Chen Technical University of Berlin Sekr. FT 5-2, Einsteinufer 25 Berlin 10587 Germany Phone: ++49 30 314 23825 EMail: chen@ee.tu-berlin.de URI: http://www-tkn.ee.tu-berlin.de/~chen Guenter Schaefer Technical University of Berlin Sekr. FT 5-2, Einsteinufer 25 Berlin 10587 Germany Phone: ++49 30 314 23836 EMail: schaefer@ee.tu-berlin.de URI: http://www-tkn.ee.tu-berlin.de/~schaefer Changpeng Fan Siemens AG Siemens AG Berlin D-13627 Germany Phone: ++49 30 386 36361 EMail: changpeng.fan@siemens.com Hermann, et. al. Expires December 12, 2003 [Page 25] Internet-Draft QoS Mobility CASP June 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Hermann, et. al. Expires December 12, 2003 [Page 26]