Subject: [MIPSHOP-MIH-DT] Current status

From: Telemaco Melia <[email-masked]>
Date: Thu, 30 Aug 2007 17:46:10 +0200

Dear all,

I have been reading the input Gabor provided with the IDs 
draft-bajko-mos-dhcp-options-00 and draft-bajko-mos-dns-discovery-00.
Thanks Gabor for the work. Here my comments:

o draft-bajko-mos-dhcp-options-00
-1 terminology section should be aligned with the PS doc
-2 introduction section: I do not think it is required, I would prefer 
to refer to the solution doc and move the text there if you want.
-3 discussion on co-located MoS: move it to the solution document when 
we talk about the transport

o draft-bajko-mos-dns-discovery-00
- same as before for 1 and 2
- refer to the solution document when you discuss on the selection of 
the transport

During the nect AC we should then discuss the open points noted in the 
draft.
I also would like to receive from Nada an update of the current status 
and see what text we can included in the first version of the document.

As for the time of the AC I would propose to have it at 14:00 CET on 
Tuesday September 4th.
Would  be fine with everybody?

Please le me know

Telemaco

Mipshop WG                                                 T. Melia, Ed.
Internet-Draft                                                       NEC
Intended status: Standards Track                                  S. Xia
Expires: January 25, 2008                                         Huawei
                                                               N. Golmie
                                                                    NIST
                                                                 H. Jang
                                                                 Samsung
                                                                  S. Das
                                                               Telcordia
                                                                G. Bajko
                                                                   Nokia
                                                              JC. Zuniga
                                                            InterDigital
                                                           July 24, 2007

              Mobility Services Transport Protocol Design
                   draft-xxx-mipshop-mstp-solution-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 January 25, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Melia, et al.           Expires January 25, 2008                [Page 1]

Internet-Draft                    MSTP                         July 2007

Abstract

   To be edited.

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.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . .  3
   4.  Solution Overview  . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  Architecture . . . . . . . . . . . . . . . . . . . . . . .  8
     4.2.  MIHF Identifiers (FQDN, NAI) . . . . . . . . . . . . . . .  9
   5.  MoS Discovery  . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  MoS Discovery in the home network  . . . . . . . . . . . .  9
     5.2.  MoS Discovery in the local network . . . . . . . . . . . .  9
     5.3.  MoS discovery in a remote network  . . . . . . . . . . . . 10
   6.  MIH Transport  . . . . . . . . . . . . . . . . . . . . . . . . 10
     6.1.  Fragmentation  . . . . . . . . . . . . . . . . . . . . . . 11
     6.2.  Congestion Control . . . . . . . . . . . . . . . . . . . . 11
   7.  Operation Flows  . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
     11.2. Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 15

Melia, et al.           Expires January 25, 2008                [Page 2]

Internet-Draft                    MSTP                         July 2007

1.  Introduction

   This document proposes a solution to the issues indetified in the
   problem statement document [ref to PS] for the transport of IEEE
   802.21 MIH protocols.

   The MIH Layer 3 transport problem is divided in two main parts: the
   discovery of mobility services (MoS) and the transport of the
   information between MN and MoS.  The discovery process is required
   for MIH function located in the MN to discover the peer MIHF (e.g.
   the IP address) of the MoS in the network (e.g. the Point of Service,
   PoS) either during attachment or during handover.  Upon succesfull
   discovery, the MIH peers can then exchange information in the form of
   MIH messages.

   This document considers firstly standard track IETF-based solutions
   for the design and recommendations of the discovery and transport
   protocol components.

2.  Terminology

   The following terminology is being used:

   MIH  Media Independent Handover

   MN Mobile Node

   NN Network Node

   MIHFID  MIH Identifier

   MIHF  MIH Function

   MoSh  Mobility Services at the Home Network

   MoSv  Mobility Services at the Visited Network

   MoS3  Mobility Services at a 3rd Party Network

3.  Deployment Scenarios

   The follwoing scenarios have been identified:

Melia, et al.           Expires January 25, 2008                [Page 3]

Internet-Draft                    MSTP                         July 2007

   S1 Home Network MoS, the MN and the services are located in the home
      network.  We refer to this as MoSh as in Figure 1.

   +--------------+  +====+
   | HOME NETWORK |  |MoSh|
   +--------------+  +====+
        /\
        ||
        \/
   +--------+
   |   MN   |
   +--------+

                      Figure 1: MoS in the Home network

   S2 Visisted Network MoS, MN is in the visited network and mobility
      services are also provided by the visited network.  We refer to
      this as MoSv Figure 2.

             +--------------+
             | HOME NETWORK |
             +--------------+
                   /\
                   ||
                   \/
    +====+ +-----------------+
    |MoSv| | VISITED NETWORK |
    +====+ +-----------------+
                   /\
                   ||
                   \/
               +--------+
               |   MN   |
               +--------+

                    Figure 2: MoSV in the Visited Network

   S3 Roaming MoS, MN is in the visited network and all services are
      provided by the home network.

Melia, et al.           Expires January 25, 2008                [Page 4]

Internet-Draft                    MSTP                         July 2007

    +====+   +--------------+
    |MoSh|   | HOME NETWORK |
    +====+   +--------------+
                   /\
                   ||
                   \/
          +-----------------+
          | VISITED NETWORK |
          +-----------------+
                   /\
                   ||
                   \/
               +--------+
               |   MN   |
               +--------+

             Figure 3: MoS provided by the home while in visited

   S4 Third party MoS, MN is in home or visited network and services are
      provided by a 3rd party network.  We refer to this as MoS3
      Figure 4.

      (preamble)
                                      +--------------+
                                      | HOME NETWORK |
   +====+    +--------------+         +--------------+
   |MoS3|    | THIRd PARTY  |  <===>        /\
   +====+    +--------------+               ||
                                            \/
                                    +-----------------+
                                    | VISITED NETWORK |
                                    +-----------------+
                                            /\
                                            ||
                                            \/
                                        +--------+
                                        |   MN   |
                                        +--------+
      (postamble)

                       Figure 4: MoS form a third party

4.  Solution Overview

   As mentioned in the introduction the solution space is being divided
   in discovery and transport.  The follwoing assumptions have been
   made:

Melia, et al.           Expires January 25, 2008                [Page 5]

Internet-Draft                    MSTP                         July 2007

   o  The solution is aimed at supporting 802.21 MIH services, namely
      Information Services (IS), Event Services (ES), and Command
      Services (CS).

   o  If the MIHFID is available, FQDN or NAI's realm is used for
      mobility service discovery.  The recommentdation to the IEEE
      802.21 WG is to restrict to only these two.

   o  The solutions are choosen to cover all possible deployment
      scenarios as described in section 3.

   o  MIHF discovery can be performed during initial network attachment
      or thereafeter.

   For the discovering the location of an MoS, the MN could either be
   pre-configured with the address of the MoS, or this address could be
   dynamilcally assigned through DHCP or DNS by the network.  The
   dynamic assignation methods are described in section 5.

   The configuration of the MoS could be executed either upon network
   attachment or after succesfull IP configuration.  The methodology to
   be used depends on the considered deployment scenario.

   Once the MIHF peer has been discovered, MIH information can be
   exchanged between peers over UDP and TCP.  The usage of these
   protocols is described in section 6.

   For DHCPv4 based solutions the following example holds.

Melia, et al.           Expires January 25, 2008                [Page 6]

Internet-Draft                    MSTP                         July 2007

                           MIH ENABLED MN
     +---------------+     +-------------+
     |  DHCP SERVER  |     | DHCP CLIENT |
     +---------------+     +------|------+
             |                    |
             |    DHCP DISCOVER   |
             |<===================|DHCP DISCOVER
             |                    |WITH MoS option
             |                    |
             |    DHCP OFFER      |
             |===================>|DHCP OFFER
             |                    |WITH MoS
             |   DHCP REQUEST     |
             |<===================|
             |     DHCPACK        |
             |===================>|
             |                    |

   Using DHCP 4-way handshake

                 Figure 5: Discovering MoS Function (MIHF)

   Upon layer-two network attachement the MN broadcasts DHCP DISCOVER
   messages according to standard [RFC 2132].  According to standard
   behavior the MN can wait to receive multiple replies from DHCP
   servers.  In any case the MN adds the MoS option to the discover
   message.  The DHCP offer message will then contain the IP address of
   the MoS.

                          MIH ENABLED MN
    +---------------+     +-------------+
    |  DHCP SERVER  |     | DHCP CLIENT |
    +---------------+     +------|------+
            |                    |
            |    DHCP INFORM     |
            |<===================|DHCP INFORM
            |                    |WITH MoS option
            |     DHCPACK        |
            |===================>|
            |                    |

   Using DHCP 2-way handshake

                 Figure 6: Discovering MoS Function (MIHF)

   Figure 6 shows the 2 way hanshake operation with MoS option enabled.

Melia, et al.           Expires January 25, 2008                [Page 7]

Internet-Draft                    MSTP                         July 2007

   For DHCPv6 based solutions we should distinguish between having
   stateless autoconfiguration and DHCP two messages based exchange or
   stateful configuration, thus four messages based exchange.  The
   follwoing figure shows how discovery of the MoS can be done through
   the first method.

   +--------------+     +--------------+
   |  DHCP CLIENT |     |  DHCP SERVER |
   +------|-------+     +-------|------+
          |                     |
          |                     |
          | INFORMATION-REQUEST |
          |====================>|
          |                     |
          |   REPLY             |
          |<====================|
          |                     |
          |                     |

                  Figure 7: DHCPv6 two messages exchange

   The INFORMATION REQUEST message is sent to the multicast FF02::1:2
   address containing an "Option Request" option.  Based on the "Client
   identifier" option the DHCP server can send a REPLY message including
   the option requested by the client.  In this case the option will
   refer to the MoS IP address being discovered.

   Should we add and informative flow for the case where the address is
   assigned via stateless autoconf?

   Figure (Figure 5) , figure (Figure 6)and figure (Figure 7) meets the
   requiremetns imposed by scenarios S1 and S2.  S3 needs tight
   interaction with the AAA infrastructure.  The follwoing picture show
   show the system i ssupposed to work.

   NOTE: add the picture for DHCP/AAA discovery.

   S4 can be supported only via DNS discovery.

   NOTE: add an example of how we intend to support discovery via DNS.

4.1.  Architecture

   The following figure depicts the MSTP reference model and its
   components.

Melia, et al.           Expires January 25, 2008                [Page 8]

Internet-Draft                    MSTP                         July 2007

    +--------------------------+
    |           MIHF           |
    +--------------------------+
        ||         ||       ||
    +---------+ +------+ +-----+
    | TCP/UDP | | DHCP | | DNS |
    +---------+ +------+ +-----+

                            Figure 8: MN stack

   As it can be seen, the MIHF relies on the services provided by TCP
   and UDP for transport, as well as DHCP and DNS for peer discovery.

4.2.  MIHF Identifiers (FQDN, NAI)

   An MIHID is an identifier required to uniquely identify the MIHF end
   points for delivering the mobility services (MoS).  Thus an MIHF
   identifier needs to be unique within a domain whereby mobility
   services are provided and invariant to interface IP addresses.  An
   MIHFID MUST be represented either in the form of an FQDN [REFERENCE]
   or NAI [REFERNCE].  An MIHFID can be pre-configured or discovered
   through the discovery methods as described in Section 5.

5.  MoS Discovery

   The MoS discovery method depends on whether the MN wants to discover
   an MoS in the local network, home network or a remote network other
   than home network.

5.1.  MoS Discovery in the home network

   To discover an MoS in the home network, the MN SHOULD use the DNS
   based MoS discovery method described in [draft-bajko-dns-discovery].
   In order to use that, the MN MUST first find out the domain name of
   its home network.  Home domains are usually preconfigured in the MNs,
   thus the MN can simply read its configuration data to find out the
   home domain name (scenario s1).

   Alternatively, the MN MAY use the dhcp options for MoS discovery
   [draft-bajko-dhcp-mos].  When the MN is roaming, using this dhcp
   options may require the MN to first perform network access
   authentication (scenario s3).

5.2.  MoS Discovery in the local network

   (scenario s2) To discover an MoS in the local network, the MN SHOULD
   attempt to use the dhcp options for MoS discovery

Melia, et al.           Expires January 25, 2008                [Page 9]

Internet-Draft                    MSTP                         July 2007

   [draft-bajko-dhcp-mos].  If the dhcp method fails, the MN SHOULD
   attempt to use the DNS based MoS discovery method described in
   [draft-bajko-dns-discovery].  In order to use that, the MN MUST first
   learn the domain name of the local network.  There are a number of
   ways how the domain name of a network can be learned:

   DHCP  In order to find out the domain name of the local network, the
      MN SHOULD use the dhcpv4 option 15 for learning the domain name
      [RFC1533].  Similar solution is available for dhcpv6
      [draft-ietf-dhc-dhcpv6-opt-dnsdomain].

   Reverse dns query  When dhcp does not provide the required domain
      name, the MN MAY use reverse dns (dns PTR record) to find the
      domain name associated with the IP address it is using in the
      local network.  Note, that when a NAT device exists between the MN
      and the local network, the MN will first need to find out the
      external IP address of the NAT device.  Some possible methods for
      determining the NAT's external IP address are STUN [RFC3489] or
      UPnP [UPnP_IDG_DCP].  Once the MN determined the external IP
      address of the NAT device, it MUST use that address in the reverse
      DNS query.

5.3.  MoS discovery in a remote network

   (scenario s4) To discover an MoS in a remote network other than home
   network, the MN MUST use the DNS based MoS discovery method described
   in [draft-bajko-dns-discovery].  In order to use that, the MN MUST
   first learn the domain name of the network it is looking for an MoS
   in.  If the MN does not yet know the domain name of the network,
   learning it may require more than one operation, as pre-configuration
   and dhcp can not be used.  The MN MAY attempt to first discover an
   MoS in either the local or home network and query that MoS to find
   out the domain name of a specific network or the domain name of a
   network at a specific location.  Alternatively, the MN MAY query an
   MoS previously known to learn the domain name of the desired network.

6.  MIH Transport

   Once the Mobility Services have been discovered, MIH peers MUST
   exchange information over TCP or UDP.  Both protocols provide a well
   proven transport for MIH messages.  There are advantages and
   disadvantages with using each one of them.  Therefore, some
   guidelines are hereby provided.

   As recommend in [draft-ietf-tsvwg-udp-guidelines-02.txt] an
   MIHFSHOULD NOT send UDP messages that result in IP packets that
   exceed the MTU of the path to the destination, and the UDP checksum

Melia, et al.           Expires January 25, 2008               [Page 10]

Internet-Draft                    MSTP                         July 2007

   option SHOULD be enabled.  Since ES ans CS messages are small in
   nature and have tight latency requirements, UDP in combination with
   MIH acknowledgement SHOULD be used for transporting ES and CS
   messages, as well as small IS messages.

   Also, as explained in [draft-ietf-tsvwg-udp-guidelines-02.txt],
   communication failures may be experienced when middleboxes destroy
   the per-flow state associated with an application session during
   periods when the application does not exchange any UDP traffic.
   Hence, communication between the MN and the MoS SHOULD be able to
   gracefully handle such failures and implement mechanisms to re-
   establish their UDP sessions.  In addtition and in order to avoid
   such failures, MIH messages MAY may be sent periodically, similarly
   to keep-alive messages, to attempt to refresh middlebox state (e.g.
   ES reports could be used for this purpose).  Unfortunately, no common
   timeout has been specified for per-flow UDP state for arbitrary
   middleboxes.  For NATs however, [RFC4787] requires a state timeout of
   2 minutes or longer, and it is likely that other types of middleboxes
   use timeouts of similar timescales.  Hence, MIH messages using UDP as
   traqnsport SHOULD be sent once every two minutes.

   On the other hand, IS messages are more resilent in terms of latency
   constraints and some long IS messages could exceed the MTU of the
   path to the destination.  Therefore, TCP SHOULD be used for
   transporting IS messages, especially if these messages exceed the MTU
   of the path to the destination.

   For both UDP and TCP cases, if a port number is not explicitly
   assigned (e.g. by the DNS SRV), MIH messages sent over UDP or TCP
   MUST use the default port number.

6.1.  Fragmentation

   NOTE JCZ: waiting for input from Nada

6.2.  Congestion Control

   NOTE JCZ: waiting for input from Nada

7.  Operation Flows

   NOTE: Include here flows for each of the scenarios we want to
   support.  Not yet assigned

Melia, et al.           Expires January 25, 2008               [Page 11]

Internet-Draft                    MSTP                         July 2007

8.  Security Considerations

   There are a number of security issues that need to be taken into
   account during node discovery and information exchange via a
   transport connection [refer PS draft]

   In case where DHCP is used for node discovery and authentication of
   the source and content of DHCP messages are required, it is
   receommended that network administrators should use DHCP
   authentication option described in RFC 3118 [DHCP Authentication].
   This will also protect the denial of service attacks to DHCP server.
   RFC 3118 provides mechanisms for both entity authentication and
   message authentication.

   In case where DNS is used for discovering the IP address of the MIHF
   and mobility services and data origin authentication and data
   integrity are required it is recommended that DNS service providers
   should use the Domain Name System Security Extensions (DNSSEC) as
   decsribed in RFC 4033 [DNSSEC].  Readers may also refer to RFC
   [DNSSEC Operational prcatice] to consider the aspects of DNSSEC
   Operational Practices.

9.  IANA Considerations

   This document registers the following TCP and UDP port(s) with IANA:

   discard XXX/mih Discard YY:ZZZ

10.  Acknowledgements

   ....

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

11.2.  Informative References

   [Anchor]   "", 2005.

Melia, et al.           Expires January 25, 2008               [Page 12]

Internet-Draft                    MSTP                         July 2007

Authors' Addresses

   Telemaco Melia (editor)
   NEC

   Phone:
   Fax:
   Email:
   URI:

   Sam Xia
   Huawei

   Phone:
   Fax:
   Email:
   URI:

   Nada Golmie
   NIST

   Phone:
   Fax:
   Email:
   URI:

   Heejin Jang
   Samsung

   Phone:
   Fax:
   Email:
   URI:

Melia, et al.           Expires January 25, 2008               [Page 13]

Internet-Draft                    MSTP                         July 2007

   Subir Das
   Telcordia

   Phone:
   Fax:
   Email:
   URI:

   Gabor Bajko
   Nokia

   Phone:
   Fax:
   Email:
   URI:

   Juan Carlos Zuniga
   InterDigital

   Phone:
   Fax:
   Email:
   URI:

Melia, et al.           Expires January 25, 2008               [Page 14]

Internet-Draft                    MSTP                         July 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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
   [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Melia, et al.           Expires January 25, 2008               [Page 15]


_______________________________________________
MIPSHOP-MIH-DT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt

---

From: Gabor Bajko <[email-masked]>
Date: Fri, 31 Aug 2007 23:08:07 +0300 (EEST)

Hi,

14.00 CET is 5am pacific time, that is to early for me. What about 14.00 PST?

- gabor

> -----Original Message-----
> From: ext Zuniga, Juan Carlos
> Received: Fri Aug 31 22:10:08 EEST 2007
> To: Telemaco Melia
> Cc: [email-masked]
> Subject: RE: [MIPSHOP-MIH-DT] Current status
> 
> 
> Hello,
> 
> 14:00 CET on Tuesday September 4th is ok for me.
> 
> Jc
> 
> -----Original Message-----
> From: Telemaco Melia [mailto:[email-masked]] 
> Sent: August 30, 2007 11:46 AM
> To: [email-masked]
> Subject: [MIPSHOP-MIH-DT] Current status
> 
> Dear all,
>