Internet DRAFT - draft-westphal-nsis-qos-mobileip

draft-westphal-nsis-qos-mobileip





  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]