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]