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 , 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 , and expires November 2001. Syed Expires November 2001 [Page 7] Internet Draft QoS (DiffServ) Context Transfer