Internet DRAFT - draft-hamid-seamoby-ct-qos-context
draft-hamid-seamoby-ct-qos-context
SeaMoby Working Group Hamid Syed
Internet Draft Muhammad Jaseemuddin
draft-hamid-seamoby-ct-qos-context-00.txt Nortel Networks
June 6, 2001
QoS (DiffServ) Context Transfer
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet- Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
The distribution of this memo is unlimited. This memo is filed as
<draft-hamid-seamoby-ct-qos-00.txt>, and expires November 2001.
Please send comments to the authors.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
1. Abstract
The intent of this draft is to describe the unique requirements for
transfer of DiffServ QoS context and to detail the specific data
which must be transferred in order to maintain the service
provisioning to the IP QoS flows.
2. Introduction
In networks where hosts are mobile, the success of real-time
services like VoIP telephony, video etc depends heavily on the
ability of the network to support handover of MN's traffic from one
access node to the other with minimum disruption of the service
level. The transfer of the context information associated with the
MN's active micro-flows from one access router to the other during
the MN's mobility can help maintaining the service level during
handovers. This context information comprises of a number of feature
contexts like header compression, QoS, security etc. Much of the
Syed Expires November 2001 [Page 1]
Internet Draft QoS (DiffServ) Context Transfer
work in establishing a generic context transfer framework has
already begun [2]. These documents focus on the generic
requirements and framework for context transfer. However, one must
identify, for each feature to which context transfer is applicable,
the data which must be transferred, and any unique requirements
which are relevant. The intent of this draft is to describe the
unique requirements for transfer of DiffServ QoS context and to
detail the specific data which must be transferred in order to
maintain the service provisioning to the IP QoS flows.
3. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC-2119].
4. Terminology
Much of the terminology used in this document is the same as that
found in [2]. However, a few additional definitions are provided
below:
o DS Domain - Differentiated Services domain. Defined in [3] as
a DS capable domain; contiguous set of nodes which operate on
a common set of service provisioning policies and PHB
definitions.
o DSBN - A Diffserv boundary node in its role in handling
traffic as it enters or leaves a DS domain. The Access Router
(AR) defined in [2] serves as DSBN.
5. Network Model
When discussing the QoS context transfer between the DS boundary
nodes (DSBN) the following network model will be assumed:
+- DS Domain-------+
+--------+ | +------+ | +----------+ +------+
| MN |---------| DSBN |-----|--|----------|---| CN |
| | | +------+ | | | | |
+--------+ | | | Internet | | |
| ... | | | +------+
| +------+ | +----------+
| | DSBN | |
| +------+ |
+------------------+
Where context transfer may occur between any two DSBNs or ARs in the
DS domain. Mobile Node (MN) and the Correspondent Node (CN) are
defined in [8].
6. DiffServ Feature Context
When determining the contents of the QoS feature context, one must
Syed Expires November 2001 [Page 2]
Internet Draft QoS (DiffServ) Context Transfer
examine all the information which is required at the DSBN to control
both the selection of the flows that need to be provided with a
preferred forwarding treatment, as well as specifying the specific
set of preferred forwarding behaviors. The conceptual model of a
DSBN includes the following function [4]:
- Traffic Classification
- Metering
- Actions of marking and dropping
- Queuing elements, including capabilities of algorithmic
dropping and scheduling.
The actions are determined for a traffic flow through the traffic
classification and metering functions and are specific to a
particular DSBN. Similarly, determination of the forwarding queue
for the flows also depends on the device-specific configuration and
queue conditions. Therefore, the actions of marking and the queuing
elements are not required for transfer as a part of the DiffServ
context. However, classification and metering build the piece of
information that is to be considered as the DiffServ context
required at the new DSBN, when the handover of a DS flow occurs from
an old DSBN to the new DSBN.
Traffic classification is performed by the classifier elements.
Classifiers are parameterized by filters and output streams. Packets
from the input streams are stored into output streams by filters
which match the contents of the packet or possibly match other
attributes associated with the packets. These classification filters
consists of the following packet header fields
- Source and Destination IP Address
- Source and Destination Port
- Protocol ID
- DiffServ Code Point (DSCP)
Meters measure the temporal state of a flow or a set of flows
against a traffic profile. In this event, a meter might be used to
trigger real-time traffic conditioning actions (e.g., marking,
dropping, or shaping). Alternatively, by counting conforming and/or
non-conforming traffic using a Counter element, it might also be
used to help in collecting data for out-of-band management functions
such as billing applications. Typical parameters of a traffic
profile are:
1. Committed Information Rate (CIR)
2. Peak Information Rate (PIR)
3. Committed Burst Size (CBS)
4. Peak Burst Size (PBS)
A typical meter measures the rate at which traffic stream passes it
[4]. Its rate estimation depends upon the flow state kept by the
meter. There is a time constraint during which if the flow state is
transferred from the old AR to the new AR, then it is effective in
estimating the rate at the new AR as if though no transfer of flow
has happened. Below we discuss this in detail for two types of
meters - Time Sliding Window (TSW) and Token Bucket (srTCM and
trTCM) meters.
6.1 Time Sliding Window (RFC 2859)
The Time Sliding Window Three-Color Marker (tswTCM) [5] is designed
Syed Expires November 2001 [Page 3]
Internet Draft QoS (DiffServ) Context Transfer
to mark packets of an IP traffic stream with red, yellow or green
color. The marking is performed using the estimated average rate as
compared against the Committed Information Rate (CIR) and the Peak
Information Rate (PIR). The computation of estimated rate is based
on a time window in order to take into account the recent behavior
of the stream. Packets that confirm to CIR are marked green. Packets
that exceed CIR but do not exceed PIR are marked yellow with certain
probability, and packets exceeding PIR are marked red with certain
probability. The TSW meter computes new estimate at the arrival of a
packet. It includes in its computation in addition to the new packet
size but also the number of bytes calculated using previously
estimated rate over a time window, which is initialized to certain
value. Hence, the meter keeps the last estimated average rate of
each flow as its flow state. The flow state needs to be transferred
within a certain time, otherwise the meter at the new AR may build
the new average rate that may be very close to the old average rate.
Hence, the flow state needs to be transferred in real-time following
the timing requirements stated below.
6.2 Token Bucket
A srTCM [6] meter is configured with CIR and CBS and Excess Burst
Size (EBS). It uses two token buckets C and E. The maximum size of C
is CBS and it is filled with CIR, and the maximum size of E is EBS
and it is also filled with CIR. Let Tc and Te be the token counts of
the token buckets C and E respectively. The flow state at any time t
are the token counts of these token buckets, that is tc(t) and
te(t). The token counts need to be transferred in real-time
following the timing requirements stated below.
A trTCM [7] meter is configured with CIR, PIR, CBS, and PBS. It uses
two token buckets C and P. The maximum size of C is CBS and it is
filled with the rate CIR, and the maximum size of P is PBS and it is
filled with the rate PIR. The flow state at any time t are the token
counts of these token buckets, that is tc(t) and tp(t). These token
counts need to be transferred in real-time following the timing
requirements stated below.
7. Requirements Analysis for the DS QoS Context
To perform the requirement analysis of the DS QoS context for upflow
traffic (from MN to CN), let us first categorize the information
contained in the DiffServ context. There is some information within
the over all context that remains unchanged throughout the life of
the micro-flow. Packet classification and metering configuration
(traffic profiles) are examples of such information. This part of
the context can be considered as "the configuration context". On the
other hand, the information like flow state in a meter is updated on
every packet arrival at the AR. This information, therefore, builds
the "state context".
The requirement analysis of the over all DiffServ context here is
based on possible different requirements posed by the configuration
and the state contexts.
7.1 Security
Since the DiffServ context is used by the new AR to determine the
Syed Expires November 2001 [Page 4]
Internet Draft QoS (DiffServ) Context Transfer
support for the service level required by the MN's traffic, careful
considerations need to be taken to ensure that the transfer of the
DiffServ context is secure.
7.2 Timing Requirements
Due to the real-time nature of the information contained in the
state context, it poses strict timing requirements to the context
transfer protocol.
7.2.1 The state context transfer MUST be coupled with the redirection
of corresponding flows to the new AR.
Since the state context is updated at every packet arrival,
transferring it ahead of redirection of actual flow to the new AR,
as for example in case of proactive transfer, may not be useful.
7.2.2 The state context transfer MUST NOT be initiated before the last
packet arrival at the old AR (that is before losing layer 3
connectivity to the old AR).
7.2.3 The state context transfer SHOULD be completed before the next
packet arrival at the new AR (that is before gaining layer 3
connectivity to the new AR.
7.3 Transport Reliability
The general properties of the reliable transport mechanism apply to
the QoS context transfer. However, the real-time nature of the state
context requires special features. For example, the retransmission
of the state context may not be required, as the retransmitted
context could be obseleted by the arrival of new packets to the new
AR. At the same time, the error-free and the most recent state
context is required to perform the DiffServ traffic conditioning
functions at the new AR. The following transport reliability
requirements are proposed for the QoS context (which may be
applicable to other feature contexts as well).
7.3.1 The transport mechanism MUST ensure in-order delivery of the
DiffServ context.
7.3.2 The transport mechanism SHOULD support retransmission of the
DiffServ context.
7.3.2 The retransmitted state context MAY be discarded at the new AR if
the packets of the corresponding flow has already passed the meter
at the new AR.
7.4 Context Update
The configuration context associated with a MN's micro-flows may
change by the addition or deletion of micro-flows to the over all
configuration context. In a proactive context transfer mode, these
Syed Expires November 2001 [Page 5]
Internet Draft QoS (DiffServ) Context Transfer
additions/deletions may occur after a context transfer has already
been performed from the sender DSBN to a potential receiver of the
context. These updates in the configuration context need to be
propagated to the receiver of the context.
7.4.1 Any updates to the configuration context MUST be transferred to
the new AR.
8. References
[1] S. Bradner, "keywords for use in RFCs to Indicate Requirement
Levels", RFC2119 (BCP), IETF, March 1997.
[2] H. Syed et. al., "General Requirements for a Context Transfer
Framework", draft-ietf-seamoby-ct-reqs-00.txt.
[3] S.Blake et. al., "An Architecture for Differentiated Services",
RFC2475, December 1998.
[4] Y. Bernet et. al., " An Informal Management Model for DiffServ
Routers", work in progress, draft-ietf-diffserv-model-06.txt,
February 2001.
[5] W. Fang et. al., Time Sliding Window Three Color Marker,
RFC2859, IETF, March 2000.
[6] J. Heinanen et. al., A single Rate Three Color Marker,
RFC2697, IETF, September 1999.
[7] J. Heinanen et. al., A Two Rate Three Color Marker, RFC2698,
IETF, September 1999.
[8] C. Perkins., IP Mobility Support, RFC2002, IETF, October 1996.
9. Acknowledgments
The authors would like to thank to following people for their useful
comments and suggestions related to this draft: Louis Hamer, Gary
Kenward.
10. Author's Addresses
Hamid Syed
Advanced Wireless Network Technology Lab
Nortel Networks
Ottawa, ON
CANADA
Email: hmsyed@nortelnetworks.com
Ph: 1-623-763-6553
Muhammad Jaseemuddin
Advanced Wireless Network Technology Lab
Nortel Networks
Ottawa, ON
CANADA
Email: jaseem@nortelnetworks.com
Ph: 1-623-765-7520
Syed Expires November 2001 [Page 6]
Internet Draft QoS (DiffServ) Context Transfer
11. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. This
document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organisations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into.
Expiration Date
This memo is filed as <draft-hamid-seamoby-ct-qos-context-00.txt>,
and expires November 2001.
Syed Expires November 2001 [Page 7]
Internet Draft QoS (DiffServ) Context Transfer
