Seamoby Working Group Cedric Westphal INTERNET DRAFT Rajeev Koodli 13 July 2001 Charles E. Perkins Communication Systems Laboratory Nokia Research Center Context Relocation of QoS Parameters in IP Networks draft-westphal-seamoby-qos-relocate-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 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. This document is an individual submission for the seamoby Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the SEAMOBY@DIAMETER:ORG mailing list. Distribution of this memo is unlimited. Abstract Seamless offering of Quality of Service (QoS) to a Mobile Node during handovers is considered crucial for enabling a variety of application services in the Mobile Internet. In this document, we define the QoS contexts and show how they could be transferred to enable seamless QoS operation during handovers. We introduce the notion of QoS Profile Types and the associated QoS Profiles, which together constitute QoS contexts, that facilitate QoS inter-operability among the pariticipating access routers. We also illustrate how these contexts can be used with fast handover signaling. Westphal, Koodli, Perkins Expires 12 January 2002 [Page i] Internet Draft QoS Context Relocation 13 July 2001 Contents Status of This Memo i Abstract i 1. Introduction 2 2. Terminology 3 3. QoS Profile and QoS Profile Types 4 3.1. QoS Profile Type . . . . . . . . . . . . . . . . . . . . 5 3.2. Examples of QoS Profile Data Structures . . . . . . . . . 6 3.2.1. Best Effort QoS Profile Type . . . . . . . . . . 6 3.2.2. ``Default'' Intserv QoS Profile Type . . . . . . 6 3.2.3. DiffServ trTCM QoS Profile Type . . . . . . . . . 8 3.2.4. Generic QoS Profile Type . . . . . . . . . . . . 9 4. QoS Context Transfer with Handover signaling 10 5. Message Formats 12 5.1. QoS Context Transfer Request ICMP Option . . . . . . . . 12 6. QoS Context Transfer Reply ICMP Option 13 6.1. QoS Context Transfer Request SHIN Suboption . . . . . . . 14 6.2. QoS Context Transfer SHAK Suboption . . . . . . . . . . . 14 7. Configurable Parameters 14 8. Security Considerations 15 9. IANA Considerations 15 A. QoS Acknowledgment Response Codes 17 A.0.1. QoS Profile Unavailable Acknowledgment Code Format 17 A.1. QoS Context Transfer Error SHAK Suboption . . . . . . . . 17 A.1.1. Resource Unavailable Error Data Format . . . . . 18 A.1.2. Bad Format Error Data Format . . . . . . . . . . 18 A.1.3. Context Unavailable Error Data Format . . . . . . 19 Addresses 20 Westphal, Koodli, Perkins Expires 12 January 2002 [Page 1] Internet Draft QoS Context Relocation 13 July 2001 1. Introduction Over the past few years, Quality of Service (QoS) has emerged as a crucial technology for IP networks. Considerable work has taken place in IETF and in research circles to advance this technology leading to a better understanding of its feasibility in a network the size of the Internet. However, very little work has taken place considering QoS with device mobility. Specifically, how to maintain and support QoS for a mobile node's packet streams when it changes its access routers is a problem of considerable interest, especially for those interested in designing mobility protocols that offer seamless ``services'' across handovers. The QoS mechanism offered in a network could be based either on Differentiated Services architecture (DiffServ)[9], or an Integrated Services architecture (IntServ)[8], or a combination of Intserv in the access network and DiffServ in the core network (Intserv over DiffServ)[10]. It is also possible that QoS is simply a default Best-Effort service as it is in today's Internet. In any case, prior to handover, a Mobile Node (MN) attached to its Previous Router (Prtr) receives certain amount of QoS from the network. When the handover takes place, for seamless operation, the New Router (Nrtr) must receive the appropriate QoS state. The failure to possess this state could result in having to re-establish the QoS, potentially end-to-end, which could delay the establishment of the proper connections throughout the network. We take the position that context transfer is one of the components of seamless handovers. In any network, discovery of neighboring access router capabilities is an important, independent process that provides necessary information to effect seamless handovers. Once the target access router capability is known, context transfer could transmit only the required state information. When detailed capability information regarding the target router is not available however, context transfer has to be more generic, transferring the existing state assuming that it would be useful at the receiver. In any case, this transfer of feature contexts has to be synchronized with the actual handover of the mobile node from one access router to another. It is important to bear in mind that any feature context state is tightly related to packet forwarding. This state could quickly get inconsistent if it does not intrinsically follow the handover protocol which establishes basic packet forwarding. While it is important to be able to effect context transfers with handovers, it is also important that context transfers are not dependent upon any particular handover mechanism. Driven by the postulation in the preceding paragraph, we focus in this document to define feature contexts for QoS which can be used along-with handover signaling. We assume that a separate target router selection process guides the context transfer protocol about Westphal, Koodli, Perkins Expires 12 January 2002 [Page 2] Internet Draft QoS Context Relocation 13 July 2001 the destination of context transfer. We demonstrate how the context definitions can be used with Fast Handover signaling for Mobile IPv6. For this purpose, we make use of the new seamless handover options defined in [3] and specific options for QoS defined in this document. Using the introduction in [3], we define QoS Profile Types, which capture the specific QoS state parameters present at an access router. We define certain major profile types expected to be generally useful. These definitions are provided in Section 3. The mechanism described in section 4 closely follows the structure in [7] for the transfer of Header Compression context. In the rest of this document, we use Figure 1 as the reference for discussion. v +------------+ +-+ | Previous | < | | ---------- | Router | ------ > ----\ +-+ | (Prtr) | < \ MN | | \ | +------------+ +---------------+ | ^ IP | Correspondent | | | Network | Node | V | +---------------+ v / v +------------+ / +-+ | New | < / | | ---------- | Router | ------ > ----/ +-+ | (Nrtr) | < MN | | +------------+ Figure 1: Reference Diagram 2. Terminology We define the following terms for use in this document. HAck Message The ICMP Handover Acknowledgment message, sent from the New Router to the Previous Router, and defined in [6]. Westphal, Koodli, Perkins Expires 12 January 2002 [Page 3] Internet Draft QoS Context Relocation 13 July 2001 HI Message The ICMP Handover Initiate message, sent from the Previous Router to the New Router, and defined in [6]. New Router (Nrtr) The router to which the MN attaches after handover Previous Router (Prtr) The MN's default router prior to handover New access address (Naddr) The access IP address of the Mobile Node (MN) when attached to the link served by the New Router Previous access address (Paddr) The access IP Address of the Mobile Node (MN) when attached to the link served by the Previous Router Context Identifier (CID) A 16-bit unsigned integer that identifies a particular QoS context. Compression Profile Type (CPT) A 16-bit unsigned integer that indicates the type of QoS (see section 3). SHAK Message Any IPv6 message received by the mobile node containing the SHAK Destination Option defined in [3]. SHIN Message Any IPv6 message sent by the mobile node containing the SHIN Destination Option defined in [3]. SHREP Message The ICMP Smooth Handover Reply message, sent between access routers, and defined in [3]. SHREQ Message The ICMP Smooth Handover Request message, sent between access routers, and defined in [3]. 3. QoS Profile and QoS Profile Types A QoS Profile specifies the structure of the state variables which are used for QoS. The QoS Profile Type (QPT), on the other hand, provides a way to indicate which kind of QoS is provided to a particular packet stream. A QoS context thus includes QPT and the corresponding Westphal, Koodli, Perkins Expires 12 January 2002 [Page 4] Internet Draft QoS Context Relocation 13 July 2001 QoS Profile. For seamless QoS establishment, the routers located at separate network nodes must agree on the structure of these QoS state parameters. When the New Router receives the QoS context, it will instantiate a QoS state machine for the packet stream in question. That new state machine will be created with the values of the state variables taken from the QoS Profile contained in the appropriate message, and interpreted according to the data structure and format defined by the QPT. 3.1. QoS Profile Type The following QPTs are currently defined. 10: reserved 11: Best Effort 12: IntServ Controlled-Load Service 13: IntServ Guaranteed Service 14: DiffServ default 15: DiffServ srTCM 16: DiffServ trTCM 17: Generic Each QPT value is allocated an IANA type number. The size of each QPT is well-defined and is fixed. A value of zero has special meaning in suboption processing as outlined in Section 4. This list in not exhaustive. For instance, there are different possible meters in a DiffServ router architecture that would maintain different QoS states and request different QPT. Some discussion regarding flow monitoring and metering is in order. The monitoring and metering of the microflow behavior is usually done using token buckets or some averaging process. When token bucket schemes are used, the only dynamic parameter is the token count. Thus, this parameter should be provided to the relevant token bucket at the New Router. If this parameter arrives after the service has started at the New Router, then the new bucket count SHOULD be updated by taking into account the value of the previous token count. For instance, for a buffer of depth B with a bucket count b1 at Previous Router, and a buffer of depth B with a bucket count b2 not taking into account the history of the flow, then, upon arrival of the QoS context, the new buffer count should be adjusted to b3 = max( b2 + (b1-B),0). Westphal, Koodli, Perkins Expires 12 January 2002 [Page 5] Internet Draft QoS Context Relocation 13 July 2001 In the case of a moving average, the new rate at the New Router SHOULD be initialized to the corresponding value in the QoS Profile. If the value and the early computation of the moving average starts before the arrival of the QoS context, then, upon arrival of the QoS context, the value of the moving average SHOULD be updated by taking into account the value of the previous rate. For instance, for a rate r1 at the Previous Router, and a rate r2 at the New Router, then, upon arrival of the QoS context, the new rate should be adjusted to r3 = p*r2 + (1-p)*r1, with p = (time spent at New Router)/(total time length of the connection). In the case of an average rate, the dynamic state is this rate. The rate at New Router has to be initialized to this value, with a weight corresponding to the length of the connection. The Previous Router MUST provide a QoS Profile that the New Router can use. This means that the Previous Router must chose the format corresponding to the New Router and attempt to fill it with its own data. If it does not understand the format corresponding to the New Router, then it MUST provide a generic QoS Profile. 3.2. Examples of QoS Profile Data Structures We define a few example QoS Profile object formats. We expect other QoS Profiles to be similar to these examples. Once again, the following list is not exhaustive. However, we do not expect a large number of such data structures either. 3.2.1. Best Effort QoS Profile Type The QPT-BE is the context maintained by a router that does not distinguish between the packet streams. It does not maintain any information besides the fact that the router does not keep microflow states. It is the default QPT if no other one is provided. The QPT code for BE is 11 (cf. Section 3.1). 3.2.2. ``Default'' Intserv QoS Profile Type We present here the default IntServ QoS Profile. The QPT code for this profile type is 12. It is to be used when the IntServ type is Controlled-Load service or when it is not known. Westphal, Koodli, Perkins Expires 12 January 2002 [Page 6] Internet Draft QoS Context Relocation 13 July 2001 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | Type (TBD) | Length | QPT-BE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Best-Effort QoS Profile Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | Type (TBD) | Length | QPT-Default-Intserv | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 |QoS Requirement(16-bit integer)| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Average Data Rate (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 |Burstiness:Token Bucket Size(32-bit IEEE floating point number)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Peak Data Rate (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Minimum Policed Unit (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Maximum Packet Size (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Measured Rate (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | Initial Token Count at New Router (32 bit IEEE fl. pt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 | Connection Length (timestamp) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11 | Flags (future use) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Composition of QoS Profile for default IntServ The QoS Context for a Controlled-load IntServ connection uses the single token bucket specified in [13]. There is only one state variable, the current token count, that becomes the initial token count Westphal, Koodli, Perkins Expires 12 January 2002 [Page 7] Internet Draft QoS Context Relocation 13 July 2001 at the New Router once context is established. If the Previous Router is not an IntServ Router, then it is unable to fill this specific field. It sets the field either to a infinite value, meaning that the New Router would set it to the bucket size, or to the bucket size requested by the Burstiness parameter, if this parameter is available. The connection length field keeps track of the time the flow is in use. 3.2.3. DiffServ trTCM QoS Profile Type We present here the DiffServ two rates Three Color Marker QoS Profile Type. It is one of the metering/marking devices introduced in the DiffServ MIB (presented for instance in [11]). The QoS Context state that has to be transferred is composed of the configuration state and the monitoring state. Thus the state would be different for different meters. The trTCM is defined in [12]. Westphal, Koodli, Perkins Expires 12 January 2002 [Page 8] Internet Draft QoS Context Relocation 13 July 2001 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | Type (TBD) | Length | QPT-Diffserv-trTCM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 |QoS Requirement(16-bit integer)| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Committed Information Rate (32-bit IEEE floating point number)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Burstiness:Committed Bucket Size(32-bit IEEE floating point) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Peak Information Rate (32-bit IEEE floating point number)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Peak Burst Size (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Minimum Policed Unit (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Maximum Packet Size (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | New Router initial Committed Token Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | New Router initial Peak Token Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 | Connection length (time stamp) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11 | Flags (future use) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Composition of QoS Profile for Diffserv trTCM 3.2.4. Generic QoS Profile Type The Previous Router uses this profile when it does not know the capability of the New Router or when it does not understand the New Router's capability. Westphal, Koodli, Perkins Expires 12 January 2002 [Page 9] Internet Draft QoS Context Relocation 13 July 2001 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | Type (TBD) | Length | QPT-Generic | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 |QoS Requirement(16-bit integer)| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Data Rate (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Burstiness:Token Bucket Size(32-bit IEEE floating point) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Peak Rate (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Peak Burst Size (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Minimum Policed Unit (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Maximum Packet Size (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Average Measured Data Rate (32-bit IEEE floating point number)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | New Router initial Burst Token Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 | New Router initial Peak Token Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11 | Connection length (time stamp) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12 | Flags (future use) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Composition of Generic QoS Profile 4. QoS Context Transfer with Handover signaling In this section, we provide an illustration of how the QoS Profiles and QPTs defined in the previous section can be transferred along-with handover signaling. Note that these QoS Contexts (i.e., QPT plus QoS Profile) can be carried in other forms of messages as well, e.g., they could be carried in a Paging Message [14]. We use fast handover signaling for Mobile IPv6 for our illustration here. The Previous Router, in response to either the network-initiated handover or the mobile-initiated handover, sends a HI message to the New Router. In this HI message, it includes the Unsolicited Westphal, Koodli, Perkins Expires 12 January 2002 [Page 10] Internet Draft QoS Context Relocation 13 July 2001 Seamless Handover Reply (U-SHREP) option defined in [3], which carries the appropriate QoS contexts. The actual QPT and the QoS Profiles carried may depend on the knowledge the Previous Router has regarding the New Router's QoS capabilities. The Unsolicited SHREP option carries an authentication token for the New Router to verify prior to authorizing the feature contexts. This token uses the session key that gets established when the MN first connects to the Previous Router. Alternative to carrying the token, the Unsolicited SHREP message could instead carry the session key itself as one of the sub options. In any case, the network policy may require the New Router to authenticate the MN prior to granting network access as well as feature contexts. In such a case, the MN has to respond to an appropriate challenege from the New Router providing its own token that must match the one that the New Router possesses. The details of this mechanism described in [14] for IP paging are applicable for our purposes here. Once authorized (whenever enforced), the New Router makes QoS contexts available to the MN. The New Router SHOULD include a SHREP-Ack option in the HAck message to the Previous Router. When fast handover signaling is either not available or fails, the New Router fetches context subsequent to the MN's attachment to it. The MN sends a SHIN message containing its Previous IP address and Previous Router address to the New Router. This SHIN can be embedded as an option in the network access authentication message [15]. In response to the SHIN message, recognizing that the required state is not available, the New Router transmits a Seamless Handover Request (SHREQ) message with QoS sub options. And, the Previous Router responds back with a Seamless Handover Reply (SHREP) message containing the actual QoS context information. See [3] for the details. In this case, the QoS context that is provided to the New Router is only the relevant QoS context. For instance, the two routers providing IntServ QoS can exchange a context that has an IntServ granularity. Observe that even optimal handover procedures sometimes fail due to the real-world dynamics including unpredictable physical terrains, spotty coverage areas etc. For instance, due to unfavorable terrain conditions, the MN may lose link connectivity with its current AR and establish a new link with a new AR. In such a case, the New Router does not necessarily know the MN's Previous Router and its Previous IP address. However, the MN can supply this information, and it does this by including it in the SHIN message. Since there is no established means for a MN to be certain that the New Router has knowledge of its Previous Router and its Previous IP address (which is necessary to identify the contexts), we propose including the SHIN option in all the handover scenarios. When context is already present at the New Router, SHIN facilitates explicit authorization of feature contexts. When the context is not present, it triggers reactive context transfer. Westphal, Koodli, Perkins Expires 12 January 2002 [Page 11] Internet Draft QoS Context Relocation 13 July 2001 5. Message Formats QoS options and suboptions are defined for use in several different protocol message types: - as an option or a sub option to a HI, HAck, SHREQ, or SHREP ICMPv6 messages. - as a suboption of an IPv6 destination option. - as an extension to a Mobile IPv4 registration request to be processed by a Foreign Agent. - as an extension to some other seamless handover message to be defined in the future for mobile nodes using IPv4. The general format for the options is the same in all cases, as shown in Figure 6. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QOSOpt Type | QOSOpt Len | QOSOpt Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: QoS Options, Suboptions and Extension Format 5.1. QoS Context Transfer Request ICMP Option The QOSReq suboption is sent by Nrtr to Previous Router in the SHREQ message to obtain QoS context on behalf of the mobile node. The New Router MAY request all of the relevant QoS context associated with the mobile node, by sending QOSReq with suboption length equal to zero. Suboption Type: QOSReq-ICMP Suboption Length: Variable The processing of this ICMP option at the Previous Router depends on the availability of required QoS state, and is done in accordance with requirements outlined in Section 3.2. The New Router MUST respond with Westphal, Koodli, Perkins Expires 12 January 2002 [Page 12] Internet Draft QoS Context Relocation 13 July 2001 the SHAK suboption defined in section 4.4. The New Router, possibly using the information sent by the Previous Router, MAY include suboption QOSErr (defined below) in the SHAK message. 6. QoS Context Transfer Reply ICMP Option The QoS Context Transfer Reply suboption (QOSRep) suboption is defined for Prtr to transfer state to Nrtr in the HI or SHREP ICMP messages. The QOSRep suboption includes the necessary state for Nrtr to seamlessly carry-over QoS. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CID | QPT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QoS State Variables ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: QoS Reply Data Element The Option Type and Option Length fields of the QOSRep ICMP option are followed by blocks consisting of [CID, QPT, QoS State variables] tuple(s). Each block has the format illustrated in Figure 7. CID Context Identifier QPT QoS Profile Type QoS State Variables Values for QoS state variables, in the format defined by the QPT The CID and QPT are 16-bit fields. For a particular QPT, the size of QoS state variables field is fixed; this allows inclusion of multiple tuples without requiring a length indicator. If the suboption length is zero, it indicates that Prtr cannot supply the required QoS level to Nrtr. In case of errors, Prtr SHOULD include the QOSErr suboption defined in section 4.5 in the SHREP message. When the value of QPT is zero in a tuple, it indicates that the Previous Router cannot supply state information for the associated context identified by the CID. In this case also, Prtr SHOULD Westphal, Koodli, Perkins Expires 12 January 2002 [Page 13] Internet Draft QoS Context Relocation 13 July 2001 include suboption QOSErr (e.g., to indicate that suboption QOSReq was incorrectly formatted) in the packet. 6.1. QoS Context Transfer Request SHIN Suboption When the mobile node wishes to continue receiving the same level of QoS at Nrtr, it sends the QoS Context Transfer Request (QOSReq) suboption in a message addressed to Nrtr containing a SHIN Destination Option. Suboption Type: QOSReq-SHIN Suboption Length: Variable When the QOSReq is present in a SHIN message and the suboption length is zero (the default value), this suboption indicates the MN's desire to continue with the same QoS features as prior to handover. 6.2. QoS Context Transfer SHAK Suboption The QoS Context Transfer Acknowledge suboption (QOSAck) is defined for inclusion in the SHAK IPv6 Destination Option, and is used by Nrtr to respond to the mobile node. Note that SHAK is an optional message. The MN SHOULD be prepared to accept packets treated with feature contexts even when it does not receive a SHAK message. Suboption Type: QOSAck-SHAK Suboption Length: Variable When the suboption length is zero (the default value), this suboption indicates that MN's request to continue with the QoS level was accepted at Nrtr without any modifications to the context parameters. When the suboption length is non-zero, the QOSAck data has the format shown in Figure 8. Each acknowledgment code specifies the format of the QOSAck data field, which contains the data associated with the acknowledgment. The currently defined acknowledgment codes are described in the appendix. 7. Configurable Parameters The nodes supporting mobility defined in this document SHOULD be able to configure the parameters outlined below as well those in [4]. Each table entry contains the name of the parameter and the default value. Westphal, Koodli, Perkins Expires 12 January 2002 [Page 14] Internet Draft QoS Context Relocation 13 July 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QOSAck Code | QOSAck Len | QOSAck Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: QoS Context Transfer SHAK Suboptions (QOSAck) format Parameter Name Default Value ------------------------------------------------- QOS\_CONTEXT\_SAVE\_TIME 2 * SHREQ\_REXMIT\_TIME QOS\_CONTEXT\_PURGE\_TIME 5 * SHREQ\_REXMIT\_TIME SHIN\_WAIT\_TIME 1000 milliseconds 8. Security Considerations All context transfer for QoS MUST be secured by use of the Authentication suboption [4], or the IPv6 Authentication Header [2]. Thus, no additional vulnerability has been introduced. 9. IANA Considerations The QoS Profile Type (QPT) defined in this document requires IANA Type numbers. References [1] J. Bound and C. Perkins. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (work in progress). Internet Draft, Internet Engineering Task Force, May 2000. [2] S. Kent and R. Atkinson. IP Authentication Header. Request for Comments (Proposed Standard) 2402, Internet Engineering Task Force, November 1998. [3] R. Koodli and C. Perkins. A Context Transfer Framework for Seamless Mobility (work in progress). Internet Draft, Internet Engineering Task Force. draft-koodli-seamoby-ctv6-00.txt, February 2001. Westphal, Koodli, Perkins Expires 12 January 2002 [Page 15] Internet Draft QoS Context Relocation 13 July 2001 [4] R. Koodli and C. Perkins. A Framework for Smooth Handovers with Mobile IPv6 (work in progress). Internet Draft, Internet Engineering Task Force. draft-koodli-mobileip-smoothv6-01.txt, November 2000. [5] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461, Internet Engineering Task Force, December 1998. [6] G. Tsirtsis and et al. Fast Handovers for Mobile IPv6(work in progress). Internet Draft, Internet Engineering Task Force. draft-designteam-fast-mipv6-01.txt, February 2001. [7] R. Koodli, M. Tiwari, C. Perkins. Context Relocation for Seamless Header Compression in IP Networks (work in progress). Internet Draft, Internet Engineering Task Force. draft-koodli-seamoby-hc-relocate-00.txt [8] J. Wroclawski. The Use of RSVP with IETF Integrated Services. RFC 2210, Internet Engineering Task Force. [9] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss. An Architecture for Differentiated Service. December 1998. RFC 2475, Internet Engineering Task Force. [10] Y. Bernet et al., A Framework for Integrated Services Operation over Diffserv Networks. RFC 2998, Internet Engineering Task Force. [11] Bernet et al., DiffServ Informal Management Model, draft-ietf-diffserv-model-06.txt (work in progress) [12] J. Heinanen, A two rate Three Color Marker, RFC 2698 [13] S. Shenker, J. Wroclawski, General Characterization Parameters for Service Network Elements, RFC 2215. [14] R. Koodli and J. T. Malinen. Idle-mode Context Transfers in IPv6 Networks (work in progress). Internet Draft, Internet Engineering Task Force. draft-koodli-seamoby-idle-mode-ctv6-00.txt, July 2001 [15] N. Asokan, Patrik Flykt, C. Perkins and Thomas Eklund. AAA for IPv6 Network Access (work in progress). Internet Draft, Internet Engineering Task Force. Westphal, Koodli, Perkins Expires 12 January 2002 [Page 16] Internet Draft QoS Context Relocation 13 July 2001 A. QoS Acknowledgment Response Codes In this section, we define the various error codes sent back to the MN in response to its request for QoS context transfer. A.0.1. QoS Profile Unavailable Acknowledgment Code Format The QoS Acknowledgment Code block for QPT_UNAVAILABLE is as shown in Figure 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QOSAck Code=2 | Length | [CID,New-CID] pairs... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: QPT UNAVAILABLE acknowledgement Data format Code: 02 (QPT_UNAVAILABLE) Length: Variable The data for the QPT_UNAVAILABLE acknowledgment code consists of [CID, New-QPT] tuple(s), one for each requested QPT that was unavailable. When the value of QPT is zero in a tuple, it indicates that the associated context identified by the CID was not activated. In this case, Nrtr MAY include suboption QOSErr with an appropriate error code indicating the reason for failure to activate the context. A.1. QoS Context Transfer Error SHAK Suboption The QoS Context Transfer SHAK Error Suboption (QOSErr) allows the access routers to supply error codes when activation fails for one or more QoS level requests. The QOSErr data format is shown in Figure 10. Suboption Type: QOSErr-SHAK Suboption Length: Variable Each error code specifies the format of the QOSErr data field, which contains the data associated with the error condition. The currently defined error codes are specified in the following sections. Westphal, Koodli, Perkins Expires 12 January 2002 [Page 17] Internet Draft QoS Context Relocation 13 July 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QOSErr Code | QOSErr Length | QOSErr Error Code Blocks... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: QoS Context Transfer Error Format A.1.1. Resource Unavailable Error Data Format The QoS Error Code block for RESOURCE_UNAVAILABLE is as shown in Figure 11. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QOSErr Code=1 | Length = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: RESOURCE UNAVAILABLE error format Code: 01 (RESOURCE_UNAVAILABLE) Length: 0 The RESOURCE_UNAVAILABLE error has no associated error data. This error is returned when no resources are available. This code indicates that Nrtr does not have the resources required to set up QoS context(s) for this MN. The MN MUST deactivate the previous QoS state. It MAY either start sending packets expecting only Best Effort service in this case, or it may re-negotiate with Nrtr to activate a new QoS level and a QoS profile. A.1.2. Bad Format Error Data Format The QoS Error Code block for BAD_FORMAT is as shown in Figure 12. Code: 02 (BAD_FORMAT) Length: Variable Westphal, Koodli, Perkins Expires 12 January 2002 [Page 18] Internet Draft QoS Context Relocation 13 July 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QOSErr Code=2 | Length | Offending Suboption ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: BAD FORMAT error format This error indicates that the context transfer request was poorly formatted. If a router does not understand the format of a particular suboption, it sends QOSErr with this code; and the data part contains the details of the suboption which caused this error. The Previous Router SHOULD send this suboption to Nrtr whenever appropriate, and Nrtr MAY send this suboption to the MN. A.1.3. Context Unavailable Error Data Format The QOS Error Code block for CONTEXT_UNAVAILABLE is as shown in Figure 13. Code: 03 (CONTEXT_UNAVAILABLE) Length: Variable The QOSErr data for this code contains the CIDs representing contexts which are not available for transfer. This might happen because +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QOSErr Code=3 | Length | Unavailable CIDs ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: CONTEXT UNAVAILABLE error format the context has already been removed at both the routers in the fast handover case. Note that Nrtr MAY remove the state supplied Westphal, Koodli, Perkins Expires 12 January 2002 [Page 19] Internet Draft QoS Context Relocation 13 July 2001 by Prtr if Nrtr does not receive a SHIN message from the MN within QOS_CONTEXT_SAVE_TIME. Addresses Questions about this memo can also be directed to the authors: Cedric Westphal Rajeev Koodli Communications Systems Lab Communications Systems Lab Nokia Research Center Nokia Research Center 313 Fairchild Drive 313 Fairchild Drive Mountain View, California 94043 Mountain View, California 94043 USA USA Phone: +1-650 625-2247 Phone: +1-650 625-2359 EMail: cedric@iprg.nokia.com EMail: rajeev.koodli@nokia.com Fax: +1 650 625-2502 Fax: +1 650 625-2502 Charles Perkins Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA Phone: +1-650 625-2986 EMail: charliep@iprg.nokia.com Fax: +1 650 625-2502 Westphal, Koodli, Perkins Expires 12 January 2002 [Page 20]