Diameter Maintenance and P. Stupar, Ed. Extensions (DIME) NEC Internet-Draft S. Das Intended status: Standards Track Telcordia Expires: August 21, 2008 J. Korhonen Teliasonera T. Melia Cisco February 18, 2008 Diameter extensions for MoS discovery draft-stupar-dime-mos-options-00 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 August 21, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract IEEE 802.21 standard defines three distinct service types to facilitate link layer handovers across heterogeneous technologies. This document focuses on the Diameter Network Access Server (NAS) to Stupar, et al. Expires August 21, 2008 [Page 1] Internet-Draft MoS-Diameter-extensions February 2008 home Authentication, Authorization and Accounting server (HAAA) interface defining a number of Diameters AVPs containing domain names or IP addresses. Such information is related to IEEE 802.21 services assisting a mobile node in handover preparation (network discovery) and handover decision (network selection). Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Mobility Service scenarios . . . . . . . . . . . . . . . . 5 3.2. Sequence of operations . . . . . . . . . . . . . . . . . . 6 4. Commands and AVP . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Command codes . . . . . . . . . . . . . . . . . . . . . . 8 4.1.1. Diameter-EAP-Request . . . . . . . . . . . . . . . . . 8 4.1.2. Diameter-EAP-Answer . . . . . . . . . . . . . . . . . 9 4.1.3. AA-Request . . . . . . . . . . . . . . . . . . . . . . 9 4.1.4. AA-Answer . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Attribute Value Pair Definitions . . . . . . . . . . . . . 10 4.2.1. MIH-MoS-Info . . . . . . . . . . . . . . . . . . . . . 11 4.2.2. MIH-MoS-Address AVP . . . . . . . . . . . . . . . . . 11 4.2.3. MIH-MoS-FQDN AVP . . . . . . . . . . . . . . . . . . . 11 4.2.4. MIH-MoS-type AVP . . . . . . . . . . . . . . . . . . . 11 4.2.5. MIH-MoS-Capability AVP . . . . . . . . . . . . . . . . 12 5. AVP Information Tables . . . . . . . . . . . . . . . . . . . . 12 5.1. Request and Response Commands AVP Table . . . . . . . . . 12 5.2. Mobility Services AVPs . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6.1. Registration of new AVPs . . . . . . . . . . . . . . . . . 13 6.2. New Registry: Mobility Services Capability . . . . . . . . 14 6.3. New Registry: Mobility Services Type . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Stupar, et al. Expires August 21, 2008 [Page 2] Internet-Draft MoS-Diameter-extensions February 2008 1. Introduction IEEE 802.21 [IEEE80221] defines three distinct service types to facilitate link layer handovers across heterogeneous technologies. In IEEE terminology these services are called Media Independent Handover (MIH) services. The services are named Mobility Services (MoS) and are the following: Information Services (IS) IS provide a unified framework to the higher layer entities across the heterogeneous network environment to facilitate discovery and selection of multiple types of networks existing within a geographical area, with the objective to help the higher layer mobility protocols to acquire a global view of the heterogeneous networks and perform seamless handover across these networks. Event Services (ES) ES provide a way to indicate changes in state and transmission behavior of the physical, data link and logical link layers, or predict state changes of these layers. The Event Service may also be used to indicate management actions or command status on the part of the network or some management entity. Command Services (CS) CS enable higher layers to control the physical, data link, and logical link layers. The higher layers may control the reconfiguration or selection of an appropriate link through a set of handover commands. While these services may be co-located, the different pattern and type of information they provide does not necessitate the co- location, hence a server providing such services will not necessarily host all the three of them together. A mobile node may make use of any of these MIH service types separately or any combination of them. [I-D.ietf-mipshop-mstp-solution] defines different reference scenarios characterized by the location of the mobile node and the MoS which can be discovered by the node. Some of the considered scenarios enable the assignment of MoS provided the fact that the scenario is of type integrated (see for reference [I-D.ietf-mip6-bootstrapping-integrated-dhc]). In this case, assignment is performed through the interaction between DHCP and AAA frameworks, assuming the definition of extensions aimed at conveying MoS information. [I-D.bajko-mos-dhcp-options] defines the DHCP extensions and this document focuses on the Diameter extensions. 2. Terminology Stupar, et al. Expires August 21, 2008 [Page 3] Internet-Draft MoS-Diameter-extensions February 2008 Mobility Services (MoS) Those services, as defined in the MIH problem statement document [I-D.ietf-mipshop-mis-ps] , which include the MIH IS, CS, and ES services defined by the IEEE 802.21 standard. Home Mobility Services (MoSh) Mobility Services assigned in the mobile node's Home Network. Visited Mobility Services (MoSv) Mobility Services assigned in the Visited Network. 3rd Party Mobility Services (MoS3) Mobility Services assigned in a 3rd Party Network, which is a network that is neither the Home Network nor the current Visited Network. Authentication, Authorization and Accounting (AAA) A set of network management services that respectively determine the validity of a user's ID, determine whether a user is allowed to use network resources, and track users' use of network resources. Home AAA server (HAAA) An AAA server located in the MN's home network. Visited AAA server (VAAA) An AAA server located in the network visited by the MN. Mobile Node (MN) An Internet device whose location changes, along with its point of connection to the network. Network Node (NN) An Internet device whose location and network point of attachment do not change. Mobility Server (MS) A NN providing a MoS. It can be located in the home network, in a visited network or in a 3rd party network. Access Service Authorizer (ASA) A network operator that authenticates a mobile node and establishes the mobile node's authorization to receive Internet service. Access Service Provider (ASP) A network operator that provides direct IP packet forwarding to and from the end host. 3. Overview IEEE 802.21 [IEEE80221] defines three distinct service types (see [I-D.ietf-mipshop-mstp-solution]) to facilitate link layer handovers across heterogeneous technologies. As these services have different Stupar, et al. Expires August 21, 2008 [Page 4] Internet-Draft MoS-Diameter-extensions February 2008 characteristics and purpose, a Mobility Server does not necessarily host all three of these services together, thus there is a need to define a solution enabling the discovery of each MoS or of a set containing all or part of them. This draft integrates the MoS discovery solution defined in [I-D.ietf-mipshop-mstp-solution] and focuses on the required Diameter extensions in order to enable the use of DHCP to discover MoS located both in home network and in the visited network. It focuses on the interface between NAS and AAA and defines Diameter extensions providing MoS-related information. 3.1. Mobility Service scenarios [I-D.ietf-mipshop-mstp-solution] defines a solution to discover MoS. As Mobility Servers can be located in different places, different protocols may be used depending on their location ; to achieve this, the mentioned document defines different scenarios characterized by the position of the Mobility Servers. Such scenarios are the following: Scenario S1 (Home Network MoS): The MN and the services are located in the home network. In this scenario, the MoS is referred as MoSh. Scenario S2 (Visited Network MoS): The MN is in the visited network and mobility services are provided by the visited network. In this scenario, the MoS is referred as MoSv. Scenario S3 (Roaming MoS) The MN is located in the visited network and mobility services are provided by the home network. In this scenario, the MoS is referred as roaming MoS. Scenario S4: Third party MoS The MN is in its home network or in a visited network and services are provided by a 3rd party network in this scenario, these MoS are referred as MoS3. Scenarios S1, S2 and S3 are integrated as the ASA is the entity establishing the authorization for the MN to use any MoS, located in the home or in the visited network. As outlined in [I-D.ietf-mipshop-mstp-solution], in these scenarios MoS can be assigned through DHCP. To achieve this, an interaction between DHCP and AAA is required. Such interaction requires that the NAS and the DHCP Relay are co-located as shown in Figure 1, representing the network elements and the layout taking as reference by this document. Stupar, et al. Expires August 21, 2008 [Page 5] Internet-Draft MoS-Diameter-extensions February 2008 Visited Network | Home Network | +--------------+ | +---------+ | VAAA |<-------Diameter------>| HAAA | +--------------+ | +---------+ /\ | || | || +====+ | +====+ Diameter |MoSv| | |MoSh| || +====+ | +====+ \/ | +-----------------+ | | NAS/ DHCP Relay | | | Diameter Client| | +-----------------+ | /\ | || | 802.1x,EAP, DHCP || \/ +--------+ | MN | +--------+ Figure 1: Network elements layout 3.2. Sequence of operations This section outlines the message flows and actions taken by the network elements that are part of the integrated scenario of MoS assignment. Stupar, et al. Expires August 21, 2008 [Page 6] Internet-Draft MoS-Diameter-extensions February 2008 |=======| |===============| |=============| |=======| |======| MN DHCP Relay/NAS DHCP Server AAA MoS |=======| |===============| |=============| |=======| |======| | | | | | | | | | | |-------(1)------>|<-------(1)-------|-----(1)------>| | | | | | | | | | | | | | | | | | | | | | | | | | | |-------(2)------>|-------(2)------->| | | | | | | | |<----------------|<------(3)--------| | | | | | | | | | | | | | | | | | |<----------------|-------(4)--------|---------------|---------->| Figure 2: Sequence of operations (1) During AAA phase, MN gets authenticated and authorized by the home AAA to get network access. At first MN interacts with the NAS at the visited network, which in turns polls AAA infrastructure to obtain MN access credentials. In this phase, AAA defines which MoS the MN can access to (i.e. if the authorized MoS are MoSh or MoSv and which kind of services are provided). After the successfull authentication and network access authorization, the AAA has provided to the NAS the list of MoS (identified either by a FQDN or their IP address) and the list of service (ES, CS, IS) they are able to provide. To support the MoS assignment, the NAS MUST be able to provide such MoS related information to the DHCP Relay colocated with it. (2) In this phase , node starts DHCP signalling to get the MoS address. It sends a DISCOVER or INFORM message or Information_request depending on supported IP version. In order to request the MoS information, it inserts in the message MoS- information options as described in [I-D.bajko-mos-dhcp-options]. The DHCP Relay inserts the MoS information ( when it is available via NAS) and forward it to the DHCP Server. (3) In this phase DHCP server replies back to the received request by introducing the collected MoS information, which the DHCP server SHOULD extract from the Relay agent option whenever available. This document doesn't specify any solution regarding the collection of MoS information DHCP should make where no options are inserted by the DHCP Relay agent. Stupar, et al. Expires August 21, 2008 [Page 7] Internet-Draft MoS-Diameter-extensions February 2008 After receiving the message back from the DHCP Server, the node owns the list of the assigned MoS and can start using the available services (4) as defined in [IEEE80221]. 4. Commands and AVP This section contains Diameter specifications to convey MoS related information from the HAAA to the NAS for the scenario described in Section 3.2. It extends the HAAA-NAS interface by defining MoS specific AVPs. This specification does not define any new Diameter application. The AVPs defined in this specification MAY be used with any present and the future Diameter application. As title of example, messages defined in [RFC4072] and [RFC4005] are taken into consideration. 4.1. Command codes This section lists the Diameter commands used to convey MIH-MoS AVPs in order to assign MoS-related information in the integrated scenario described in Section 3.1 . Such commands are: Command-Name Abbrev. Code Reference Application Diameter-EAP-Request DER 268 RFC 4072 EAP Diameter-EAP-Answer DEA 268 RFC 4072 EAP AA-Request AAR 265 RFC 4005 NASREQ AA-Answer AAA 265 RFC 4005 NASREQ Figure 3: MIPv6 Bootstrapping NAS to HAAA Interface Command Codes 4.1.1. Diameter-EAP-Request The Diameter-EAP-Request (DER) message defined in [RFC4072], indicated by the Command- Code field set to 268 and the 'R' bit set in the Command Flags field, is sent by the NAS to the Diameter server to initiate a network access authentication and authorization procedure. The DER message format is the same as defined in [RFC4072]. The message MAY include optional MIH-MoS AVPs: Stupar, et al. Expires August 21, 2008 [Page 8] Internet-Draft MoS-Diameter-extensions February 2008 ::= < Diameter Header: 268, REQ, PXY > < Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } { Destination-Realm } { Auth-Request-Type } * [ MIH-MoS-Info ] [ MIH-MoS-Capability ] [ User-Name ] [ Destination-Host ] ... * [ AVP ] 4.1.2. Diameter-EAP-Answer The Diameter-EAP-Answer (DEA) message defined in [RFC4072], indicated by the Command-Code field set to 268 and 'R' bit cleared in the Command Flags field, is sent in response to the Diameter-EAP-Request message (DER). If the network access authentication procedure was successful then the response MAY include any set of MIH-MoS AVPs. The DEA message format is the same as defined in [RFC4072] with an addition of optional MIH-MoS AVPs: ::= < Diameter Header: 268, PXY > < Session-Id > { Auth-Application-Id } { Auth-Request-Type } { Result-Code } { Origin-Host } { Origin-Realm } * [ MIH-MoS-Info ] [ MIH-MoS-Capability ] [ User-Name ] ... * [ AVP ] 4.1.3. AA-Request The Diameter AA-Request (AAR) message defined in [RFC4005], indicated by setting the Command-Code field to 265 and the 'R' bit in the Command Flags field, is used to request authentication and/or authorization for a given NAS user. The AAR message format is the same as defined in [RFC4005]. The message MAY contain additional Stupar, et al. Expires August 21, 2008 [Page 9] Internet-Draft MoS-Diameter-extensions February 2008 MIH-MoS AVPs: ::= < Diameter Header: 265, REQ, PXY > < Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } { Destination-Realm } { Auth-Request-Type } * [ MIH-MoS-Info ] [ MIH-MoS-Capability ] [ User-Name ] [ Destination-Host ] ... * [ AVP ] 4.1.4. AA-Answer The Diameter AA-Answer (AAA) message defined in [RFC4005], indicated by setting the Command-Code field to 265 and clearing the 'R' bit in the Command Flags field, is sent in response to the AA-Request (AAR) message. If the network access authentication procedure was successful then the response MAY include any set of MIH-MoS AVPs. The AAA message format is the same as defined in [RFC4005] with an addition of optional MIH-MoS AVPs: ::= < Diameter Header: 265, PXY > < Session-Id > { Auth-Application-Id } { Auth-Request-Type } { Result-Code } { Origin-Host } { Origin-Realm } * [ MIH-MoS-Info ] [ MIH-MoS-Capability ] [ User-Name ] [ Destination-Host ] ... * [ AVP ] 4.2. Attribute Value Pair Definitions This section defines the AVP introduced by this document. Stupar, et al. Expires August 21, 2008 [Page 10] Internet-Draft MoS-Diameter-extensions February 2008 4.2.1. MIH-MoS-Info The MIH-MoS-Info AVP (AVP code TBD) is of type Grouped and contains necessary information to assign a MoS to the MN. When the MIH-MoS- Info AVP is present in a message, it MUST contain either a MIH-MoS- Address AVP or a MIH-MoS-FQDN AVP, but not both: MIH-MoS-Address SHOULD be preferred over MIH-MoS-FQDN. The grouped AVP has the following grammar: ::= < AVP Header: TBD > [ MIH-MoS-Address ] [ MIH-MoS-FQDN] [ MIH-MoS-type] * [ AVP ] 4.2.2. MIH-MoS-Address AVP The MIH-MoS-Address AVP (AVP Code TBD) is of type Address and contains the MoS address. The Diameter server MAY decide to assign a MoS to the MN depending on different reasons. For example, in case of MoSv, MoS that is in close proximity to the point of attachment (e.g., determined by the NAS-Identifier AVP) MAY be assigned. There may be other reasons for dynamically assigning a MoS to the MN. This AVP MAY also be attached by the NAS when sent to the Diameter server in a request message as a hint of a locally assigned MoS address. 4.2.3. MIH-MoS-FQDN AVP The MIH-MoS-FQDN AVP (AVP Code TBD) is of type UTF8String and contains the FQDN of a MoS. The usage of this AVP is equivalent to the MIH-MoS-Address AVP but offers an additional level of indirection via the DNS infrastructure. 4.2.4. MIH-MoS-type AVP The MIH-MoS-type AVP (AVP Code TBD) is of type Unsigned 32 and contains the type of MoS service the server supports. In case the MoS-related information is reported, the all NULL MIH-MoS_type is implicitly set. The following values are defined: o IS_TYPE (0x00000001): this flag is set when the MoS provides Information Service. o ES_TYPE (0x00000002): this flag is set when the MoS provides Event Service. Stupar, et al. Expires August 21, 2008 [Page 11] Internet-Draft MoS-Diameter-extensions February 2008 o CS_TYPE (0x00000004): this flag is set when the MoS provides Command Service. 4.2.5. MIH-MoS-Capability AVP The MIH-MoS-Capability AVP (AVP Code TBD) is of type Unsigned32 and contains a 32 bits flags field of supported capabilities of the NAS/ ASP. Sending and receiving the MIH-MoS-Capability AVP with value 0 MUST be supported. The NAS MAY include this AVP to indicate capabilities of the NAS/ASP to the Diameter server. For example, the NAS may indicate that a local MoS can be provided. Similarly, the Diameter server MAY include this AVP to inform the NAS/ASP about which of the NAS/ASP indicated capabilities are supported or authorized by the ASA or by the MoS authorizer. The following capabilities are defined in this document: o MoS_SERVCE_CAPABILITY (0x00000001) -- This flag indicates whether the assignment of MoS information is supported or authorized. o LOCAL_MoS_ASSIGNMENT (0x00000002) -- This flag indicates whether the assignement of vMoS information is supported or authorized. The NAS sets the MoS_SERVICE_CAPABILITY bit in order to communicate to HAAA that the assignment of MoS is supported. The HAAA sets this bit in order to allow MoS assignment through the solution outlined in Section 3.2. The LOCAL_MoS_ASSIGNMENT is set either by the NAS or by the VAAA when a local MoS assignment is wished. Additional MIH-MoS-Info MAY be inserted in order to provide a hint to the HAAA about the MoS the visited network is willing to assign. This flag is set when the use of a local MoS is allowed by the HAAA. In this case, HAAA MUST NOT insert any MIH-MoS-Info it received by the visited network but MAY insert own MIH-MoS-Info providing MoS FQDNs or addresses in order to enable the NAS to chose the MoS (vMoS or hMoS) to assign to the MN. 5. AVP Information Tables 5.1. Request and Response Commands AVP Table The following table lists the additional MoS related AVPs that may optionally be present in any Request and Response, independent of the used Diameter application. In the case the Diameter application being used requires multiple round trips, then the Request and Stupar, et al. Expires August 21, 2008 [Page 12] Internet-Draft MoS-Diameter-extensions February 2008 Respone correspond to the first and the last messages of the multiple round trips message exchange. +-----------+ | Cmd-Code | |-----+-----+ Attribute Name | Req | Rep | -------------------------------|-----+-----| MIH-MoS-Info | 0+ | 0+ | MIH-MoS-Capability | 0-1 | 0-1 | +-----+-----+ Figure 9: Request and Response Commands AVP Table 5.2. Mobility Services AVPs The following table describes the Diameter AVPs, their AVP Code values, types, possible flag values, and whether the AVP MAY be encrypted. The Diameter base [RFC3588] specifies the AVP Flag rules for AVPs in Section 4.2. +---------------------+ | AVP Flag rules | +----+-----+----+-----+----+ AVP Section | | |SHLD|MUST | | Attribute Name Code Defined Data Type |MUST| MAY |NOT |NOT |Encr| ------------------------------------------+----+-----+----+-----+----+ MIH-MoS-Info TBD 4.2.1 Grouped | | P | | V,M | Y | MIH-MoS-Address TBD 4.2.2 Address | | P | | V,M | Y | MIH-MoS-FQDN TBD 4.2.3 Grouped | | P | | V,M | Y | MIH-MoS-Type TBD 4.2.4 Unsigned32 | | P | | V,M | Y | MIH-MoS-Capability TBD 4.2.5 Unsigned64 | | P | | V,M | Y | ------------------------------------------+----+-----+----+-----+----+ Figure 10: AVP Flag Rules Table 6. IANA Considerations 6.1. Registration of new AVPs This specification defines the following new AVPs: Stupar, et al. Expires August 21, 2008 [Page 13] Internet-Draft MoS-Diameter-extensions February 2008 MIH-MoS-Info is set to TBD MIH-MoS-Address is set to TBD MIH-MoS-FQDN is set to TBD MIH-MoS-Type is set to TBD MIH-MoS-Capability is set to TBD 6.2. New Registry: Mobility Services Capability IANA is requested to create a new registry for the Mobility Services Capability as described in Section 4.2.5. Token | Value | Description ----------------------------------+--------------+------------ MoS_SERVCE_CAPABILITY | 0x00000001 | [RFC TBD] LOCAL_MoS_ASSIGNMENT | 0x00000002 | [RFC TBD] Available for Assignment via IANA | 2^x | Allocation rule: Only numeric values that are 2^x (power of two) are allowed based on the allocation policy described below. Following the policies outlined in [RFC3775] new values with a description of their semantic for usage with the MIH-MoS-Capability AVP together with a Token will be assigned after Expert Review initiated by the O&M Area Directors in consultation with the DIME working group chairs or the working group chairs of a designated successor working group. Updates can be provided based on expert approval only. A designated expert will be appointed by the O&M Area Directors. No mechanism to mark entries as "deprecated" is envisioned. Based on expert approval it is possible to delete entries from the registry. 6.3. New Registry: Mobility Services Type IANA is requested to create a new registry for the Mobility Services Type as described in Section 4.2.4. Token | Value | Description ----------------------------------+--------------+------------ IS_TYPE | 0x00000001 | [RFC TBD] ES_TYPE | 0x00000002 | [RFC TBD] CS_TYPE | 0x00000004 | [RFC TBD] Available for Assignment via IANA | 2^x | Allocation rule: Only numeric values that are 2^x (power of two) are allowed based on the allocation policy described in Section 6.2. Stupar, et al. Expires August 21, 2008 [Page 14] Internet-Draft MoS-Diameter-extensions February 2008 7. Security Considerations The security considerations for the Diameter interaction required to accomplish the MoS discovery are described in [I-D.ietf-mipshop-mstp-solution]. Additionally, the security considerations of the Diameter base protocol [RFC3588], Diameter NASREQ application [RFC4005] and Diameter EAP [RFC4072] applications (with respect to network access authentication and the transport of keying material) are applicable to this document. This document does not introduce new security vulnerabilities. 8. Acknowledgements Authors would like to thank Victor Fajardo for the valuable comments and support. 9. References 9.1. Normative References [I-D.bajko-mos-dhcp-options] Bajko, G. and S. Das, "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for Mobility Server (MoS) discovery", draft-bajko-mos-dhcp-options-02 (work in progress), February 2008. [I-D.ietf-mip6-bootstrapping-integrated-dhc] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Integrated Scenario", draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in progress), July 2007. [I-D.ietf-mipshop-mis-ps] Melia, T., Hepworth, E., Sreemanthula, S., Ohba, Y., Gupta, V., Korhonen, J., and Z. Xia, "Mobility Services Transport: Problem Statement", draft-ietf-mipshop-mis-ps-05 (work in progress), November 2007. [I-D.ietf-mipshop-mstp-solution] Melia, T., Bajko, G., Das, S., Golmie, N., Xia, Z., and J. Zuniga, "Mobility Services Framework Design", draft-ietf-mipshop-mstp-solution-01 (work in progress), February 2008. [IEEE80221] Stupar, et al. Expires August 21, 2008 [Page 15] Internet-Draft MoS-Diameter-extensions February 2008 "Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services", IEEE LAN/ MAN Draft IEEE P802.21/D07.00, July 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005. [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005. Authors' Addresses Patrick Stupar (editor) NEC Kurfursten-Anlage 36 Heidelberg 69115 Germany Phone: +49/(0)62214342215 Email: patrick.stupar@nw.neclab.eu Subir Das Telcordia Phone: Email: subir@research.telcordia.com Stupar, et al. Expires August 21, 2008 [Page 16] Internet-Draft MoS-Diameter-extensions February 2008 Jouni Korhonen Teliasonera Teollisuuskatu 13 Sonera FIN-00051 Finland Email: jouni.korhonen@teliasonera.com Telemaco Melia Cisco Avenue des Uttins 5 Rolle 1180 Switzerland (FR) Email: tmelia@cisco.com Stupar, et al. Expires August 21, 2008 [Page 17] Internet-Draft MoS-Diameter-extensions February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Stupar, et al. Expires August 21, 2008 [Page 18]