FMC Y. An Internet-Draft Stoke, Inc. Expires: January 29, 2007 July 28, 2006 An Architecture Framework For Fixed Mobile Convergence Using SIP as Access Call Control Protocol draft-yafan-fmc-arch-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet-Draft will expire on January 29, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes an architecture framework for achieving converged mobile services across alternative radio access networks (GAN, or Generic Access Network), such as WLAN, WiMax, and the cellular network, while utilizing SIP for media session control between the dual mode handset (DMH) and a network SIP proxy. The key benefits of this architecture include (1) fast and flexible service deployment in the IP domain, and (2) allow seamless voice call continuity services across IP and circuit-switched cellular domains. An Expires January 29, 2007 [Page 1] Internet-Draft SIP-based FMC Architecture July 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Objectives . . . . . . . . . . . . . . . . . . 4 3. System Overview . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Cellular Homed Deployment . . . . . . . . . . . . . . . . 7 3.1.1. Mobility Proxy (MP-CSCF) . . . . . . . . . . . . . . . 7 3.1.2. Dual Mode Handset . . . . . . . . . . . . . . . . . . 8 3.1.3. Media Gateways and Media Gateway Controllers . . . . . 9 3.1.4. Home Location Registrar . . . . . . . . . . . . . . . 9 3.1.5. Mobile Switching Center (MSC/VLR) . . . . . . . . . . 9 3.1.6. Short Message Service Center . . . . . . . . . . . . . 9 3.1.7. Supplementary Services Support . . . . . . . . . . . . 9 3.2. Soft Switch Homed Deployment . . . . . . . . . . . . . . . 10 3.2.1. Soft Switch (S-CSCF) . . . . . . . . . . . . . . . . . 11 3.2.2. HLR . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.3. Supplementary Services Support . . . . . . . . . . . . 11 4. Basic Feature Set . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Registration and Nomadic Mobility . . . . . . . . . . . . 12 4.1.1. Global versus Local Registration . . . . . . . . . . . 12 4.1.2. Nomadic versus Local Mobility . . . . . . . . . . . . 13 4.1.3. Registration Message Flow in Cellular-homed Scenario . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.4. Registration Message Flow in Soft Switch-homed Scenario . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.5. Dual Registration and Domain Selection . . . . . . . . 17 4.2. Roving Across Domains . . . . . . . . . . . . . . . . . . 18 4.2.1. Rove-out Trigger Detection . . . . . . . . . . . . . . 18 4.2.2. Rove-out Message Flow . . . . . . . . . . . . . . . . 18 4.2.3. Rove-in Trigger Detection . . . . . . . . . . . . . . 19 4.2.4. Rove-in Message Flow . . . . . . . . . . . . . . . . . 19 4.3. Single Number Reach-ability . . . . . . . . . . . . . . . 19 4.3.1. Call Termination in VoIP Domain . . . . . . . . . . . 20 4.3.2. Call Termination in Cellular Domain . . . . . . . . . 21 5. Session Mobility and Session Anchoring . . . . . . . . . . . . 23 5.1. Mobile Controlled Handovers . . . . . . . . . . . . . . . 23 5.2. Mobile Assisted and Network Controlled Handovers . . . . . 23 5.3. Session Anchor . . . . . . . . . . . . . . . . . . . . . . 24 5.3.1. Natural Anchoring . . . . . . . . . . . . . . . . . . 24 5.3.2. Anchor Migration . . . . . . . . . . . . . . . . . . . 25 5.3.3. Forced Anchor Selection . . . . . . . . . . . . . . . 25 6. Use of SIP Headers for Converged Services . . . . . . . . . . 27 6.1. Time Zone Indication . . . . . . . . . . . . . . . . . . . 27 6.2. Operator Name . . . . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31 Intellectual Property and Copyright Statements . . . . . . . . . . 32 An Expires January 29, 2007 [Page 2] Internet-Draft SIP-based FMC Architecture July 2006 1. Introduction There has been increasingly more and more dual mode handsets (DMH) coming to the market recently. These DMH have both cellular baseband and radio and WLAN baseband and radio. Voice over IP (VoIP) services has started to utilize these WLAN capabilities on the handsets. Achieving converged mobiles services across VoIP and cellular is the goal of fixed mobile convergence (FMC). The objective of this document is to outline a generic framework to so that specific protocols, methods and algorithms can be specified without repeating the generic framework. The cellular network considered is the 3GPP GSM circuit switched network, although such framework may be adapted to support other cellular networks. There has been other frameworks defined or being defined, such as the Unlicensed Mobile Access (UMA) technology which is standardized in [3GPP.43.318], and the Voice Call Continuity (VCC) approach currently being standardized in [3GPP.23.206]. UMA dost not use SIP as access call control in GAN domain. VCC uses SIP as call control protocol in GAN in an Internet Multimedia Sub-system (IMS) centric fashion. The framework described in this document is more generic than UMA or VCC. The framework is defined for the purposes of defining the SIP- based protocol interface between the dual mode handset (DMH) and the network SIP proxy to achieve seamless services across VoIP and circuit-switched cellular domains. This framework does not define individual product nor does it suggest functional groupings of network elements. This architecture framework is intended to be compatible with the Internet Multimedia Sub-System (IMS) architecture, but the focus of this framework is to address incremental requirements in the current VoIP and cellular infrastructure to achieve converged services in the near term. These incremental requirements are represented as incremental capabilities in the SIP interface between the DMH and the SIP proxy, and extra CSI inter-working capabilities on the network SIP proxy (or a separate entity in the network). This document only focuses on the SIP interface between the DMH and the SIP proxy. In order to put the focus only on the SIP interface between the DMH and the SIP proxy, this framework is described with only existing cellular and VoIP infrastructure elements to achieve converged services. An Expires January 29, 2007 [Page 3] Internet-Draft SIP-based FMC Architecture July 2006 2. Terminology and Objectives The target capability set of this framework includes the following: 1. Rove-in: a DMH in an idle state to leave the cellular network and register with the GAN network 2. Rove-out: a DMH in an idle state to leave the GAN network and attaches to the cellular network 3. Single number reach-ability across GAN and cellular networks 4. Hand-in: a DMH in an active call in the cellular network to carry over the call into a GAN network 5. Hand-out: a DMH in an active call in the GAN network to carry over the call into a GAN network The first 3 items above are also referred to as the "basic feature set". The basic feature set is achieved with only the requirements described in this document. The last 2 items above referred to as the "extended feature set". The extended feature set can be achieved with the method described in [yafan-fmc-mancho], or the method described in Section 5.1, or other methods. The following introduces additional terminologies used in this document: Back-To-Back (B2B) Proxy: A logical entity that maintains state information for the entire duration of a SIP dialog, and is in the signaling path of all messages of a subscriber's transactions, see [RFC3261]. Soft Switch Homed Subscriber : Refers to a subscriber whose home network is a SIP-enabled soft switching network. The public identities of a soft switched homed subscriber are routed to a soft switch in the home network. Its private identities (such as IMSI) is provisioned on a cellular HLR. Cellular Homed Subscriber : Refers to a subscriber whose home network is a cellular network. The public identity of a cellular homed subscriber is routed to a mobile switching centre (MSC, or GMSC) in the cellular network. Its private identity is provisioned on a cellular HLR. An Expires January 29, 2007 [Page 4] Internet-Draft SIP-based FMC Architecture July 2006 Home Network : Refers to the home network where a subscriber is provisioned. Typically, an inter-network call termination request is routed to the home network for routing decisions. Visited Network : Refers to a network where a subscriber is not provisioned, but a user is gaining access according to a roaming agreement. Typically, an inter-network call termination request is routed to the home network for routing decisions. GAN-Attach : Refers to the procedure where a handset achieving access to a GAN radio network. Service Attach : Refers to a procedure where a handset's SIP user agent registers with the VoIP network to receives FMC services. Hand-in Attach : Refers to a procedure where a handset's SIP user agent establishes a local relationship with a SIP proxy to receive hand-in of active sessions. An Expires January 29, 2007 [Page 5] Internet-Draft SIP-based FMC Architecture July 2006 3. System Overview The framework described in this document supports two deployment options: Cellular-homed deployment: In this deployment model, new dual-mode handset users are provisioned on an existing cellular network, which include at least two parts: The dual-mode handset's SIM card (or IMSI) is provisioned on the cellular network's HLR; and The dual-mode handset's MSISDN number is a routable number, and the MSISDN number is routed to a Gateway MSC (GMSC) in the cellular network for call termination. This implies that supplementary services, such as voicemail, call forwarding services, etc. for the dual-mode handset subscribers are provided by the cellular network. Soft switch-homed : In this deployment model, the carrier is assumed to have a class-5 soft switch (CSCF, or S-CSCF), and the dual-mode handset users are provisioned in the VoIP infrastructure as follows: The dual-mode handset's SIM card (or IMSI) is provisioned on a cellular network's HLR belonging to the VoIP infrastructure, and is accessible by the cellular networks for roaming purposes; and The dual-mode handset's MSISDN number is a routable number, and the MSISDN number is routed to the soft switch for call termination. This implies that supplementary services, such as voicemail, call forwarding services, etc. for the dual-mode handset subscribers are provided by the VoIP infrastructure. Cellular-homed deployment allows the carrier to start offering FMC services with minimal and less-sophisticated VoIP service infrastructure. Soft switch-homed deployment allows the carrier to start offering FMC services by leveraging existing VoIP service infrastructure. An Expires January 29, 2007 [Page 6] Internet-Draft SIP-based FMC Architecture July 2006 3.1. Cellular Homed Deployment Cellular-Homed System Architecture C / D +--------+ +-------------------| HLR | | +--------+ | | E +--------+ +-------------------| SMSC | | +--------+ +---------------------------+ | | Mobility Proxy +-----+ | | +---------+ | | CSI | |---+ | MSC / | | +-----------+___+-----+ | +------+ +------| VLR | | | SIP B2BUA | | PSI | | SIP | MGCF | | ISUP +---------+ | +-----------+ +-----+ |------+------+--+ /PRI | +---------------------------+ | MG | +---------+ | +------+ | BSC/BTS | | SIP +---------+ | | +-------+ | | DMH |------------------------------------------- +-------+ This diagram does not suggest the grouping of functions into physical entities. 3.1.1. Mobility Proxy (MP-CSCF) The Mobility Proxy, or Mobility Proxy CSCF (MP-CSCF), is a key element to facilitate converged services across WLAN and cellular networks. From the pespective of the IP network, the MP-CSCF serves as Breakout Gateway Control Function (BGCF) plus voice session continuity support. For the purpose of this document, the term MP- CSCF is used, and it includes three functional elements: o The back-to-back SIP user agent allows a DMH SIP UA to register, originate and terminate calls, send and receive instant messages, using the SIP protocol. It is a B2B UA in order to perform call bridging in the cases of handing over call-legs between WLAN and cellular domains, in a manner similar to third party call control (3PCC). o The Circuit Switched Interworking (CSI) function allows the MP- CSCF to initiates handover call-leg setup to the cellular domain. For the basic feature set, the CSI uses the MAP C and D interface with the HLR. In the method of [yafan-fmc-mancho], the MAP E An Expires January 29, 2007 [Page 7] Internet-Draft SIP-based FMC Architecture July 2006 interface is also used to facilitate bidirectional handover. o The Packet Switched Interworking (PSI) function allows the MP-CSCF to accept bridging request from the cellular network via the MGCF. The PSI manages a set of mobile station roaming numbers (MSRN) that are routable from the cellular network. The Mobility Proxy (MP-CSCF), together with the MGCF/MG appears to the cellular network as a peering MSC. It shall be provisioned with at least one Location Area Code (LAC) and a cell-id. The MP-CSCF MAY authenticate the DMH SIP UA using its cellular credentials, such as using MD5-AKAv1 as per [RFC3310], or other authentication mechanisms. The MP-CSCF may also serve as a Gateway MSC (GMSC), in which case, the network is configured to route the MSISDN of the DMH to this MP- CSCF via MGCF. 3.1.2. Dual Mode Handset A DMH SHALL support the appropriate attachment and security mechanism in the GAN network. This aspect of the framework is not described in this document. For security related discussions, please refer to Section 7 of this document. Prior to SIP registration to a MP-CSCF, the DMH SHOULD also perform a provisioning and discovery procedures to obtain the addresses of the local (home or visited) MP-CSCF and various other parameters. The provisioning and discovery procedures are not discussed in this document. The DMH MUST also support the following capabilities: Singular Registration -- Singular registration refers to the fact that a DMH is actively logged on to only one network, i.e. either cellular or the MP-CSCF. Although this framework does not exclude the support of dual registration, i.e. a DMH is logged on to both the IP-based MP-CSCF and the cellular network at the same time, it is assumed in order to simplify the discussions. Idle Scan -- While in cellular idle state, the handset must be able to scan for WLAN wireless signal, at an interval that is defined by the handset. While in GAN idle state, the handset must be able to scan for cellular signal, at an interval that is defined by the cellular standards. An Expires January 29, 2007 [Page 8] Internet-Draft SIP-based FMC Architecture July 2006 Monitor GAN -- While in an active cellular session, the handset must be able to scan for GAN wireless signal, at an interval that is defined by the handset. Monitor Cellular -- While in an active GAN session, the handset must be able to scan for cellular signal, at an interval that is defined by the handset. Transient Dual Transmission -- During an active handover, the handset should be able to maintain both wireless and cellular sessions for a short period, the due-radio period can be terminated once the handover transaction is terminated. 3.1.3. Media Gateways and Media Gateway Controllers MG and MGCF are the media and signaling conversion functions to connect the IP packet switched network and the circuit switched cellular network. It usually connects to the cellular network using ISUP or PRI trunks; and connects to the IP packet network with SIP and RTP. These MGCF and MG do not need to be mobility-aware. 3.1.4. Home Location Registrar The HLR in the cellular network is the subscriber database which hosts the IMSI of the DMH. The MP-CSCF connects to the HLR using the C/D interface. In this framework, this HLR does not need extra features as compared to a regular cellular HLR. 3.1.5. Mobile Switching Center (MSC/VLR) For the basic feature set of this document, the MP-CSCF do not have direct connections to the MSC/VLR. 3.1.6. Short Message Service Center The MP-CSCF connects to the SMSC via the MAP E interface for SMS interworking. The PSI/CSI performs conversion between SIP MESSAGE requests to/from SMS. 3.1.7. Supplementary Services Support It is expected that supplementary services of DMH would have similar "look and feel" of the cellular network. The MP-CSCF, including the CSI/PSI functions, is expected to be implemented according to An Expires January 29, 2007 [Page 9] Internet-Draft SIP-based FMC Architecture July 2006 cellular network's definition of supplementary features. As an example, the MP-CSCF SHOULD implement call barring policy according to policy data retrieved from the HLR, and to support CAMEL triggers for compliance to supplementary services of the cellular network. 3.2. Soft Switch Homed Deployment Soft Switch-Homed System Architecture +---------------+ +-----------+ | Soft Switch |.......| HLR / HSS | | (S-CSCF) | Cx +-----------+ +---------------+ C/D | | | E +--------+ | SIP +-------------------| SMSC | | | +--------+ +---------------------------+ | | Mobility Proxy +-----+ | | +---------+ | | CSI | |---+ | MSC / | | +-----------+___+-----+ | +------+ +------| VLR | | | SIP B2BUA | | PSI | | SIP | MGCF | | ISUP +---------+ | +-----------+ +-----+ |------+------+--+ /PRI | +---------------------------+ | MG | +---------+ | +------+ | BSC/BTS | | SIP +---------+ | | +-------+ | | DMH |------------------------------------------- +-------+ This diagram does not suggest the grouping of functions into physical entities. As can be seen, soft switch-homed deployment utilizes similar entities and functions as compared to cellular-homed deployment, with only the following differences: o A Soft Switch (S-CSCF) to serve the needs of switching and supplementary services in VoIP domain. There may be other application servers (AS) or media servers, which are not shown for simplicity. o This HLR is associated with the VoIP network, or the cellular network via a co-hosting agreement. This HLR does not require extra features as compared to a cellular HLR. An Expires January 29, 2007 [Page 10] Internet-Draft SIP-based FMC Architecture July 2006 3.2.1. Soft Switch (S-CSCF) In soft switch-homed deployment, supplementary services is expected to have similar "look and feel" of the VoIP network. The MP-CSCF serves as an outbound SIP proxy which is transparent to supplementary services. Supplementary features are implemented by the Soft Switch and the application servers (AS) in the VoIP network. The MSISDN (or the DMH's telephony SIP URI or telephony URI) must be provisioned on this soft switch. The MP-CSCF (together with the S-CSCF) also serves as a Gateway MSC for VoIP domain. 3.2.2. HLR The HLR must be provisioned with the DMH's IMSI. As mentioned earlier, this HLR does not require additional features as compared to a normal cellular HLR. However, in the soft switch-homed deployment, the HLR provisioning of IMSI must be coordinated with the provisioning of MSISDN on the soft switch. Therefore, the HLR may be owned or closely associated with the VoIP carrier. As the network evolves to IMS, the Cx interface between the S-CSCF and the HSS will ensure consistency of subscriber and service profiles to be consistent across different domains. 3.2.3. Supplementary Services Support It is expected that supplementary services of DMH would have similar "look and feel" of the VoIP network. Supplementary features are implemented by the Soft Switch and the application servers (AS) in the VoIP network. An Expires January 29, 2007 [Page 11] Internet-Draft SIP-based FMC Architecture July 2006 4. Basic Feature Set As already known, the cellular network and the VoIP networks define different sets of terminologies and concepts. To facilitate the understanding of the architecture framework presented in this document, a few important concepts and terminologies are described in order to fully understand the design of this framework. 4.1. Registration and Nomadic Mobility In a VoIP network, nomadic mobility is supported via the SIP REGISTER transaction. A SIP Registrar stores the contact information of the SIP client after it registered with the Registrar. Due to the global nature of IP-based SIP contact address, a SIP client has built-in nomadic mobility capability. Such capability is exhibited in the fact that the SIP server can deliver a terminating request to the SIP client wherever it registers from. In a cellular network, nomadic mobility is largely supported by the Home Location Registrar (HLR). The HLR stores the location of the handset when it performs a Location-Update request. Recognizing the similarities of SIP-REGISTER and cellular Location- Update, the SIP-REGISTER and Location-Update are both referred to as the registration procedures to their perspective networks. 4.1.1. Global versus Local Registration It is well-known that the cellular network HLR serves as the global registrar of a handset, while a local MSC or Visiting Location Registrar (VLR) serves as the local registrar of a handset. The global registrar is consulted for call termination on a global scale, while the MSC/VLR, which has temporary subscriber data, serves to control micro bearer mobility for best mobility performance. This hierarchical partition of responsibility has benefited the mobility implementation well. In VoIP or SIP, there is no explicit separation of global versus local registration. However, a hierarchical registration is naturally supported by SIP. For example, when a B2BUA or a stateful proxy is traversed between a SIP client and SIP Registrar, the proxy also stores temporary state data of the client. An access Session Border Controller (SBC) is a good example of such scenario, in which an SBC may acknowledge REGISTER on behalf of the global Registrar, provided that the global registration has not timed out. In this architecture framework, the MP-CSCF serves as a local registrar (or VLR) for DMH. The MP-CSCF also manages handover call- An Expires January 29, 2007 [Page 12] Internet-Draft SIP-based FMC Architecture July 2006 legs in the most efficient manners locally (such as shortest bearer detour). Therefore, this framework supports clear separation of global versus local registration. Further, local registration and global registration may be supported by different protocols. For example, in cellular-homed deployment of this framework, local registration is manifested by SIP-REGISTER to the MP-CSCF, while MP-CSCF performs global registration via cellular Location-Update to the HLR. 4.1.2. Nomadic versus Local Mobility The separation of nomadic versus local mobility also simplifies the impact of mobility on the implementation of supplementary services. The basic feature set deals monadic mobility. Local mobility that involves session anchoring and call-leg switching are described in [yafan-fmc-mancho] and [yafan-fmc-mcho]. 4.1.3. Registration Message Flow in Cellular-homed Scenario In cellular-homed deployment, SIP-REGISTER is mapped to Location- Update to the HLR. MD5-AKAv1 ([RFC3310] allows SIP authentication based on SIM credentials. An Expires January 29, 2007 [Page 13] Internet-Draft SIP-based FMC Architecture July 2006 Updated access-type values: +-----+ +----------+ +---------+ | DMH |----------------------| Visisted |-----------------| Home | +-----+ | MP-CSCF | | Net HLR | | SIP: REGISTER +----------+ +---------+ |------------------------------>| MAP/D: SEND-AUTH-INFO | | |--------------------------->| | | MAP/D: SEND-AUTH-INFO res | | SIP: 407 Unauthorized |<---------------------------| |<------------------------------| | | SIP: REGISTER | | |------------------------------>| MAP/D: LOCATION-UPDATE | | |--------------------------->| | | MAP/D: INSERT-SUB-DATA | | |<---------------------------| | | MAP/D: INSERT-SUB-RESULT | | |--------------------------->| | | +-------+ MAP/D: CANCEL | | | |MSC/VLR|<--------------->| | | +-------+ LOCATION | | | MAP/D: LOC-UPDATE-RESULT | | SIP: 200 OK |<---------------------------| |<------------------------------| | | | | REGISTER (DMH --> MP-CSCF) -- The purpose of this request is to register the user's SIP URI with the MP-CSCF in the home or visited GAN domain. The MP-CSCF, or visited MP-CSCF authenticates the DMH to the VoIP network. It is routed to the MP-CSCF since it is the SIP proxy known to the DMH. MAP/D SEND-AUTHENTICATION-INFO exchange -- This exchange with the HLR is to retrieve the authentication credentials for the handset. Since multiple authentication vectors can be retrieved in a single request, this exchanged is needed only when the MP-CSCF has exhausted authentication vectors. The MP-CSCF needs to know the IMSI of the DMH in order to retrieve the authentication vector from the HLR. The DMH MUST use IMSI as its username. The MAP/D SEND-AUTHENTICATION-INFO exchange can be performed only after the MP-CSCF has learned the proclaimed IMSI from the DMH. Therefore, the SIP REGISTER SHOULD include its credentials even it is not challenged, i.e. assuming nonce=''. An Expires January 29, 2007 [Page 14] Internet-Draft SIP-based FMC Architecture July 2006 407 -- The MP-CSCF forms a challenge based on the authentication vectors obtained from the HLR, and sends a AKAv1-MD5 challenge to the DMH. SIP/2.0 407 Proxy Unauthorized From: To: Contact: Call-ID: Authorization: Digest username="imsi@home1.net", realm="home1.net",uri="sip:home1.net", nonce="5bc80c48", algorithm=AKAv1-MD5 CSeq: 1 REGISTER REGISTER with credentials -- This REGISTER contains challenge response. MAP/D LOCATION-UPDATE -- Upon successful authentication, the MP-CSCF performs Location-Update towards the HLR. This transaction establishes that mobile-terminating calls are routed through the MP-CSCF for terminating in the VoIP domain. 200 OK -- If the Location-Update MAP exchange with the HLR is successful, the MP-CSCF returns 200 OK to the MS. Errors occurred during MP-CSCF's location update procedure shall be propagated to the MS: IMSI invalid: If the HLR returns error code indicating IMSI invalid, the MP-CSCF will return "404 Not Found" SIP message. Roaming not allowed: If the HLR returns error code indicating that this subscriber is not allowed to roam into the GAN area served by this MP-CSCF, the MP-CSCF returns "603 Forbidden" SIP message. Other errors: If the Location-Update exchange with the HLR results with other errors, e.g. timed out, the MP-CSCF returns "500 Internal Server Error" SIP message to the DMH. The identity is composed compliant with the Network Access Identifier (NAI) format specified in [RFC2486]. The format of NAI is username@realm [3GPP.23.003]. The username in SIP authentication SHALL also be composed according to the following format 1@imsi.mnc.mcc.3gppnetwork.org or 1@myprovider.com An Expires January 29, 2007 [Page 15] Internet-Draft SIP-based FMC Architecture July 2006 For example, if the IMSI is 234150999999999 (MCC = 234, MNC = 15), the NAI then takes the form of 1234150999999999@uma.mnc015.mcc234.3gppnetwork.org or 1234150999999999@myprovider.com. The preceding "1" indicate IMSI is used as identifier. 4.1.4. Registration Message Flow in Soft Switch-homed Scenario In soft switch-homed deployment, SIP-REGISTER is forwarded to the soft switch (or S-CSCF) for authentication, and is then mapped to Location-Update to the HLR. Both S-CSCF and the HLR are in the DMH's home network. In this deployment scenario, the S-CSCF may use non SIM-based authentication mechanism, such as the Digest-MD5 authentication mechanism, for SIP authentication. Updated access-type values: +-----+ +----------+ +---------+ | DMH |----------------------| Visisted |-----------------| Home | +-----+ | MP-CSCF | | Net HLR | | SIP: REGISTER +----------+ +---------+ |------------------------------>| REGISTER +--------+ | | |----------------->| S-CSCF | | | | 401 +--------+ | | SIP: 401 |<---------------------| | |<------------------------------| | | | SIP: REGISTER | | | |------------------------------>| REGISTER | | | |--------------------->| | | | 200 OK | | | SIP: 200 OK |<---------------------| | |<------------------------------| | | | MAP/D: LOCATION-UPDATE | | |---------------------------->| | | MAP/D: INSERT-SUB-DATA | | |<----------------------------| | | MAP/D: INSERT-SUB-RESULT | | |---------------------------->| | | +-------+ MAP/D: CANCEL | | | |MSC/VLR|<---------------->| | | +-------+ LOCATION | | | MAP/D: LOC-UPDATE-RESULT | | SIP: 200 OK |<----------------------------| |<------------------------------| | | | | An Expires January 29, 2007 [Page 16] Internet-Draft SIP-based FMC Architecture July 2006 REGISTER (DMH --> MP-CSCF --> S-CSCF) -- The purpose of this request is to register the user's SIP URI with the S-CSCF in the VoIP domain. The S-CSCF authenticates the DMH to the VoIP network. It is routed to the MP-CSCF since it is the SIP proxy known to the DMH. The AKAv1-MD5 mechanism is still preferred here, in which case the MP-CSCF performs the authentication using SIM-based credentials. A trust relation between the MP-CSCF and the S-CSCF SHALL be established. Such trust relationship can be based on multiple means, such as a IPsec or TLS security association, or a simple site-wide username/password for all users. MAP/D LOCATION-UPDATE exchange -- The Location-Update exchange is performed only when the DMH is successfully authenticated. The MP-CSCF must have learned the proclaimed IMSI from the DMH. Therefore, the SIP REGISTER SHOULD include its credentials even it is not challenged, with its IMSI in the username field. The Location-Update transaction establishes that mobile- terminating calls are routed through the S-CSCF via the MGCF/MG for terminating in the VoIP domain. 200 OK -- If the Location-Update exchange with the HLR is successful, the MP-CSCF returns 200 OK to the MS. The errors occurred during MP-CSCF's location update procedure SHALL be propagated to the DMH: IMSI invalid: If the HLR returns error code indicating IMSI invalid, the MP-CSCF will return "404 Not Found" SIP message. Roaming not allowed: If the HLR returns error code indicating that this subscriber is not allowed to roam into the GAN area served by this MP-CSCF, the MP-CSCF returns "603 Forbidden" SIP message. Other errors: If the Location-Update exchange with the HLR results with other errors, e.g. timed out, the MP-CSCF returns "500 Internal Server Error" SIP message to the DMH. 4.1.5. Dual Registration and Domain Selection Concurrent registration in both VoIP and cellular domains is not a focus of this framework, although its support is not excluded. It is envisioned that the HLR (or HSS) may be expanded so that it maintains two location records: one for cellular location and one for VoIP location. Then, a domain selection for terminating requests can also An Expires January 29, 2007 [Page 17] Internet-Draft SIP-based FMC Architecture July 2006 be supported on the HLR. 4.2. Roving Across Domains The DMH will be able to rove in and out across cellular and VoIP networks by treating the MP-CSCF as an MSC. In this document, i.e. to support only the "basic feature set" described in this document, roving has two parts (1) registration in the target domain, and (2) stop refreshing registration in the source domain. 4.2.1. Rove-out Trigger Detection Rove-out is a handset's operation to leave VoIP domain and to register onto the cellular domain. Similar to roaming in a cellular network, rove-out trigger detection is a pure handset matter. The handset must periodically monitor the cellular cell radio signals, and compare its quality to the current GAN (e.g. IEEE 802.1a/b/g) radio signal, and initiates a rove-out operation when it decides to log on to a target cellular network to continue service. It is important to note that the rove-out operation is strictly compliant to the cellular standards. 4.2.2. Rove-out Message Flow Rove-Out Message Flow for Cellular-Homed DMH: Visited Target Target DMH MP-CSCF BSC HLR MSC/VLR | BCCH: Signal==Good | | | | |<------------------------------| | | | RR: CHAN REQ/ASS | | | | |<----------------------------->| | | | MM: LOC UPDATE | | | MAP: LOC UPD | |------------------------------>|------------------------------>| | < Intermediate messages skipped > | | MM: LOC UPD ACCEPT | | | | |<--------------------------------------------------------------| | SIP: de-REGISTER | | | | |--------------------->| | | | | SIP: 200 OK | | | | |<---------------------| | | | The above message flow intends to show the high-level exchanges only. Various flavors of the message flows are described in [XX], [XX], and [XX]. An Expires January 29, 2007 [Page 18] Internet-Draft SIP-based FMC Architecture July 2006 Rove-Out Message Flow for Soft Switch-Homed DMH: Visited Target Target DMH MP-CSCF BSC HLR S-CSCF MSC/VLR | BCCH: Signal==Good | | | | | |<------------------------------| | | | | RR: CHAN REQ/ASS | | | | | |<----------------------------->| | | | | MM: LOC UPDATE | | | MAP: LOC UPD | |------------------------------>|------------------------------>| | < Intermediate messages skipped > | | | MM: LOC UPD ACCEPT | | | | | |<--------------------------------------------------------------| | SIP: de-REGISTER | | | | | |--------------------->| | REGISTER (trust) | | | SIP: 200 OK |---------------------------->| | |<---------------------| | 200 OK | | | | |<----------------------------| | The above message flow intends to show the high-level exchanges only. For soft switch-homed DMH, the MP-CSCF does not de-REGISTER from the S-CSCF, but it instead registers with the S-CSCF via a pre-defined trust relationship, such as a site-wide credential. After rove-out, the MP-CSCF transitions into a Gateway MSC for the DMH. The VoIP domain has the flexibility of designating one or multiple MP-CSCF as GMSC depending on network configuration. 4.2.3. Rove-in Trigger Detection Rove-in is handset's operation to leave cellular domain and register onto the VoIP domain. As in cellular roaming, rove-in trigger detection is a pure handset matter. The handset must periodically monitor the GAN radio signals, and compare its quality to the current cellular radio signal, and initiates a rove-in operation when it decides to log on to a VoIP network to continue service. 4.2.4. Rove-in Message Flow Rove-in message flows are identical to SIP registration flows described in Section 4.1.4 and Section 4.1.3. 4.3. Single Number Reach-ability It is obvious that, with the support of MP-CSCF, especially the CSI/ An Expires January 29, 2007 [Page 19] Internet-Draft SIP-based FMC Architecture July 2006 PSI functions of the MP-CSCF, a DMH is reachable with a single telephone number (or URI) across VoIP and cellular domains. 4.3.1. Call Termination in VoIP Domain There is slight difference for call termination between a cellular- homed and soft switch-homed DMH. When a DMH is homed in the cellular domain, a call termination request is first routed to the Gateway MSC of the cellular network. The GMSC is then queries the HLR for routing information. The HLR returns the ISUP routing information of the MGCF/MG associated with the MP-CSCF. The MGCF then routes the INVITE to the MP-CSCF for termination. Recall that, in cellular homed deployment, the MP-CSCF is the serving MSC and SHOULD possess logics for supplementary services. When a DMH is homed on a VoIP soft switch, a call termination request is first routed to the soft switch. There are two scenarios: SS-homed DMH registered in VoIP domain: This case is straight- forward. The INVITE is forwarded to the DMH via the MP-CSCF. SS-homed DMH roaming in cellular domain: When a DMH is not currently registered in the VoIP domain, a designated MP-CSCF is designated as the Gateway MSC on behalf of the DMH. Recall Section 4.2.2 that a MP-CSCF transitions into a GMSC for the DMH during rove-out by maintaining a registration with the S-CSCF on behalf of the DMH. The S-CSCF forwards the INVITE to the MP-CSCF who shall then query the HLR to obtain a Mobile Station Roaming Number (MSRN), and the termination request is sent to the cellular network for termination. This scenario will be discussed in more details in Section 4.3.2. An Expires January 29, 2007 [Page 20] Internet-Draft SIP-based FMC Architecture July 2006 Call Termination in VoIP Domain for SS-homed and Cellular-Homed DMH: Cellular-homed DMH: Visited DMH MP-CSCF HLR MGCF/MGW GMSC | | | MAP/C: SRI |<-- | | MAP/D: PRI |<----------------|IAM | |<---------------------| | | | | MAP/D: PRI (MSRN) | | | | |--------------------->| C: SRI res | | | |---------------->| | SIP: INVITE | SIP: INVITE | | IAM | |<--------------------|<----------------------------|<---------| | | | | | <... Intermediate messages skipped ...> Soft Switch-homed DMH: Visited Circuit DMH MP-CSCF HLR S-CSCF Switch | | | | | | SIP: INVITE | SIP: INVITE | | IAM | |<--------------------|<----------------------------|<---------| <... Intermediate messages skipped ...> The above message flow intends to show the high-level exchanges only. 4.3.2. Call Termination in Cellular Domain There are slight difference when a DMH is homed in the cellular domain or in the VoIP domain. When a DMH is homed in the cellular domain, a call termination request MAY be routed according to cellular network, unless its routing is changed by using other means such as those described in [3GPP.23.206]. When a DMH is homed on a VoIP soft switch, a call termination request is first routed to the soft switch. There are two scenarios: SS-homed DMH is registered in VoIP domain: This case is straight- forward. The INVITE is forwarded to the DMH via the MP-CSCF. SS-homed DMH roaming in cellular domain: When a DMH is not currently registered in the VoIP domain, a designated MP-CSCF is designated as the Gateway MSC on behalf of the DMH. Recall Section 4.2.2 that a MP-CSCF transitions into a GMSC for the DMH during rove-out by maintaining a registration with the S-CSCF on behalf of the DMH. The S-CSCF forwards the INVITE to the MP-CSCF who shall then An Expires January 29, 2007 [Page 21] Internet-Draft SIP-based FMC Architecture July 2006 query the HLR to obtain a Mobile Station Roaming Number (MSRN), and the termination request is sent to the cellular network for termination. Call Termination in Cellular Doamin for SS-homed and Cellular-Homed DMH: Cellular-homed DMH in Cellular Domain: Visited Visited DMH BSC MSC/VLR HLR S-CSCF GMSC | | | | | C: SRI |<-- | | | D: PRI |<----------------|IAM | | |<---------------------| | | | | | D: PRI (MSRN) | | | | | |--------------------->| C: SRI (MSRN) | | | | |---------------->| | CC: SETUP | ISUP: IAM | | IAM | |<--------|<----------|<---------------------------------------| | | | | | | <... Intermediate messages skipped ...> Soft Switch-homed DMH Roaming in Cellular Domain: Visited Gateway Visited Circuit DMH BSC MP-CSCF MSC/VLR HLR S-CSCF Switch | | | | | | | | | | SIP: INVITE | | IAM | | | |<----------------------------|<---------| | | | MAP/C: SRI | | | | | |--------------------->| | | | | MAP/D: PRI | | | | |<---------------------------------| | | | | | MAP/D: PRI (MSRN) | | | |--------------------------------->| | | | | MAP/C: SRI(MSRN) | | | | |<---------------------| MGCF/MG | | | | SIP: INVITE(MSRN) | | | | |---------------------------->| | | | | | | | | | CC: SETUP | | ISUP: IAM | | |<--------------------------------|<----------------| | | | | | | | | <... Intermediate messages skipped ...> The above message flow intends to show the high-level exchanges only. An Expires January 29, 2007 [Page 22] Internet-Draft SIP-based FMC Architecture July 2006 5. Session Mobility and Session Anchoring Earlier in this document, a basic set of features enabled by this architecture framework has been described. The basic feature can be categorized by the term called Single Number Services. The framework can enable a much larger set of features on top of the basic set of features. The extended features are fully described in [yafan-fmc-mancho] and [yafan-fmc-mcho]. One of the extended features is dynamic session handover across VoIP and cellular domains. This feature is sometimes called voice call continuity (VCC) service. This document describes certain concepts and brief introduction of the extended features enabled by this framework. 5.1. Mobile Controlled Handovers Mobile controlled handover refers to a handover that is initiated and executed by the handset based on handset's logic and decisions. In a network where heterogeneous radio access networks are totally independent, converged services are achieved by handset's capability of utilizing multiple radio access technologies. The converged network has no comparative intelligence of the radio access networks. The handset is in the driver seat with respect to which network to use and to switch services among different access networks. The framework in this document naturally supports mobile controlled handovers. 5.2. Mobile Assisted and Network Controlled Handovers Mobile assisted, network controlled handover refers to a handover that is initiated and executed by a network element based on handset's report or network element's measurement of radio characteristics and consult certain network policies. The handover is assisted by the handset for completion. In a network where a network element can obtain comparative intelligence about heterogeneous radio access networks, converged services can be achieved by the intelligent network element executing its logic to complete a handover procedure. Mobile assisted but network controlled handovers offer more flexibility, controllability, and more predictable network behaviors. It allows the network element a chance to manages faults during handovers. The framework in this document naturally supports mobile controlled An Expires January 29, 2007 [Page 23] Internet-Draft SIP-based FMC Architecture July 2006 handovers. 5.3. Session Anchor To achieve session stream continuity, an anchor point is required. This is true in all the mobile network designs. A degradation of this model is that one or both endpoints act as the anchor, which is the case where binding update is sent to the endpoint in Mobile IP. Session anchoring at endpoint is not feasible in many networks. When the endpoints of a session stream is not able to perform the anchor function, an anchor point in the network is necessary. In the framework of this document, the MP-CSCF is designed as a session anchor point. Since the MP-CSCF can be deployed in a distributed and geographically distributed fashion, this architecture allows network designers to design the network to minimize handover control message latency and to reduce bearer detour, to achieve desired handover performances. Handover is treated as a bearer path transfer procedure, and is intended to be independent to supplementary services. This is in contrast to certain alternative approaches where session anchor is designed as a centralized server function, e.g. [3GPP.23.206] Session anchoring is an important aspect of a design for session continuity. When dealing with session continuity across VoIP and cellular domains, there may be multiple choices for selecting an anchor. Multiple anchoring options are introduced later in this Section. A key objective of this framework is to any combination of the anchoring choices, concurrently if so desired. When a DMH is involved in a voice session, a single anchor is selected. When a DMH is involved in an active multimedia session, the framework in this document naturally allows each media stream to select a different anchor and be handed over independently. Based on the selected anchoring choice, handover mechanism is selected accordingly. Mobile controlled handover is described in Section 5.1. Mobile assisted and controlled handover is described in Section 5.2. 5.3.1. Natural Anchoring Natural anchoring refers to the utilization of the existing anchoring mechanism for each media stream that is already established by the original domain where the session stream is established. The CSI/PSI functions are the facilitator for handing over the session stream across domains. An Expires January 29, 2007 [Page 24] Internet-Draft SIP-based FMC Architecture July 2006 When a voice call is established in the cellular network, either mobile originated or mobile terminated, the cellular MSC naturally becomes the anchor of the voice stream. When a voice call is established in the VoIP domain, the MP-CSCF becomes the anchor of the voice stream. Natural anchoring refers to the above scenario where converged services do not require the altering of the natural anchors. Natural anchoring and mobile assisted and controlled handover are described in detail in [yafan-fmc-mancho]. 5.3.2. Anchor Migration Natural anchor selection, as described in Section 5.3.1 and in [yafan-fmc-mancho] requires the MP-CSCF to implements mobility interworking function utilizing the MAP E interface, which in turn requires the VoIP domain to configure peering topologies such as the neighbor cell list on both the MP-CSCF and the cellular MSC. In order to alleviate the burden of configuring the peering topology, the network may choose to use mobile-controlled handovers, as described in Section 5.1 and [yafan-fmc-mcho]. However, with natural anchoring in Section 5.3.1, only hand-out can be performed, while hand-in cannot be always performed if the natural anchor is in the cellular domain. When the handover is between WLAN and cellular, hand-out is obviously more critical than hand-in for the purpose of maintaining voice services. Therefore, mobile-controlled handover is a valuable option. It should be noted that a side effect of mobile-controlled handover is the shifting of the anchor point during handover, and anchoring migration is not always bidirectional. Mobile-controlled handover with anchor migration is described in detail in [yafan-fmc-mcho]. 5.3.3. Forced Anchor Selection As described in Section 5.3.2, mobile-controlled hand-in cannot always be performed when the natural anchor is in the cellular domain. In order to alleviate this issue, the network may choose to select an alternative anchor point for handover. To establish an alternative anchor point in the VoIP domain, a call's signaling and bearer path must be routed through a VoIP element. Such routing must be done at the call establishment phase, not at the time of handover. The MP-CSCF is also designed to be such an alternative anchor point. An Expires January 29, 2007 [Page 25] Internet-Draft SIP-based FMC Architecture July 2006 Obviously, calls originated or terminated to a DMH in the VoIP domain is already routed through an MP-CSCF, so alternative anchoring does not apply. However, it applies for mobile originated or terminated calls in the cellular domain, where they may or may not be routed through an MP-CSCF. There are many ways that call routing in the cellular domain can be altered to pass through an MP-CSCF. The following lists a few possible methods: Mobile-Terminated Call in Cellular Domain -- Since mobile-terminated calls are first routed to a GMSC (cellular-homed DMH) or the Soft Switch (soft switched-homed DMH), termination routing can be controlled by the HLR or the Soft Switch to pass through a local MP-CSCF. This is called "termination tandem". hangText="Mobile-Originated Call in Cellular Domain --">Call origination could be placed to designated destination number on the MP-CSCF, which again originates the call on behalf of the DMH to its original destination. This is called "origination tandem". Static routing configured for DMH users based on its class of service types. Use of pre-defined tandem numbers for tandem routing. Use Service Control Point (SCP) and CAMEL triggers to control tandem routing. USSD exchange to control tandem routing. Not every method can be applied in every network or in every region within a network without investing in legacy cellular networks. Therefore, architecture SHOULD support multiple methods in a non- exclusive fashion. An alternative anchor point does not replace or remove the natural anchor point, it is used only for session handover across VoIP and cellular domains. Forced anchor selection is also described in [yafan-fmc-mcho]. An Expires January 29, 2007 [Page 26] Internet-Draft SIP-based FMC Architecture July 2006 6. Use of SIP Headers for Converged Services In order to improve the quality of the converged services, certain convention should be established. This section describes these conventions. 6.1. Time Zone Indication The Date header in SIP ([RFC3261]) indicates the time and time zone of the user agent client or server. However, [RFC3261] restricts the time zone to "GMT", and let the SIP client to find out its local time zone. In cellular networks, the time and time zone is often passed down by the network element to the handsets. This is useful for the handset to be aware of the local time and time zone due to the mobile nature of the service. In this document, this Date header, when passed down from the MP- CSCF, it indicates the time zone, date and time of the LAC area of the local GAN cell. In this specification, the time zone parameter SHALL expanded to be compatible with [RFC0822] and [RFC1123], which includes the support of numeric time zones. ( The local SIP proxy is therefore able to pass down the time and timezone information of the approximate location to the handset. The handset SHOULD display the time according to the timezone information obtained from the network. For example, -700 means Pacific Standard Time. 6.2. Operator Name Due to the mobility nature of converged services, a handset may sometimes use a visited MP-CSCF for services. The use of foreign MP- CSCF is necessary when handover and roaming depends on an existing peering relationship between the MP-CSCF and the local cellular network. The visited MP-CSCF is comparable with a P-CSCF in the Internet Multimedia Sub-systems (IMS) terminologies. Utilizing foreign GAN network MAY has cost impact, therefore it is beneficial to inform the user about the identity of the local operator. The Organization header of SIP SHOULD be used by the SIP proxy to inform the handset of the identity of local network. To allow the passing of the both the long and short names of the An Expires January 29, 2007 [Page 27] Internet-Draft SIP-based FMC Architecture July 2006 local MP-CSCF operator, the header is formatted as follows: Organization: Operator-Long-Name (Short-Name) The name outside of the bracket is the Long Name of the operator, the name inside the bracket is the short form of the same operator. The DMH SHOULD display the name to the user, similar to a cellular phone. An Expires January 29, 2007 [Page 28] Internet-Draft SIP-based FMC Architecture July 2006 7. Security Considerations This document does not define a protocol, but still presents some security requirements in the presented framework. Since IMSI and other network information is transmitted inside SIP messages, the operator may not wish them to be seen by unauthorized entities in the network. For this reason, SIP messages between the DMH and the MP-CSCF SHALL be transmitted over a secure transport protocol, such as TLS or IPsec. Secure MINE may also satisfy this requirement; however, the Authorization header must be inside the encrypted SMINE body. 8. References [3GPP.23.003] 3GPP, "Numbering, addressing and identification", 3GPP TS 23.003 3.14.0, January 2004. [3GPP.23.206] 3GPP, "Voice call continuity between Circuit Switched (CS) and IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.206 1.0.0, June 2006. [3GPP.43.318] 3GPP, "Generic access to the A/Gb interface; Stage 2", 3GPP TS 43.318 6.7.0, July 2006. [RFC0822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)", RFC 3310, September 2002. [yafan-fmc-mancho] An, Y., "Mobile Assisted Handover Across VoIP and Cellular An Expires January 29, 2007 [Page 29] Internet-Draft SIP-based FMC Architecture July 2006 Domains Using SIP as Access Call Control", draft-yafan-fmc-mancho-01 (work in progress), July 2006. [yafan-fmc-mcho] An, Y., "Mobile Controlled Handover Across VoIP and Cellular Domains Using SIP as Access Call Control", draft-yafan-fmc-mcho-01 (work in progress), July 2006. An Expires January 29, 2007 [Page 30] Internet-Draft SIP-based FMC Architecture July 2006 Author's Address Yafan An Stoke, Inc. 5403 Betsy Ross Drive Santa Clara, CA 95054 US Email: yafan@stoke.com URI: http://www.stoke.com/ An Expires January 29, 2007 [Page 31] Internet-Draft SIP-based FMC Architecture July 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. An Expires January 29, 2007 [Page 32]