[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/