NSIS Working Group Xiaoming Fu Internet-Draft Holger Karl Expires: July 16, 2002 Andreas Festag Guenter Schaefer Technical University Berlin Changpeng Fan Cornelia Kappler Mirko Schramm Siemens AG January 15, 2002 QoS-Conditionalized Binding Update in Mobile IPv6 draft-tkn-nsis-qosbinding-mipv6-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 July 16, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This draft presents a scheme for QoS support in Mobile IPv6. A QoS hop-by-hop option piggybacked in the binding messages is used for QoS signaling. A handoff takes place only upon the availability of sufficient resources along the new transmission path. This QoS- conditionalized scheme builds upon the hierarchical modbile IPv6 Fu, et al. Expires July 16, 2002 [Page 1] Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002 protocol and is especially fit for local mobility, where the signaling overhead is reduced. It also enables the mobile node to flexibly choose among a set of available access points so that the mobile node can transmit packets through a route which offers satisfying QoS. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Format of QoS option . . . . . . . . . . . . . . . . . . . . 11 5. Detailed description of QoS-conditionalized binding update procedure . . . . . . . . . . . . . . . . . . . . . . 13 5.1 Mobile node . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2 Router . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Comparison of our scheme with the requirements draft . . . . 15 6.1 Performance requirements . . . . . . . . . . . . . . . . . . 15 6.2 Interoperability requirements . . . . . . . . . . . . . . . 15 6.3 Exception condition requirements . . . . . . . . . . . . . . 15 6.4 Miscellaneous requirements . . . . . . . . . . . . . . . . . 16 6.5 Obvious requirements . . . . . . . . . . . . . . . . . . . . 16 7. Further discussion . . . . . . . . . . . . . . . . . . . . . 18 7.1 QoS control in entities unaware of the BU/BA options . . . . 18 7.2 Sending QoS-conditionalized binding messages via a non-default route . . . . . . . . . . . . . . . . . . . . . 18 7.3 Signaling downstream QoS requirements . . . . . . . . . . . 18 7.4 Upgrading the level of QoS . . . . . . . . . . . . . . . . . 19 7.5 Possibility of changing from a hop-by-hop option to destination option . . . . . . . . . . . . . . . . . . . . . 20 7.6 Handling intermediate reservations . . . . . . . . . . . . . 20 7.6.1 Optimistic reservation . . . . . . . . . . . . . . . . . . . 21 7.6.2 Postponed reservation . . . . . . . . . . . . . . . . . . . 21 7.7 Handling large signaling packets over the wireless link . . 21 8. Security considerations . . . . . . . . . . . . . . . . . . 23 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . 24 References . . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26 Full Copyright Statement . . . . . . . . . . . . . . . . . . 28 Fu, et al. Expires July 16, 2002 [Page 2] Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002 1. Introduction With the advent of various radio access technologies and increasing deployment of sophisticated applications in mobile end systems, IPv6- based networks will increasingly have to support Quality of Service (QoS) in mobile environments. Mobile IPv6 ensures correct routing of packets to a mobile node when the mobile node changes its point of attachment with the IPv6 network. However, it is also required to provide proper QoS forwarding treatment to the mobile node's packet streams at the changed route in the network due to node mobility in a fast, flexible, and scalable way, so that QoS-sensitive IP services can be supported over Mobile IPv6 [2]. A QoS scheme for Mobile IPv6 should (i) be able to localize the QoS (re-) establishment to the affected parts of the packet path in the network, and (ii) in cases where more than one access technology or access router (AR) is available, it may be desirable for the MN to choose an appropriate AR that can satisfy its QoS requirements among several potential new ARs when the MN moves into such a region (especially since in vertical handoff scenarios, choosing a "good" access router might be more important than the mere speed of reestablishing a QoS path). In these cases, a handoff should not be performed if the MN's QoS requirement is not met; yet if the QoS can be met, handoff should be performed as quickly as possible. In reference [7] a new IPv6 option called "QoS option" is introduced. One or more QoS objects are included as a hop-by-hop option in IPv6 packets carrying Binding Update (BU) and Binding Acknowledgement (BA) messages. When one packet for this purpose traverses different network domains in the end-to-end path, the QoS option is examined at these intermediate network domains to trigger QoS support for the MN's data packets. The mechanism described in reference [7] outperforms RSVP [8][12] in that its signaling overhead is decreased. However, it does not allow to check whether the QoS requirements are satisfied along the new route before performing the handoff. We therefore introduce a QoS- conditionalized binding update. The node at which old and new paths diverge ("switching router") makes the final decision whether or not to update the binding, depending on the result of QoS checks. A binding update will only take place (in the sense of modifying the route) if all nodes along the route between the AR and the switching router are capable of complying with the QoS request, otherwise, the old route will still be used and a negative acknowledgement will be returned to the MN. Our scheme is based on the architecture of Hierarchical Mobile IPv6 (HMIPv6) [6] to localize the QoS-conditionalized bindings. In HMIPv6, a new entity, the Mobility Anchor Point (MAP), is introduced Fu, et al. Expires July 16, 2002 [Page 3] Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002 and a MN only needs to perform one Local BU through MAP when changing its layer 3 access point within the MAP domain. Hence the MAP is a reasonable place for the switching router. However HMIPv6 is not able to express QoS requirements, let alone to provide feedback regarding the success of such request. We built on the work described in reference [7] to overcome these limitations. In this scheme, a QoS hop-by-hop option is carried in the message containing the BU option to the MAP - this message is called BU+QoS message. Each node concerned with QoS management between the MN and the MAP (including the MAP) will pass the QoS requirement represented by the QoS option to internal QoS mechanisms and check its resource availability. If resources are available locally, they are reserved and the message will be forwarded along its route. If specified in the BU+QoS message, reservations covering less than the desired amount of resources are also be possible; the request in the BU+QoS message is then updated accordingly. If resources are not available, negative feedback will be provided to the MN. Upon receiving the BU+QoS message, the MAP also checks resource availability and, if successful, will update the binding status and respond with a positive BA+QoS message, including the actual amount of reserved resources, if different from the requested amount. Otherwise, no binding update is performed and a negative BA+QoS message is returned to the MN. By way of this scheme, QoS (re-)establishment due to local handoffs is managed locally and transparently to the CNs, while in the worst case (global mobility) it is managed with Mobile IPv6 and [7]. Only if all routers along the new path find that sufficient resources are available will a handoff (switching from old to new path) take place. In this sense, the handoff process is conditional on the availability of QoS resources and our scheme can take advantage of HMIPv6. The additional advantage, however, is that mobile nodes will only perform a handoff to an AR that can fulfill the QoS requirement (if there are multiple ARs to choose from; in case there is only a single AR able to serve the mobile node, even best-effort service would likely be acceptable, however, this is an application-level concern). The rest of this document provides a detailed description of the QoS- conditionalized binding update procedure(s) for Mobile IPv6. The document is organized as follows: o Section 2 gives the terminology used in the document. o Section 3 gives an overview of the scheme. o Section 4 gives the message format used for the scheme. Fu, et al. Expires July 16, 2002 [Page 4] Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002 o Section 5 describes the scheme in more detail. o Section 6 compares our scheme with the requirements for a QoS solution for Mobile IP as described in [2]. o Section 7 presents a few important issues brought up by our scheme and gives the reasons for choosing a particular solution among different possibilities within our scheme. o Section 8 addresses the security considerations. Fu, et al. Expires July 16, 2002 [Page 5] Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002 2. Terminology This document uses the following terms in addition to those defined in the Mobile IPv6 protocol [4] and Hierarchical Mobile IPv6 protocol [6]: QoS option: A Hop-by-Hop option introduced in reference [7]. A QoS option contains zero or more QoS objects in Type/Length/ Value (TLV) format. QoS object: An object introduced in reference [7]. Essentially, QoS OBJECT is an extension of RSVP QoS and FILTER_SPEC objects, and contains certain parameters representing QoS requirements and traffic characteristics for a QoS flow. QoS entity: An entity responsible for QoS negotiation and establishment. Examples are RSVP daemons in RSVP/IntServ, a Bandwidth Broker in a DiffServ domain, or a Label Edge Router in an MPLS domain. From the perspective of MIPv6, QoS (re)establishment is treated transparently in QoS-capable routers or hosts; the IPv6 nodes MAY ask QoS entities to check the QoS requirements included in the QoS option, and afterwards the latter SHOULD perform such a reservation and respond with an acknowledgement possibly along with (possibly modified) QoS parameters. Switching router/MAP: The node at which old and new paths diverge The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Besides, the following acronyms and abbreviations are used in this document: MIP/MIPv6/HMIPv6: Mobile IP/Mobile IPv6/Hierarchical Mobile IPv6 MAP: Mobility Anchor Point MN: Mobile Node CN: Correspondent Node QoS: Quality-of-Service CoA: Care-of-Address Fu, et al. Expires July 16, 2002 [Page 6] Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002 RCoA/LCoA: Regional/On-Link CoA HoA: Home Address AR: Access Router BU/BA: Binding Update/Binding Acknowledgement ER: Edge Router of network domain IR: Interior Router of network domain MPLS: Multi-Protocol Label Switching LSP: Label Switched Path DiffServ: Differentiated Services IntServ: Integrated Services RSVP: Resource ReSerVation Protocol Upstream(UP)/Downstream(DW) direction: From MN/Towards MN Fu, et al. Expires July 16, 2002 [Page 7] Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002 3. Overview The all-IP network is assumed to consist of routers which may also be responsible for the management of QoS resources, in which case we call them QoS entities. For the purpose of this paper, such a QoS entity acts as a black box to which QoS requests for a certain path can be sent, which checks resource availability (resources would typically include link bandwidth, buffer space in the router, CPU resources, etc.) along the particular part of the path it is responsible for, and either grants the request (and reserves the resources), denies it, or, optionally, grants a reduced version of the request. Typically, such QoS entities may be located at least in the access routers and the agents which perform binding updates, additional entities are of course possible. How to implement such QoS entities and how to enforce such reservations is beyond the scope of this paper; here, the mechanisms of conditionalizing the binding update is discussed. Since most handoffs are assumed to be local, a QoS solution minimizing the time for QoS (re)establishment may take the advantage of the regional mobility solutions. Furthermore, Hierarchical Mobile IPv6 (HMIPv6) protocol is assumed to be the regional mobility solution within our work. The operation of QoS-conditionalized binding update is as follows. A QoS hop-by-hop option is carried in the message containing the BU option to the MAP -- this message is called BU+QoS message. Each QoS entity between the MN and the MAP (including the MAP) will pass the QoS requirement represented by the QoS option to internal QoS mechanisms and check its resource availability. If resources are available locally, they are reserved and the message will be forwarded along its route. If resources are not available, negative feedback will be provided to the MN by means of an extended Binding Acknowledgement (BA+QoS) message. If a BU+QoS message has reached the switching MAP and passed the local QoS test as well, the binding update will take place (the binding cache in the MAP is updated to reflect the new LCoA) and a positive BA+QoS message is returned to the MN. Otherwise, no handoff is performed and a negative BA+QoS message is returned to the MN. When observing a negative BA+QoS message, intermediate QoS entities can release reservations that could not be granted further upstream. Fu, et al. Expires July 16, 2002 [Page 8] Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002 ____________ | | | CN | |____________| /\ /\ /\ / | \ / _____\/_____ \ / | | \ / | MAP | \ / |____________| \ / /\ /\ \ \ / / (2)\ \(3) \ data / / BU+QoS\ \BA+QoS \ data path1/ _______\/__ ___\_\/____ \path2 | | | | | | | | AR1 | | AR2 | | | |___________| |___________| | | /\ /\ / | \ \ (1)/ /(4) / \ \ BU+QoS/ /BA+QoS / \ \/_______/__\/ / \ | | / --> | MN | <-- |____________| <---------------> Node Mobility Figure 1 - An Example of a QoS-Conditionalized Binding Procedure Figure 1 shows an example of a QoS-conditionalized binding update in a MAP domain. In this figure, the MAP is the switching router, the ARs and the MAP are the only nodes concerned with QoS control. Suppose the data packets between the MN and the CN is sent through AR1 and QoS-guarranteed. Now due to node mobility, a second AR, AR2, is reacheable while AR1 is still available. The MN can then send a so-called QoS-conditionalized Binding Update message (BU+QoS) toward the MAP through AR2, and the MAP will reply with acknowledgement message (BA+QoS). If both AR2 and the MAP are able to fulfil the QoS requirements embedded in the BU+QoS message, the BA+QoS message will be positive and the resources will be reserved in its transmission path. Otherwise it will be negative and the resources will be released. In general, the path between the switching router and the AR may contain several MAPs, as well as DiffServ/MPLS domains and/or IntServ nodes, or combinations of both. QoS entities in such nodes or domains should make admission control decisions based on the QoS option. The QoS Option is a hop-by-hop header extension option and treated as described below. (As an optimization, the new AR could Fu, et al. Expires July 16, 2002 [Page 9] Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002 obtain QoS information from the old AR via context transfer protocols in order to save wireless bandwidth - see discussion in Section 7.7.) In HMIPv6, outside the MAP domain, destination address or source address of any packet to and from MN is marked as the MAP's IP address or MN's RCoA in the MAP domain, not the HoA or LCoA of the MN. Hence, the CN is oblivious of the BA, and a QoS (re-) establishment procedure due to handoff only happens inside the MAP domain. here we only discuss the case of the basic mode of HMIPv6 and the treatment in the extended mode of HMIPv6 needs more investigation. Fu, et al. Expires July 16, 2002 [Page 10] Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002 4. Format of QoS option 1. The format of the QoS object (see Figure 2) follows [7]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | Reserved | Object Length |QoS Requirement| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Max Delay (16-bit integer) ms |Delay Jitter (16-bit integer)ms| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Average Data Rate (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 |Burstiness:Token Bucket Size(32-bit IEEE floating point number)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Peak Data Rate (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Minimum Policed Unit (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Maximum Packet Size (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | | ~ Values of Packet Classification Parameters ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 - Composition of a QoS OBJECT 2. Format of QoS Option - follows [7], except that 3 bits of "Reserved" bits are used to specify whether QoS requirement indicated by this option can be met, how to include desired and/or accepted QoS and up- and/or downstream QoS. (see Figure 3): 1. If the "F" bit is set, this means "QoS can not be met", otherwise "(up to current node) QoS can be met". 2. If the "D" bit is set, this means "only downstream QoS are specified", otherwise "both upstream and downstream QoS are specified. 3. If the "A" bit is set, this means "both acceptable QoS and desired QoS are specified", otherwise "only desired QoS is specified". Fu, et al. Expires July 16, 2002 [Page 11] Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 |0|0|1| Opt Type| Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 |F|D|A| Reserved| DW- Desired QoSObj {, UP- Desired QoSObj} ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | | ~ {, DW- Accepted QoSObj}{, UP- Accepted QoSObj} in TLV format ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 - Composition of QoS OPTION Fu, et al. Expires July 16, 2002 [Page 12] Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002 5. Detailed description of QoS-conditionalized binding update procedure 5.1 Mobile node The MN in our scheme behaves different to the one in the HMIPv6 basic mode when responding to a few events: detecting connectivity to a new AR, loosing connectivity to an existing router, and the arrival of BA+QoS. As a simplification, the processing here assumes that whenever a new AR becomes available, a binding update to this AR should be attempted. In reality, more sophisticated schemes may be implemented (e.g., only sending BU+QoS messages when the link quality to the old AR is deteriorating, keeping track of a list of prospective ARs, etc.); also, immediately obtaining an IP address from any new AR might not be cost-efficient, these are out of the scope of this draft. Note that the treatment of acceptable/desirable QoS is also not discussed here; the necessary modifications are reasonably straightforward. The MN detects the connectivity to a new AR either by listening to Router Advertisements or performing Router Solicitation as specified in [4]. After MN acquires new local IP address (LCoA), it should compose a BU+QoS message and send it towards MAP (via new AR). If the MN receives a BA+QoS message, it should check whether the "F" bit is set in the QoS Option. If not set, the AR which this BA+QoS message passing through should be set as the default route for future data transmission. Otherwise no action is required: either still use old AR, or go with no QoS guarantees. To optimize the QoS-conditionalized binding update procedure, the MN may maintain at least two lists of LCoA-AR-QoS pairs for which are available in connectivity and for which the MN has received positive BA+QoS messages. Once a BU+QoS message is responded with a negative BA+QoS, the QoS requirements embedded in the next BU+QoS message may differ from the previous one, e.g., the desired level of QoS could be reduced. There are several possibilities of how the number of available access routers could influence the setting of lowest acceptable QoS. E.g., acceptable QoS could be a function of the number of available ARs and/or the MN's speed. 5.2 Router Upon receiving a BU+QoS message, a router should check whether the "F" bit is set. If not set, it should ask QoS entity for resources. If sufficient resources are not available, this router should set "F" bit in QoS packet. If this router is the switching MAP, the MAP should compose a BA+QoS packet from the BU+QoS packet, with "F" bit set as in the BU+QoS packet and return the BA+QoS message to the MN. Fu, et al. Expires July 16, 2002 [Page 13] Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002 If "F" bit is not set, the switching MAP should update the MN's binding to the new LCoA. It may compose a negative BA+QoS message and send it along the old path to release reservations. A MAP with MAP functionalities, but is not the switching MAP, behaves like a normal router. Upon receiving a BA+QoS message, a router should check whether the "F" bit is set. If set, it should ask QoS entity for releasing any possibly reserved resources. Note that a router MUST NOT interpret the QoS option inside a BA+QoS as request for new resources, even when the "F" bit is not set. Rather, this QoS option is interpreted as providing more up-to-date information about a flow for which reservations have already been made. Note that in order to correctly process the BA+QoS message, all routers concerned with QoS management, such as MAPs, ARs, and possibly DiffServ and MPLS edge routers (ER), as well as IntServ nodes need to maintain state for each flow. However, this is not an additional burden to these entities as they need to maintain this same state anyway: MAPs must maintain the binding cache, and also the AR has to keep information, including QoS information, for each MN. ERs typically act as aggregation routers, i.e. they (as opposed to interior routers) still know individual flows, just as IntServ nodes do. Nevertheless, this constitutes an argument in favor of restricting QoS control to AR and MAP. There are two ways to release the resources that have been re- served. One is to release them explicitly via a message carrying a QoS option with "F" bit set. Another is to use soft-state for the QoS reservations and to rely on time-out of the reservation along an unused path. The timer of QoS option may differ from that for the BU option; optimal choices for these values are unknown as of this moment. Fu, et al. Expires July 16, 2002 [Page 14] Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002 6. Comparison of our scheme with the requirements draft In [2], a number of requirements are listed which a QoS solution for Mobile IP has to satisfy. The following sections discuss how the conditionalized binding update presented in this draft compares with these requirements. 6.1 Performance requirements A QoS solution o MUST minimize the interruption in QoS at the time of handoff - our scheme minimizes this interruption, because it provides the possibility to check for and reserve resources simultaneously with the binding update, and also allows for negotiating with several ARs to find one that can meet the QoS required. o MUST localize the QoS (re)programming to the affected parts of the packet path in the network - satisfied with HMIPv6. o MUST provide means to release any QoS state along the old path that is not required after handoff - one possibility is to let the MAP initiate the release request for the old path; the other is timing-out: as BUs time out, the QoS state along the old path will be released. 6.2 Interoperability requirements A QoS solution o MUST be interoperable with other mobility protocols related to mobile IP. This is an open issue, however, the scheme as such could be applicable to other mobility protocols as well. o MUST be interoperable with heterogeneous QoS paradigms. As discussed in Section 5 above, our scheme interoperates with DiffServ, IntServ and MPLS. Since its task is just carrying QoS information which is then used by QoS entities to do whatever the QoS paradigm requires, it should in fact interwork with any QoS paradigm. 6.3 Exception condition requirements A QoS solution o MUST provide means to handle a situation in which the old QoS Fu, et al. Expires July 16, 2002 [Page 15] Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002 agreement cannot be supported after handoff - our scheme informs the MN the old QoS requirements cannot be met via a negative BA. The MN may initiate another BU with another AR or the same AR with lowered QoS requirements or stay attached to the old AR. 6.4 Miscellaneous requirements A QoS solution o SHOULD be able to support QoS along different potential paths, such as route-optimized path between the MN and the CN, triangle route via HA, temporary tunnels between old and new access router. This is an open issue and requires additional investigation. o MAY provide information to link layer to support required QoS, such as acceptable IP packet loss ratio for wireless link. Not supported, extensions are conceivable. 6.5 Obvious requirements A QoS solution MUST satisfy o scalability: the major scalability concern in this scheme is the need to maintain state in intermediate entities. However, as most of the are MAP and hence must maintain binding update mappings, they do keep state on a per-flow level anyway. Hence, this scheme does not introduce any new scalability problems. o security - see Section 8 o conservation of wireless bandwidth - apart from obtaining a new LCoA address from a new basestation/access router, wireless bandwidth is used only to send BU+QoS and to receive BA+QoS. It can, however, be decreased further by transferring context from old AR to new AR as described in [3] and as discussed later in Section 7.7 o low processing overhead on mobile terminals - MN need to insert QoS object into BU and must be able to interpret negative BAs (but compare discussion about the use of context transfer in Section 7.7). o hooks for authorization and accounting - needs further Fu, et al. Expires July 16, 2002 [Page 16] Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002 investigation o robustness against failure of any MIP-specific QoS component in the network - since we use the QoS option in a context of HMIP, if (one) MAP fails, the QoS option will be delivered further without any treatment for QoS option (esp. if a destination option for QoS option is used). This needs further investigations. Fu, et al. Expires July 16, 2002 [Page 17] Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002 7. Further discussion 7.1 QoS control in entities unaware of the BU/BA options In our discussion, we distinguish two kinds of QoS-controlling entities. Both of them are able to interpret the QoS object. While one kind is capable of recognizing the BU/BA options in order to decide what kind of message arrived, and are also capable of generating (negative) BAs, the other kind of QoS-controlling entity do not know about BUs and BAs. Such an entity bases its behavior only on the QoS option along with the QoS objects, but cannot use the BU/BA option to decide how to handle a message. In particular, it must be able to distinguish a QoS option for a flow that has not yet established any reservations at this particular entity from a flow that already has a reservation. As described in detail in Section 5, our mechanism works correctly with both kinds of QoS-controlling entities. 7.2 Sending QoS-conditionalized binding messages via a non-default route To minimize the latency of QoS re-establishment interval, the MN should send the BU+QoS messages via the "trial" access router while the previous access router is still used. In case a negative BA+QoS is generated by the MAP it is also necessary to send via the non- default route (towards the MN via the "trial" access router). IPv6 specification [5] doesn't specify this usage. To overcome this, routing header may be used. The MN may add a routing header (the MAP address as destination address) in its BU+QoS messages while setting the destination address as the "trial" access router; and when necessary, the MAP may send its negative BA+QoS messages towards the MN. 7.3 Signaling downstream QoS requirements One concern is how to include QoS requirement for downstream traffic into a message carrying Binding options. In an end-to-end signaling scenario, e.g., when using standard Mobile IP, the QoS information for the downstream traffic can easily be provided by the CN. When using a hierarchical architecture, however, the downstream traffic information must still be available for the new path between the MAP and the MN. Requesting this information from the CN would defeat the purpose of using hierarchical mobility schemes in the first place. On the other hand, making this information available in the router might be feasible with some QoS paradigms that provide per-flow QoS, yet QoS schemes that only work on aggregated traffic schemes should not burden intermediate nodes with maintaining information about individual traffic flows (rendering the entire idea of aggregate flow Fu, et al. Expires July 16, 2002 [Page 18] Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002 treatment useless) - and this information would have to be present in every router that would potentially be a MAP. Hence, the downstream QoS description cannot be obtained from the CN, neither can intermediate routers be expected to store this information for every flow. Rather, the downstream traffic QoS requirements should be provided along with the upstream requirements in the BU+QoS message. The MN could know this information (e.g., from some application-level negotiation of QoS) but how to get it is out of the scope of this document. The main disadvantage of this approach is that the BU packets become larger. While this should not pose much of a problem in the wired backbone network, it could be considered a serious drawback when the BU+QoS message has to be communicated over the wireless link. There are some possible remedies to this problem which will be discussed later. Therefore, it is reasonable to assume that the MN also specifies the downstream QoS requirements in the BU+QoS (the MN should be capable of providing this information, e.g., derived from application-level negotiation protocols). While this does increase the amount of protocol data of the solution proposed here, the possibility to reduce state information in the network appears to be the outweighing concern - mechanisms like transferring context from old to new AR (e.g., [3], see discussions later) can additionally reduce wireless bandwidth requirements. The treatment of up- and downstream QoS information in the routers directly follows [7]. 7.4 Upgrading the level of QoS Another concern is which level of QoS requirements is appropriate for a MIPv6 QoS solution. When the MN requests (in preparation of a handoff) a QoS along the new path that is larger than the one used on the old path, the switching router alone can no longer decide whether or not this request should be accepted (assuming that it would be possible to provide this level of QoS on the new path). This inability is partly caused by the need to contact the CN to check whether it agrees as well, whether the CN's access network can provide such an increased capacity (otherwise, upgrading the MN's local reservation would make little sense), and it may also involve inter-domain QoS (re-)negotiation out of the (highest) MAP domain. Therefore, we suggest to consider during a handoff only the problem of maintaining the currently used QoS (and possibly specifying an acceptable lower limit) and to treat the problem of upgrading to higher service levels separately (the main points involved here would be authorization/charging, providing indication of the availability of more resources to the application, and application-level QoS Fu, et al. Expires July 16, 2002 [Page 19] Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002 renegotiation). 7.5 Possibility of changing from a hop-by-hop option to destination option The feature of hop-by-hop option for the QoS option obviously will be a drawback for a fast handoff. Hence, a solution trying to use a destination option may be favorable. If the AR is also a MAP, the MN may specify a destination for the QoS option (destined to the AR) and the AR may relay it as the destination option (destined to the next hop MAP) again, and so forth. Then the QoS option can be carried as a destination option in the whole QoS-conditionalized binding procedure. Using such a destination option is straightforward if the MAPs are the only entities concerned with QoS control. Typically, at least the AR would also perform QoS control without necessarily being a MAP as well. An important case would be when the AR is the only QoS control entity besides the MAPs. Here, the QoS option can be transmitted from the MN to the (switching) MAP in a hop-by-hop way, but it would be possible for the AR to change the QoS option from a hop-by-hop option to a destination option, destined to the next upstream MAP. Upon receiving this destination option and necessary work regarding QoS management, a MAP between AR and the highest MAP may encapsule the BU message again to destine it to the hierarchically next higher MAP. When the highest MAP finally receives the BU+QoS message, it will issue a BA+QoS message and follow a reverse procedure (from destination option to a hop-by-hop option). 7.6 Handling intermediate reservations As the process of accepting a binding update is a distributed one in which several routers can participate, it is necessary to further specify in detail how this decision process should take place. Specifying such distributed processing is further complicated by the fact that multiple binding updates from different MNs could be processed at the same routers with only small temporal offset. The main issue is how a router handles a BU+QoS message that it could serve, but that also has to be passed upstream onto other routes in order to check whether they can also provide the requested QoS. In general, this is a distributed commit problem and can be solved with well-known techniques, requiring a number of message exchanges e.g., [10]. Here we are interested in faster approaches that should ideally work using only one round trip from MN to switching router and back; sacrificing some optimality aspects is unavoidable in such schemes. Two main schemes are conceivable: optimistic or postponed Fu, et al. Expires July 16, 2002 [Page 20] Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002 reservation. 7.6.1 Optimistic reservation An intermediate router considers the requested QoS as actually being reserved, optimistically assuming that all other routers along the way can also grant the request. Reserving the capacity is the correct decision if all upstream routers can also grant the request. If any upstream router cannot comply with the request, a NACK is returned and the "lower" routers have to release the spuriously made reservation. This optimistic reservation approach can be problematic if a lower router made a reservation that will later be denied and has had to reject other reservation requests that could have been granted upstream. However, if the round-trip time for BUs is short (which is reasonable in an access network using HMIPv6) and if there is less traffic (relative to the available capacity) towards the core than there is at the edges of the network, this situation should be rather improbable and might hence be regarded as an acceptable risk (in typical networks, the bottlenecks are likely to be closer to the edge than towards the core). 7.6.2 Postponed reservation In order to circumvent the problems of optimistic reservations, one possibility would be to postpone the actual reservation: when receiving a BU, a router only checks the instantaneous availability of resources, without actually reserving anything when forwarding the BU. Actual reservation only takes place when positive acknowledgements are returned from upstream routers. The problem with such postponed reservations is that a BA+QoS might not be able to actually reserve capacity because of overlapping BU/ BA messages from different MNs. In such a case, the switching MAP has incorrectly reserved capacity and, even worse, performed a handoff to a path that is not QoS-guaranteed. This is a rather serious drawback, and we hence propose to use an optimistic reservation scheme. 7.7 Handling large signaling packets over the wireless link At the beginning of an application, QoS information needs to be transported over the wireless link in order to enable end-to-end application-level negotiation of QoS requirements. However, as both wireless communication capacity and processing power on mobile terminals are precious resources, once this QoS information has been established, it would be desirable to minimize the amount of QoS Fu, et al. Expires July 16, 2002 [Page 21] Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002 information traversing the wireless link and the amount of processing the MN has to perform. A number of different approaches exist for this problem in general: compression schemes, moving protocol functionality away from MNs onto proxies that reside in the wired network; in the present context, context transfer schemes appear to be particularly useful [3]. In particular, it should be feasible to assume that the old AR has the QoS requirement information for each of its MNs. When an MN wishes to associate itself with a new AR, it could simply inform the new AR of the old AR's identity as well as of its own address (permanent and temporary address should work). The new AR then fetches the QoS requirement description from the old AR and initiates the BU process on behalf of the MN; acknowledgements would still have to be provided eventually to the MN. Alternatively, the binding update process could also be initiated by the old AR. Here, the MN (or even the new AR) becomes aware of a new address it wants to use. The MN asks the old AR to initiate a binding update procedure for this new address. The old AR contacts the corresponding new AR, providing QoS requirements, and the new AR constructs a BU message to be sent in the usual fashion. As soon as the BA arrives, the new AR informs the MN that the new address is no valid and that this new link should now be used. Negative feedback should be provided via the old AR. This scheme is particularly attractive if the MN is not capable of maintaining two different link layer bindings (i.e., communicate with both old and new AR simultaneously). Choosing between directly transmitting BU/QoS information and transferring context from another AR depends on a number of factors (delay, bandwidth and cost of both the wired and the wireless link and the respective weights assigned to them). Additionally, applying context transfer is orthogonal to different ways of initiating the actual handoff (controlled by the MN, the old or the new AR). However, this question requires additional investigations. Fu, et al. Expires July 16, 2002 [Page 22] Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002 8. Security considerations The QoS scheme described in this document raises the following threats, mainly concerning the integrity of BU/BA and QoS options: o An attacker might possibly try to forge or replay BU messages with specific QoS options in the name of another entity in order to either just harm that entity or to even gain economic benefits as QoS reservations may imply some form of billing consequences. o An attacker might try to delay, delete, or modify passing BU+QoS messages (especially, the QoS options), e.g. in order to reduce the desired QoS specification of another entity which might possibly affect its own QoS requests or the QoS requests of a third entity it wants to support in a positive manner. The above threats SHOULD be averted by protecting the integrity of BU+QoS messages with some kind of cryptographic signature, e.g. as it is done with Mobile IP registration messages. However, this requires the availability of appropriate key material in the signing and the checking entities. It is out of the scope of this specification and for further study if this can be realized with a hop-by-hop approach, that is every intermediate node that processes BU+QoS messages or just the QoS options checks their integrity and signs the outgoing BU+QoS / QoS options, or an end-to-end approach which could, for example, require the last MAP to check the integrity of the mobile node's original BU+QoS message and its QoS option(s). Fu, et al. Expires July 16, 2002 [Page 23] Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002 9. Acknowledgement The authors are grateful to Tianwei Chen, Axel Neumann, Hemant Chaskar and Hesham Soliman for their valuable comments to an earlier version of this draft. Fu, et al. Expires July 16, 2002 [Page 24] Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC (Best Current Practice) 2119, March 1997. [2] Chaskar(Ed.), H., "Requirements of a QoS Solution for Mobile IP", Internet Draft, work in progress, draft-ietf-mobileip-qos- requirements-01.txt, July 2001. [3] Koodli, R. and C. Perkins, "Context Transfer Framework for Seamless Mobility", Internet Draft, work in progress, draft- koodli-seamoby-ctv6-00.txt, February 2001. [4] Johnson, D. and C. Perkins, "Mobility Support in IPv6", Internet Draft, work in progress, draft-ietf-mobileip-ipv6- 15.txt, November 2001. [5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [6] Soliman, H., Castelluccia, C., El-Malki, K. and L. Bellier, "Hierarchical MIPv6 mobility management", Internet Draft, work in progress, draft-ietf-mobileip-hmipv6-04.txt, July 2001. [7] Chaskar, H. and R. Koodli, "A Framework for QoS Support in Mobile IPv6", Internet Draft, work in progress, draft-chaskar- mobileip-qos-01.txt, March 2001. [8] Thomas, M., "Analysis of Mobile IP and RSVP Interactions", Internet Draft, work in progress, draft-thomas-seamoby-rsvp- analysis-00.txt, Feburary 2001. [9] Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [10] Lyon, J., Evans, K. and J. Klein, "Transaction Internet Protocol Version 3.0", RFC 2371, July 1998. [11] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [12] Braden, B., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994. [13] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. Fu, et al. Expires July 16, 2002 [Page 25] Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002 Authors' Addresses Xiaoming Fu (corresponding author) Technical University Berlin Sekr.FT 5-2, Einsteinufer 25 Berlin 10587 Germany Phone: +49-30-314-23827 EMail: fu@ee.tu-berlin.de Holger Karl Technical University Berlin Sekr.FT 5-2, Einsteinufer 25 Berlin 10587 Germany Phone: +49-30-314-23826 EMail: karl@ee.tu-berlin.de Andreas Festag Technical University Berlin Sekr.FT 5-2, Einsteinufer 25 Berlin 10587 Germany Phone: +49-30-314-79171 EMail: festag@ee.tu-berlin.de Guenter Schaefer Technical University Berlin Sekr.FT 5-2, Einsteinufer 25 Berlin 10587 Germany Phone: +49-30-314-23836 EMail: schaefer@ee.tu-berlin.de Fu, et al. Expires July 16, 2002 [Page 26] Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002 Changpeng Fan Siemens AG ICM N MC ST3 Berlin 13623 Germany Phone: +49-30-386-36361 EMail: changpeng.fan@icn.siemens.de Cornelia Kappler Siemens AG ICM N MC ST3 Berlin 13623 Germany Phone: +49-30-386-32894 EMail: cornelia.kappler@icn.siemens.de Mirko Schramm Siemens AG ICM N MC ST3 Berlin 13623 Germany Phone: +49-30-386-25068 EMail: mirko.schramm@icn.siemens.de Fu, et al. Expires July 16, 2002 [Page 27] Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). 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. Fu, et al. Expires July 16, 2002 [Page 28]