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-EAP-Request> ::= < 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-EAP-Answer> ::= < 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:
<AA-Request> ::= < 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:
<AA-Answer> ::= < 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:
<MIH-MoS-Info> ::= < 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]