IETF NSIS Working Group Cedric Westphal INTERNET DRAFT Hemant Chaskar 24 June 2002 Nokia Research Center QoS Signaling Framework for Mobile IP draft-westphal-nsis-qos-mobileip-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 made obsolete 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. Copyright Notice Copyright (c) The Internet Society (2002). All rights reserved. Conventions used in this document The key words ``MUST", ``MUST NOT", ``REQUIRED", ``SHALL", ``SHALL NOT", ``SHOULD", ``SHOULD NOT", ``RECOMMENDED", ``MAY", and ``OPTIONAL" are to be interpreted as described in RFC 2119. Abstract This draft provides a framework for QoS signaling that is optimized for Mobile IP handoffs. It covers the horizontal signaling between access routers (ARs) as well as the vertical signaling along the packet data path, both of which are triggered by handoff of mobile node (MN). The key design goals are wireless bandwidth economy, fast QoS establishment along the new data path after handoff and secure protocol operation. Westphal, Chaskar Expires December 2002 [Page 1] Internet Draft QoS Signaling Framework for Mobile IP June 2002 Table of Content 1. INTRODUCTION...................................................3 2. OPTIMISZED QOS SIGNALING TOOLS: OVERVIEW.......................4 3. EDGE QOS SIGNALING.............................................4 4. DATA PATH QOS SIGNALING........................................5 4.1. Uplink QoS...................................................6 4.1.1. Launching the QoS signaling packet:........................6 4.1.2. Updating/creating flow states in intermediate nodes:.......7 4.1.3. Tearing down QoS along the segment of path that is not required after handoff:...........................................8 4.1.4. Confirming the QoS establishment along the new segment of path..............................................................9 4.1.5. Forwarding QoS signaling packet beyond crossover router....9 4.1.6. Authenticating the QoS signaling packet....................9 4.2. Negotiation.................................................12 4.3. Downlink QoS................................................13 5. GENERIC QOS SIGNALING.........................................14 6. REFERENCES....................................................15 7. AUTHORSÆ ADDRESSES............................................16 Westphal, Chaskar Expires December 2002 [Page 2] Internet Draft QoS Signaling Framework for Mobile IP June 2002 1. INTRODUCTION As the Internet evolves from the best-effort network to one supporting multimedia communication, it becomes important to be able to signal QoS requirements of applications to the Internet. A number of different scenarios and requirements for QoS signaling are given in [1]. The scenarios mentioned therein cover a broad scope, such as, among others: - Terminal mobility: The QoS signaling must cope with handoff of end terminal, possibly between network domains with heterogeneous QoS technologies. - Cellular networks: The QoS signaling must be able to integrate with cellular access technologies such as, for example, UMTS network. - QoS reservation from access to core network: The signaling should allow for aggregate QoS provision and negotiation between access and core networks. - Administrative boundaries: It should be possible to signal QoS over the administrative boundaries. Due to the conflicting requirements imposed by these different usage environments (for instance, there is a possible conflict between a lightweight signaling mechanism required over the wireless link and a reliable and robust mechanism required to provision QoS for aggregate traffic in the core), it is unlikely that the same QoS signaling protocol can be used in all environments. An effective solution would be a ``QoS signaling toolkit", wherein each tool is optimized for a particular situation. This draft describes a framework for QoS signaling tools that are optimized for Mobile IP handoffs. We cover the horizontal signaling between access routers (ARs) as well as the vertical signaling along the packet data path, both of which are triggered by handoff of mobile node (MN). The network QoS architecture assumed here is as follows: MN --- AR ---QC-----QoS Domain(s)-----QC----- CN | | | | | QC \/ | | MN ----AR----------------| Westphal, Chaskar Expires December 2002 [Page 3] Internet Draft QoS Signaling Framework for Mobile IP June 2002 The QoS signaling follows data path from the MN to the correspondent node (CN) through a set of QoS Controllers (QCs). The QCs could be all the routers on the path, or a subset of these that effectively controls the QoS over the whole path. Among others, QCs perform functions such as multi-field packet classification, admission control etc. This is similar to the architecture considered in [2]. The terms QC and router are used interchangeably in this document. 2. OPTIMISZED QOS SIGNALING TOOLS: OVERVIEW The QoS signaling tools that we describe here cater to the following situations: @ Edge QoS Signaling: This signaling covers signaling between MN and its AR as well as horizontal signaling between ARs. The wireless link to MN induces the requirement of bandwidth economy on the signaling between the MN and AR. Signaling between ARs imposes requirements similar to context transfer framework. @ Data Path QoS Signaling: This signaling covers the signaling along the data path to establish, tear down or modify QoS. The desire for seamlessness of handoff induces the requirement of speed on the signaling used to establish QoS after handoff. Further, since there will be frequent handoffs in future mobile networks, it is required to keep the overhead of handoff-induced QoS signaling at the minimal possible level. @ Generic QoS Signaling: When there are less bandwidth constraints or time constraints, another set of rules can be used with increased reliability, robustness or redundancy. Here, we do not discuss this tool in detail, rather only point out the placeholder for it. Each of these bullets is detailed in the following sections. 3. EDGE QOS SIGNALING The main tasks of the Edge QoS Signaling protocol are to initiate QoS, negotiate QoS, transfer QoS and terminate QoS. Edge QoS Signaling can be based on the concept of QoS profile Type (QPT) and the QoS objects defined in [6] and [7]. The QPT defines the format for the parameters that are submitted into its accompanying QoS object. A QPT and its associated QoS object allow the consecutive ARs to which the MN attaches to share the QoS information regarding Westphal, Chaskar Expires December 2002 [Page 4] Internet Draft QoS Signaling Framework for Mobile IP June 2002 the flow without the MN transmitting it over the air interface. Edge QoS Signaling can use the context transfer signaling. (i) QoS initiation: Assuming that the MN has L3 connectivity with AR, and would need some specific QoS for an application, the MN sends a QoS initiation message to the AR. This message is an ICMP Context INitiation (CIN) message. It contains the QPT requested by the MN. Upon reception of this QPT, the AR sets up the QoS on behalf of the MN, possibly using Generic QoS Signaling protocol. This also results in a QoS context establishment at the AR. Depending on whether the AR exercises admission control, it sends an acknowledgment to the MN. Acknowledgment may be requested by the MN on the basis of the QoS requirement field of the QoS object. Acknowledgment is in the form of an ICMP message (SHAK) with a QoSAck suboption (QoSAck-SHAK). If the QoS requested by MN falls under a default profile type, then the MN just sends a packet with a QPT option and no specific bandwidth or peak rate parameters. The AR then creates the proper request on behalf of the MN. (ii) QoS negotiation: The AR receives from the network the available QoS level that it can offer to the MN, be it a different DSCP or a lesser amount of bandwidth. This is communicated to the MN by the AR through the QoSAck suboption in the ICMP SHAK message. The QoSAck can specify the available QoS from the network to the MN. The MN can then accept this or refuse this. (iii) QoS transfer: In the event of handoff, QoS context created in the AR is transferred to the new AR. For this, ICMP-based QoS context relocation signaling is used. It is described in [7]. No extra signaling is thus required from the MN over the wireless link than the already existing signaling for context transfer. (iv) QoS release: If the MN wishes to release a QoS provision, it can do so by requesting a null QPT for the flow it wants released in a CIN message. 4. DATA PATH QOS SIGNALING Context transfer only provides a horizontal signaling between the consecutive ARs. A vertical signaling MAY be needed to establish QoS along the new data path after handoff. It is also required to tear down QoS along the segment of the old data path that is not used after handoff. To effect QoS establishment as fast as possible, the QoS signaling should be coordinated with the mobility signaling (see for example [5]). The asymmetric nature of the handoff (MN changes point of attachment, not the CN) implies a different treatment for the uplink QoS and the downlink QoS. Westphal, Chaskar Expires December 2002 [Page 5] Internet Draft QoS Signaling Framework for Mobile IP June 2002 Also, note that both uplink and downlink packet paths may get affected even if only one of the end nodes undergoes IP-level handoff. In a number of cases, handoff changes only a small segment of end-to-end packet path near one of the extremities. Then, the overhead of QoS signaling processing on the unaffected part of the path needs to be kept at minimum. Finally, security aspects need to be considered so as to prevent a malicious node from spoofing the handoff-induced QoS establishment or tear down. The Data Path QoS Signaling described below takes into account above aspects of QoS establishment (see [3]) in response to handoff. 4.1. Uplink QoS 4.1.1. Launching the QoS signaling packet: QoS signaling for uplink SHOULD be initiated by the new AR upon receiving the QoS context from the previous AR. This is possible when the QoS context transfer is executed successfully. For this, the new AR launches the QoS signaling packet towards the CN. However, if context transfer fails for some reason, the MN MUST launch the QoS signaling packet from the new CoA. This packet SHOULD be launched as soon as the MN is ready to send packets to CN from the new care-of address (CoA). This ensures that the QoS establishment occurs in time for most of the data packets that would be sent from the new CoA. The QoS signaling packet MUST be formatted so that every node that needs to examine the flow-specific QoS information has an opportunity to process this packet. One way to achieve this is to include the QoS information to be carried in this packet as an IPv6 hop-by-hop option. Another way would be to assign a protocol number for such packet in IPv6 main header and include the QoS related information as the packet payload. Other alternatives are possible too. The QoS signaling packet MUST carry the following information in it. Pieces of this information may either be placed in dedicated fields in payload or should be inferable from the parameter values in certain header fields. For example, CoA of the CN can be obtained from the destination IP address in the packet header. - QoS requirements of the flow - Classifier parameters that allow intermediate nodes to identify the packets of the flow in order to offer specific forwarding treatment. According to [4], this information amounts to the triplet (IPv6 flow label, MN new CoA, CN CoA). Westphal, Chaskar Expires December 2002 [Page 6] Internet Draft QoS Signaling Framework for Mobile IP June 2002 - QoS session identification: This information is necessary to identify a flow despite the changes in CoA of MN. Further, a specific method, described below, of generating QoS session IDs at the MN is used as a security measure against the spoofing attacks. The QoS session identification information consists of (i) QoS session ID prior to handoff (called ``previous QoS session ID"), (ii) QoS session ID after handoff (called ``new QoS session ID"), (iii) QoS flow public key, (iv) sequence number. The QoS session ID is generated as the signature of the combination of the CoA of the MN and a sequence number value at MN using the MN's private key. The sequence number at the MN is incremented for every QoS signaling packet launched. Note that MN may need to provide the new QoS session ID to new AR so that the latter can include it in the QoS signaling packet. - An optional signature on the whole immutable parameters, to ensure their integrity, using the private key of the MN. Finally, there MUST be space for mutable parameters in the QoS signaling packet (see below for the purpose of this). 4.1.2. Updating/creating flow states in intermediate nodes: In the following description, we assume that the router agrees to provide the QoS requested in the signaling packet. On the other hand, if the offered QoS is different from the requested QoS, a negotiation procedure may need to be performed. Negotiation procedure is described later. Every router on the path (that needs to examine the flow-specific QoS information) checks whether the previous QoS session ID in the QoS signaling packet matches that associated with one of the existing flow states at the router. A flow state in the router contains the current QoS session ID of the flow, the associated QoS flow public key, the current classifier parameters and the current sequence number. (i) If there is no match, the router creates a new flow state and stores in it the new QoS session ID contained in the signaling packet. This flow state uses (IPv6 flow label, MN new CoA, CN CoA) to classify the packets of the flow. It stores the QoS flow public key and the sequence number from the QoS signaling packet in the flow state. The router also programs the requested QoS forwarding treatment. Thus, the subsequent packets of the MN traversing this router, which are initiated from the new CoA, are offered the corresponding forwarding treatment. Westphal, Chaskar Expires December 2002 [Page 7] Internet Draft QoS Signaling Framework for Mobile IP June 2002 (ii) On the other hand, if there is a match, the router updates the existing flow state with the new classifier parameters indicated in the QoS signaling packet, namely, (IPv6 flow label, MN new CoA, CN CoA). It also replaces the old QoS session ID and the old sequence number with the new QoS session ID and the sequence number from the QoS signaling packet. After the flow states are created/updated, the router extracts the IP address of the previous router that processed the QoS signaling packet and a new cookie (such as random number) generated by this previous router (available in the specified mutable fields of the signaling packet) and stores them along with the flow state. The previous router IP address is later used to retrace the packet path for tearing down the QoS, while the cookie is used to authenticate the future TEAR DOWN messages (see Section 4.1.3). It then forwards the QoS signaling packet to the next router after inserting its own IP address and a new cookie in the above-mentioned mutable fields. On crossover router (see below) to CN path, the router also includes its previous cookie in the specified mutable field of QoS signaling packet. Every router on this path compares the previous cookie included by previous router in the signaling packet with the cookie value stored in its flow state. If they match, authentication of QoS signaling packet is deemed successful at those routers. 4.1.3. Tearing down QoS along the segment of path that is not required after handoff: A router identifies itself as a ``crossover router" if it has an existing flow state with the QoS session ID same as the previous QoS session ID that is contained in the QoS signaling packet. The crossover router authenticates the QoS signaling packet as described later in Section 4.1.6. If the authentication succeeds, the crossover router sends TEAR DOWN message to tear down QoS along the segment of the old packet path (old AR to crossover router) that is not required after handoff. This message is forwarded from the crossover router to the old AR of MN. The IP addresses of the previous routers (that processed the QoS signaling packet) stored along with the flow states in routers are used to retrace this packet path from crossover router to old AR. The TEAR DOWN message sent from a router to its previous (QoS) hop router, must also contain the cookie of the previous (QoS) hop router that is stored in the flow state at the originating router. The previous (QoS) hop router ensures that this cookie is the same as that inserted by it earlier in the QoS signaling packet. Thus, cookies are used to authenticate the TEAR DOWN messages on successive (QoS) hops. This mechanism safeguards against malicious nodes sending TEAR DOWN messages to routers for disrupting the existing QoS of the MN. Note that, even though TEAR DOWN messaging happens between routers, Westphal, Chaskar Expires December 2002 [Page 8] Internet Draft QoS Signaling Framework for Mobile IP June 2002 an authentication mechanism such as above is still needed. It foils the attacks of the following kind. Consider a QC R1 that had forwarded the QoS signaling packet before, and let R2 be the next QC downstream to R1. Now, R1 and R2 could be more than one IP hops away, and hence, R1 may not know that R2 is the next QC downstream to it. In other words, a malicious node may send TEAR DOWN message to R1, and normally, R1 has no way to detect that it has not come from R2. The cookie-based mechanism described above enables such detection and foils the attacks. On the other hand, if authentication of QoS signaling packet fails at the crossover router, it sends TEAR DOWN message as described above to tear down QoS along the segment of the packet path (new AR to crossover router) along which new flow states were just established. Again the cookies are used for authenticating this TEAR DOWN message. 4.1.4. Confirming the QoS establishment along the new segment of path Upon successful authentication, the crossover router may also send CONFIRM message to corroborate the flow states along the new segment of the packet path (new AR to crossover router). The IP addresses of the previous routers (that processed the QoS signaling packet) stored along with the flow states in routers are used to retrace this packet path from crossover router to new AR. The cookie-based scheme described above is used to authenticate the CONFIRM messages. 4.1.5. Forwarding QoS signaling packet beyond crossover router Upon successful authentication, the crossover forwards the QoS request to the CN, so that subsequent nodes on the path can update the QoS session ID, sequence numbers, classifier parameters and cookies. It includes a cookie that was distributed during QoS establishment to dispense the next nodes to perform the public key check. The cookie is included as a mutable field and is updated by each QoS controller on the crossover to CN path. 4.1.6. Authenticating the QoS signaling packet Threat analysis: The authentication mechanism described here for the QoS signaling packet (and the cookie-based authentication mechanism described in Sections 4.1.3 and 4.1.4 for the TEAR DOWN and CONFIRM messages) are proposed based on the following threat analysis: First, consider an ideal situation wherein Edge QoS Signaling protocol is Westphal, Chaskar Expires December 2002 [Page 9] Internet Draft QoS Signaling Framework for Mobile IP June 2002 used at the time of flow initiation and for all the subsequent handoffs. The initial AR then creates a QoS session ID (say, simply as a random number) and this is used in future to identify the flow irrespective of the changes in CoA of MN. For every handoff, context transfer executes successfully and new AR launches the QoS signaling packet. Then, QoS session ID never appears on the wireless link, and hence, the malicious node cannot eavesdrop on it. Further, malicious node cannot disrupt the QoS of MN without knowing the QoS session ID. In such an ideal situation, spoofing attacks are practically impossible. However, in practice there might be handoff instances when context transfer fails, and hence, MN has to launch the QoS signaling packet. In this case, QoS session ID would appear on the wireless link allowing malicious nodes to eavesdrop on it. One can always REQUIRE that in this case, MN MUST send QoS signaling packet from itself to AR in a secure tunnel making it impossible to eavesdrop on the QoS session ID. Then again, spoofing attacks are practically impossible. However, if one insists that handoff induced Data Path QoS Signaling MUST be secure even in the light of possibility of the malicious node eavesdropping on the QoS signaling over the wireless link to gather sufficient information so as to spoof the QoS signaling packet, we propose the following mechanism based on QoS session ID generated as the hash of MNÆs CoA and sequence number using the MNÆs private key. (The cookie-based mechanism achieves the same purpose for TEAR DOWN and CONFIRM messages). Authentication at the crossover router: The crossover router performs the authentication of the QoS signaling packet. Authentication is required to ensure that malicious nodes do not spoof the QoS signaling packet thereby disrupting the existing QoS for the MN. Such a spoofing attack could be launched as follows. The malicious node eavesdrops on the previous signaling from MN to determine the current QoS session ID. It then launches a QoS signaling packet with this value as the previous QoS session ID, either from a different CoA or with a reduced QoS requirement. Such an attack can be foiled by the following scheme. The crossover router uses the QoS flow public key stored in the existing flow state to ensure that the new QoS session ID is indeed a signature of the combination of the MNÆs CoA and the sequence number found in the QoS signaling packet. If true, this means that the MN at this CoA does possess the private key, and thus it is the correct MN. Else, the authentication is deemed to have failed. The inclusion of sequence number in calculating the QoS session ID Westphal, Chaskar Expires December 2002 [Page 10] Internet Draft QoS Signaling Framework for Mobile IP June 2002 prevents against a replay attack in which a malicious node eavesdrop on one of the QoS session IDs generated by the MN (say on the same link), and later replays it (possibly from the same CoA that MN held before) after MN departs from the link. Such an attack is foiled by requiring the crossover router to reject (and thereby declare authentication failure) a QoS signaling packet with sequence number not greater than that associated with the existing flow state. With this, for a spoofed signaling packet to be accepted by crossover router, the malicious node must increment the sequence number. But then, the signature of the CoA, sequence number combination would change. The malicious node cannot calculate the correct signature as it does not have MNÆs private key. (Note: Here, QoS session ID is used for two purposes: (i) to identify the flow despite change in CoA of MN, and (ii) as a hash value to authenticate the QoS signaling packet. Alternatively, it is possible to use a separate ID (say, based on home address (HoA)) for flow identification.) Even with these measures, one more spoofing attack possibility (albeit less likely to succeed) still exists. This attack works as follows. Suppose that malicious node and MN are on the same link such as 802.11, and MN has to launch QoS signaling packet from itself. Suppose that MN does so without using secure tunnel between itself and AR. Malicious node eavesdrops on the QoS session ID. It then spoofs the MNÆs CoA and launches another QoS signaling packet containing reduced QoS request. Now, if the QoS signaling packet launched by malicious node overtakes that launched by the MN, it will cause QoS disruption. To foil such attack, one can include the signature of the immutable fields in the QoS signaling packet generated using MNÆs private key in the QoS signaling packet. The crossover router can run the MNÆs public key on the immutable fields and verify their integrity. A malicious node can always launch a spoofing attack with arbitrary value for previous QoS session ID, thereby creating fake flow states in the intermediate routers. However, such a QoS signaling packet can be determined to be a spoofed packet as either one or both of the following tests would fail: (i) CN would not have binding for this CoA, if spoofing attack has been launched from a CoA different from MN's true CoA, (ii) AR to which CN is attached does not have a matching QoS session ID. Note that at least an AR to which CN is attached needs to have a matching QoS session ID. A TEAR DOWN message can then be sent to tear down these fake flow states. Westphal, Chaskar Expires December 2002 [Page 11] Internet Draft QoS Signaling Framework for Mobile IP June 2002 4.2. Negotiation In the above discussion, we assumed that the routers along the new packet path do agree to provide requested QoS to MN. However, in practice, some of them may not agree to provide the QoS requested in the QoS signaling packet, rather offer a reduced QoS. To cope with this situation, we propose a two bit flag in the QoS signaling packet. If the first bit (``negotiation flag") is turned off, it implies that the QoS request is non-negotiable. In other words, if some router cannot offer the requested QoS, it rejects the QoS request and sends TEAR DOWN message to tear down QoS along the uplink packet path from MN to this router in a similar way as described in Section 4.1.3. It also sends another TEAR DOWN message towards CN. This TEAR DOWN message serves the purpose of tearing down QoS along the path from crossover router to CN. This TEAR DOWN message MUST contain sufficient information from the QoS signaling packet (new CoA, new sequence number and new QoS session ID) to enable the crossover router to authenticate the TEAR DOWN message (the authentication of TEAR DOWN message at crossover router works in a similar way to that of a QoS signaling packet as described in Section 4.1.6). The crossover router also sends TEAR DOWN message to tear down QoS along the old segment of the uplink packet path as described in Section 4.1.3. The crossover router also forwards the original TEAR DOWN message towards CN to tear down QoS along the path from itself to CN. A cookie-based authentication, as described in Section 4.1.5, is used for this TEAR DOWN message. On the other hand, if the negotiation flag is turned on, it implies that the request is negotiable. In this case, the router may offer a reduced level of QoS. The second bit in the flag (``notification flag") is used to indicate whether MN wants to be notified about the reduced QoS offering at intermediate nodes. When the notification flag is turned on (and of course, negotiation flag is also turned on), if some intermediate node on the new segment of the uplink packet path cannot offer the QoS requested in the QoS signaling packet, it can offer a reduced QoS and include description of it in the mutable fields of QoS signaling packet. When the crossover router receives this QoS signaling packet and notices that the offered QoS is less than the requested QoS at one of the intermediate routers (and that notification flag is turned on), it sends a copy of QoS signaling packet back towards the MN. Note that this is in addition to the normal processing of QoS signaling packet at the crossover router as described before. MN (or AR acting on its behalf) can thus examine the description of the reduced QoS and may decide to accept it or reject it. If MN decides to reject it, a TEAR DOWN message is sent by MN (or AR acting on its behalf) towards the CN. The TEAR DOWN message SHOULD contain MNÆs CoA, sequence number, a new QoS session ID generated as a hash of first two, and the previous QoS Westphal, Chaskar Expires December 2002 [Page 12] Internet Draft QoS Signaling Framework for Mobile IP June 2002 session ID. The first router (that maintains the flow state) closest to MN authenticates the TEAR DOWN message as described in Section 4.1.6 for the crossover router. The authentication from this router onwards to CN can be cookie-based. If the reduced level of QoS is acceptable, MN may send CONFIRM message. 4.3. Downlink QoS The downlink procedure is similar to the uplink with the following important differences: If applicable (i.e., if the flow has bi-directional QoS requirements), the QoS signaling packet is sent by the AR of CN towards the new CoA of MN as soon as CN is ready to send packets to new CoA of MN (say, immediately after confirming the new CoA of MN). Also, note that QoS session IDs for downlink directions are generated using CNÆs private key. A "crossover router" is identified as follows: When a router (that needs to examine flow specific information) receives and examines the QoS signaling packet and notices that it does not have existing flow state for this flow (after comparing previous QoS session ID in the signaling packet with the QoS session IDs associated with existing flows at the router), it informs the router whose address is found in the previous router field of QoS signaling packet that this previous router was a crossover router. This next router makes a note of the fact in the QoS signaling packet (by setting a specified flag bit) that the crossover router has already been located. This prevents the subsequent routers (which also do not have the existing flow state for this flow), from erroneously inferring that their previous routers were a crossover router. Crossover router sends TEAR DOWN message towards the old CoA of MN. This message is authenticated using cookie-based scheme. The routers along the new packet path from crossover router to the new AR of MN, may or may not provide the requested QoS. In the former case, the new AR sends CONFIRM message to fix the flow states along the new packet path. In the latter case, these routers will offer reduced QoS (if "negotiation flag" is on) and include a description of it in the mutable fields of the QoS signaling packet. The MN (or new AR acting on its behalf) examines this reduced QoS offerings and sends either CONFIRM or TEAR DOWN message towards CN, depending upon whether it accepts or rejects the reduced QoS. The previous router IP addresses stored in the flow states are used to forward CONFIRM and TEAR DOWN messages. TEAR DOWN message must be propagated upto CN. CONFIRM message may be intercepted at the crossover router, but it may also be propagated upto CN. TEAR DOWN and CONFIRM messages are authenticated using cookie-based mechanism described before. In the downlink direction, authentication of QoS Westphal, Chaskar Expires December 2002 [Page 13] Internet Draft QoS Signaling Framework for Mobile IP June 2002 signaling packet (similar to that described in Section 4.1.6) can be performed by the first router (that maintains the flow state) near the CN. Usually, this is an AR of CN. Once this router performs authentication, it sets a flag in the QoS signaling packet to inform the subsequent routers that the public/private key based authentication has been performed. Then, the authentication on the subsequent (QoS) hops upto the crossover router can be cookie-based. 5. GENERIC QOS SIGNALING This signaling is used when no strict constrains in terms of speed of signaling or bandwidth economy are encountered. It is useful to have a signaling without these constraints, as it is then possible to add many more features to the signaling, such as security key exchanges during a session initiation, or such as a reliable treatment of the information using some transport protocols such as SCTP. This signaling is not discussed in this draft. Westphal, Chaskar Expires December 2002 [Page 14] Internet Draft QoS Signaling Framework for Mobile IP June 2002 6. REFERENCES 1. M. Brunner, ``Requirements for QoS Signaling Protocols", draft- ietf-nsis-qos-req-02.txt, work in progress, May 2002. 2. Y. Bernet, et. al., ``A Framework for Integrated Services Operation over DiffServ Networks", RFC 2998, November 2000. 3. H. Chaskar, ``Requirements of a QoS Solution for Mobile IP", draft-ietf-mobileip-qos-02.txt, work in progress, February 2002. 4. J. Rajahalme, et. al., ``IPv6 Flow Label Specification", draft- ietf-ipv6-flow-label-01.txt, work in progress, September 2002. 5. H. Chaskar and R. Koodli, ``A Framework for QoS Support in Mobile IPv6", draft-chaskar-mobileip-qos-01.txt, work in progress, March 2001. 6. C. Westphal, R. Koodli, C. Perkins, ``Context Relocation of QoS Parameters in IP Networks", draft-westphal-seamoby-qos-relocate- 00.txt, work in progress. 7. R. Koodli, C. Perkins, ``A Context Transfer Protocol for Seamless Mobility", draft-koodli-seamoby-ctv6-03.txt, work in progress. Westphal, Chaskar Expires December 2002 [Page 15] Internet Draft QoS Signaling Framework for Mobile IP June 2002 7. AUTHORSÆ ADDRESSES Cedric Westphal Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043, USA Phone: +1-650 625-2247 EMail: cedric@iprg.nokia.com Fax: +1 650 625-2502 Hemant Chaskar Communications Systems Lab Nokia Research Center 5 Wayside Road Burlington, MA 01803, USA Phone: +1-781 993-3785 EMail: Hemant.Chaskar@nokia.com Fax: +1-781 993-1907 Westphal, Chaskar Expires December 2002 [Page 16]