Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [802.21] IETF draft on problem statement



Title: Vice Chair candidate
Hello, 
Here is a draft version of the internet-draft that is due on 6th March to the IETF that contains the 802.21  problem statement encompassing all MIH services. Your comments are most welcome. 
Regards, 
Srini




MIPSHOP                                                      E. Hepworth
Internet-Draft                               Siemens Roke Manor Research
Expires: August 29, 2006                                        G. Daley
                                                               Panasonic
                                                         S. Sreemanthula
                                                               S. Faccin
                                                   Nokia Research Center
                                                                G. Vivek
                                                                   Intel
                                                       February 25, 2006


        Problem Statement: Media Independent Handover Signalling
            draft-hepworth-mipshop-mih-problem-statement-01

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 29, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   There are on-going activities in the networking community to develop
   solutions for handover between heterogeneous wired and wireless



Hepworth, et al.         Expires August 29, 2006                [Page 1]

Internet-Draft               MIH Signalling                February 2006


   access systems including, but not limited to, IEEE 802.21.
   Intelligent access selection, taking into account link layer
   attributes, requires the delivery of a variety of different
   information types to the terminal from different sources within the
   network.  The protocol requirements for this signalling have both
   transport and security issues that must be considered.  The
   signalling must not be constrained to specific link types, so there
   is at least a common component to the signalling problem which is
   within the scope of the IETF.  This draft presents a problem
   statement for this core problem.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Entities . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  End-to-End Signalling and Transport over IP  . . . . . . .  4
     2.2.  End-to-End Signalling and Partial Transport over IP  . . .  4
     2.3.  End-to-End Signalling with a Proxy . . . . . . . . . . . .  5
   3.  Solution Components  . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Payload Formats and Extensibility Considerations . . . . .  8
   4.  Requirements on the Mobility Service Transport Layer . . . . . 10
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   6.  Conclusions and Open Issues  . . . . . . . . . . . . . . . . . 13
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 14
   Appendix B.  Relationship to IEEE 802.21 . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
   Intellectual Property and Copyright Statements . . . . . . . . . . 17






















Hepworth, et al.         Expires August 29, 2006                [Page 2]

Internet-Draft               MIH Signalling                February 2006


1.  Introduction

   This Internet Draft provides a problem statement for the exchange of
   information to support handover in heterogeneous link environments.
   This mobility support service allows more sophisticated handover
   operations by making available information about network
   characteristics, neighbouring networks and associated
   characteristics, indications that a handover should take place, and
   suggestions for suitable target networks to which to handover.

   There are two key attributes to the handover support service problem:

   1.  The Information and Information Exchange mechanism: this includes
       the information elements that describe the information, and any
       signalling exchanges that are required to support the transfer of
       these Information Elements.

   2.  The Underlying Transport: this supports the Information Exchange
       between devices in the network.  The requirements on this
       transfer mechanism include transport issues, because of the
       volume of data to be sent, as well as security issues, as the
       signalling may cross administrative boundaries and is
       interdependent with AAA aspects.

   This draft has been motivated by on-going work within IEEE 802.21,
   but the following description intentionally describes the problem
   from a more general perspective.  This document represents the views
   of the authors, and does not represent the official view of IEEE
   802.21.

   The structure of this document is as follows.  Section 2 provides a
   simple model for the entities involved in the signalling and their
   possible relationships.  Section 3 describes a decomposition of the
   signalling problem into service specific parts and a generic
   transport part.  Section 4 describes more detailed requirements for
   the transport component.  Section 5 provides security considerations,
   and Section 6 summarises the conclusions and open issues.


2.  Entities

   The following section provides an overview of the network entities
   that are expected to be involved in the signalling exchanges to
   support the handover operation.  The following abbreviations are used
   in this section:






Hepworth, et al.         Expires August 29, 2006                [Page 3]

Internet-Draft               MIH Signalling                February 2006


   o  MN: mobile node

   o  NN: network node, intended to represent some device in the network
      (the location of the node e.g. in the access network, home network
      is not specified, and for the moment it is assumed that they can
      reside anywhere).

   o  EP: endpoint, intended to represent the terminating endpoints of
      the transport protocol used to support the signalling exchanges
      between nodes.

   The deployment sceanrios are outlined in the following sections.
   Note: while MN-to-MN signalling exchanges are theoretically possible,
   these are not currently being considered, and are out-of-scope.

2.1.  End-to-End Signalling and Transport over IP

   In this case, the end-to-end signalling used to exchange the handover
   information elements (the Information Exchange) runs end-to-end
   between MN and NN.  The underlying transport is also end-to-end

           +------+                              +------+
           |  MN  |                              |  NN  |
           | (EP) |                              | (EP) |
           +------+                              +------+
                        Information Exchange
               <------------------------------------>

               /------------------------------------\
              <          Transport over IP           >
               \------------------------------------/

   Figure 1: End-to-end Signalling and Transport

2.2.  End-to-End Signalling and Partial Transport over IP

   As before, the Information Exchange runs end-to-end between the MN
   and the second NN.  However, in this scenario, some other transport
   means is used from the MN to the first NN, and the transport over IP
   is used only between NNs.  This is analogous to the use of EAP end-
   to-end between Supplicant and Authentication Server, with a upper-
   layer multihop protocol such as RADIUS used as a backhaul transport
   protocol between an Access Point and the Authentication Server.








Hepworth, et al.         Expires August 29, 2006                [Page 4]

Internet-Draft               MIH Signalling                February 2006


           +------+           +------+           +------+
           |  MN  |           |  NN  |           |  NN  |
           |      |           | (EP) |           | (EP) |
           +------+           +------+           +------+
                        Information Exchange
               <------------------------------------>

                (Transport over  /------------------\
               <--------------->< Transport over IP  >
                    e.g. L2)     \------------------/

   Figure 2: Partial Transport

2.3.  End-to-End Signalling with a Proxy

   In the final case, a number of proxies are inserted along the path
   between the two transport endpoints.  The use of proxies is possible
   in both cases 1 and 2 above, but distinguished here as there are a
   number of options as to how the proxy may behave with regard to the
   transport and end-to-end signalling exchange.

   o  Information Exchange Approach


      In this case, the proxy performs some processing on the
      Information Exchange before forwarding the information on.  This
      can be viewed as concatenating signalling exchanges between a
      number of EPs.

           +------+         +---------+          +------+
           |  MN  |         | ProxyNN |          |  NN  |
           | (EP) |         |   (EP)  |          | (EP) |
           +------+         +---------+          +------+
                       Information Exchange
              ------------------>
                                ------------------->
                                <-------------------
              <------------------
              /---------------\     /----------------\
             <    Transport    >   <    Transport     >
              \---------------/     \----------------/

      Figure 3: Information Exchange Approack

      The Proxy NN processes all layers of the protocol suite in the
      same way as an ordinary EP.





Hepworth, et al.         Expires August 29, 2006                [Page 5]

Internet-Draft               MIH Signalling                February 2006


   o  Redirection Approach


      In this case, the redirection NN processes enough of the
      Information Exchange to forward the message to the correct
      ultimate NN for that MN and service type.  Subsequent Information
      Exchanges take place between the MN and NN.


            +------+         +----------+         +------+
            |  MN  |         | Redirect |         |  NN  |
            | (EP) |         |    NN    |         | (EP) |
            +------+         +----------+         +------+
                        Information Exchange
               ------------------> ------------------->
               [------Minimal Transport/Security------]

                        Information Exchange
               <-------------------------------------->
               /--------------------------------------\
              <              Transport                 >
               \--------------------------------------/

      Figure 4: Redirection Approach

      The initial messages are assumed to have minimal transport
      requirements.  The main information exchange takes place directly
      between the endpoints.

   o  Directory Approach





















Hepworth, et al.         Expires August 29, 2006                [Page 6]

Internet-Draft               MIH Signalling                February 2006


      In this scenario, the MN (EP) carries out an Information Exchange
      with a Directory node in the network to determine which NN should
      be used for subsequent Information Exchanges.

           +------+        +------------+        +------+
           |  MN  |        | Directory  |        |  NN  |
           | (EP) |        |    (EP)    |        | (EP) |
           +------+        +------------+        +------+
              Information Exchange
              ------------------->
              <-------------------
          [Minimal Transport/Security]

                       Information Exchange
              <------------------------------------->
              /--------------------------------------\
             <              Transport                 >
              \--------------------------------------/

      Figure 5: Directory Approach

      The Information Exchange with the Directory requires only minimal
      processing, just enough to determine the appropriate NN for the MN
      to use.  Transport and security requirements for the lookup phase
      are typically very limited.  This option provides one approach to
      supporting initial node discovery, where subsequent Information
      Exchanges are carried out directly between two peers.

   The question as to which of these proxy options should be considered
   is still open.


3.  Solution Components

   Figure 6 shows a model where the Information Exchanges are
   implemented by a signalling protocol specific to a particular
   mobility service, and these are relayed over a generic transport
   layer (the Mobility Service Transport Layer).













Hepworth, et al.         Expires August 29, 2006                [Page 7]

Internet-Draft               MIH Signalling                February 2006


                           +----------------+          ^
                           |Mobility Support|          |
                           |   Service 2    |          |
        +----------------+ |   (e.g. ES)    |          | Mobility Service
        |Mobility Support| +----------------+          |    Signaling
        |    Service 1   |    +----------------+       |      Layer
        |   (e.g. IS)    |    |Mobility Support|       |
        +----------------+    |   Service 3    |       |
                              |    (other)     |       |
                              +----------------+       V
      ================================================
         +---------------------------------------+     ^ Mobility Service
         |  Mobility Service Transport Protocol  |     |    Transport
         +---------------------------------------+     V      Layer
      ================================================
         +---------------------------------------+
         |                   IP                  |
         +---------------------------------------+

   Figure 6: Handover Services over IP

   The Mobility Service Transport Layer provides certain functionality
   (outlined in Section 4) to the higher layer mobility support services
   in order to support the exchange of information between communicating
   mobility service functions.  The transport layer effectively provides
   a container capability to mobility support services, as well as any
   required discovery, transport and security operations required to
   provide communication.

   The Mobility Support Services themselves may also define certain
   protocol exchanges to support the exchange of service specific
   Information Elements.  It is likely that the responsibility for
   defining the contents and significance of the Information Elements is
   the responsibility of other standards bodies other than the IETF.
   Example mobility services include the Media Independent Information
   Service [1], and the Media Independent Command and Event Services
   [2].

3.1.  Payload Formats and Extensibility Considerations












Hepworth, et al.         Expires August 29, 2006                [Page 8]

Internet-Draft               MIH Signalling                February 2006


   The format of the Mobility Service Transport Protocol is as follows:

   +----------------+----------------------------------------+
   |Mobility Service|           Opaque Payload               |
   |Transport Header|     (Mobility Support Service)         |
   +----------------+----------------------------------------+

   Figure 7: Protocol Structure

   The opaque payload encompasses the Mobility Support Service
   information that is to be transported.  The definition of the
   Mobility Service Trabsport Header is something that is best addressed
   within the IETF.

   The Mobility Support Service payload format also includes a header,
   which could vary depending on the definition of each Mobility Support
   Service.

                     +----------------+-------------------------------+
   Mobility Support  |    Header      |            Payload            |
     Service 1 (IS)  |                |(Mobility Support Service Data)|
                     +----------------+-------------------------------+

                     +--------+---------------------------------------+
   Mobility Support  | Header |                Payload                |
   Service 2 (other) |        |    (Mobility Support Service Data)    |
                     +--------+---------------------------------------+

   Figure 8: Protocol Structure

   There are a number of issues with regard to the Mobility Support
   Service header and payload definition.  These include:

   1.  Responsibility for defining the header: where should the contents
       of the Mobility Support Service header be defined, and should
       there be one or multiple header definitions (i.e. will a common
       header definition for all mobility support services be
       adequate?).  Where there are commonalities, it may indicate that
       these aspects should actually be included in the Mobility Service
       Transport Header.

   2.  Payload Format: the format or the Mobility Support Service Data
       payload could be represented in a number of formats, e.g.  TLV,
       ASN/1, XML or text.  Ideally, a single payload representation
       should be defined, as support for multiple formats leads to
       unnecessary complexity.  It is expected that a set of Data
       Objects will be defined for the Mobility Support Services to
       exchange.



Hepworth, et al.         Expires August 29, 2006                [Page 9]

Internet-Draft               MIH Signalling                February 2006


   3.  Sharing of Data Objects: which refers to sharing the definitions
       of Data Objects between Mobility Support Services, e.g. if a
       Capabilities object is defined that is used by multiple Mobility
       Support Services, should the same definition be used by all of
       them.  If this is the case, then a common identifier space is
       needed to identify the different Data Objects.  There is a
       question about where the definition of Data Objects and the
       management of the identifier space should take place.

   The answers to some of the above issues may in part depend on how
   many standards groups are interested in defining their own Mobility
   Support Services.


4.  Requirements on the Mobility Service Transport Layer

   The following section outlines some of the general transport
   requirements that should be supported by the Mobility Service
   Transport Protocol.  Analysis within IEEE 802.21 has suggested that
   at least the following need to be taken into account:

   Discovery: MNs need the ability to locate nodes that support
      particular mobility services in the network.  There are no
      assumptions about the location of these mobility services within
      the network, therefore the discovery mechanism needs to operate
      across administrative boundaries.  Issues such as speed of
      discovery, when discovery needs to take place, and the length of
      time over which the discovery information may remain valid all
      need to be considered.  Similar discovery requirements may apply
      to general NN discovery in the network.

   Information from a trusted source: The MN uses the Mobility Service
      information to make decisions about what steps to take next.  It
      is essential that there is some way to ensure that the information
      received is from a trustworthy source.  This includes cases where
      trusted proxies along the path have access to, and may modify,
      parts of the Mobility Service information.  This requirement
      should reuse trust relationships that have already been
      established in the network, for example, on the relationships
      established by the AAA infrastructure after a mutual
      authentication, or on the certificate infrastructure required to
      support SEND.

   Low latency: Some of the Mobility Services generate time sensitive
      information.  Therefore, there is a need to deliver the
      information over quite short timescales, and the required lifetime
      of a connection might be quite short lived.  For reliable
      delivery, short-lived connections could be set up as and when



Hepworth, et al.         Expires August 29, 2006               [Page 10]

Internet-Draft               MIH Signalling                February 2006


      needed, although there is a connection setup latency associated
      with this approach.  Alternatively, a long-lived connection could
      be used, but this requires advanced warning of being needed and
      some way to maintain the state associated with the connection.  It
      also assumes that the relationships between devices supporting the
      mobility service are fairly stable.  Another alternative is
      connectionless operation, but this has interactions with other
      requirements such as reliable delivery.

   Reliability: Reliable delivery for some of the mobility services may
      be essential, but it is difficult to trade this off against the
      low latency requirement.  It is also quite difficult to design a
      robust, high performance mechanism that can operate in
      heterogeneous environments, especially one where the link
      characteristics can vary quite dramatically.  There are two main
      approaches that could be adopted:

      1.  Assume the transport cannot be guaranteed to support reliable
          delivery.  In this case, the Mobility Support Service itself
          will have to provide some sort of reliability mechanism to
          allow communicating endpoints to acknowledge receipt of
          information.

      2.  Assume the underlying transport will deal with most error
          situations, and provide a very basic acknowledgement mechanism
          that (if no acknowledgement is received) will indicate that
          something more serious has occurred than a packet drop (since
          these other types of error conditions are dealt with at the
          transport layer).

      Option 1 has a number of diasadvantges associated with it, namely
      that ultimately the protocol design ends up re-inventing a lot of
      the functionality already avaialble in lower layers at a higher
      layer where access to information about what is going on in the
      network is restricted.  For example, how will the higher layer
      determine the cause of the error, if a message is lost due to
      network congestion, it is pointless sending the message again.  It
      also adds to the complexity of the higher layer protocol, and
      makes successful deployment less certain (the protocol will have
      to be trialled in a number of network situations instead of re-
      using a protocol that has already been tested).

   Congestion Control: A Mobility Service may wish to transfer large
      amounts of data, placing a requirement for congestion control in
      the transport.  There is an interaction between this requirement
      and that of the requirement for low latency since ways to deal
      with timely delivery of smaller asynchronous messages around the
      larger datagrams is required (mitigation of head of line blocking



Hepworth, et al.         Expires August 29, 2006               [Page 11]

Internet-Draft               MIH Signalling                February 2006


      etc.).

   Secure delivery: The Mobility Service information must be delivered
      securely between trusted peers, where the transport may pass
      though untrusted intermediate nodes and networks.

   Multiplexing: The transport service needs to be able to support
      different mobility services.  This may require multiplexing and
      the ability to manage multiple discovery operations and peering
      relationships in parallel.

   Multihoming: For some information services exchanged with the MN,
      there is a possibility that the request and response messages can
      be carried over two different links e.g. a handover command
      request is on the current link while the response could be
      delivered on the new link.  Depending on the IP mobility
      mechanism, there is some impact on the transport option for the
      mobility information services.  This may potentially have some
      associated latency and security issues, for example, if the
      transport is over IP there is some transparency but Mobile IP may
      introduce additional delay and both TCP and UDP must use the
      permanent address of the MN.

   In addition to the above, it may be necessary for the transport to
   support multiple applications (or modes of operation) to support the
   particular requirements of the Information Exchange being carried out
   between nodes.  This may require the ability to multiplex multiple
   information exchanges into a single transport exchange.

   Further information about transport requirements related to specific
   Mobility Services can be found in [1] and [2].


5.  Security Considerations

   Network supported mobility services aim at improving decision making
   and management of dynamically connected hosts.  The control and
   maintenance of mobile nodes becomes challenging where authentication
   and authorization credentials used to access a network are
   unavailable for the purpose of bootstrapping a security association
   for handover services.

   Information Services may not require authorization of the client, but
   both event and command services must authenticate message sources,
   particularly if they are mobile.  Network side service entities will
   typically need to provide proof of authority to serve visiting
   devices.  Where signalling or radio operations can result from
   received messages, significant disruption may result from processing



Hepworth, et al.         Expires August 29, 2006               [Page 12]

Internet-Draft               MIH Signalling                February 2006


   bogus or modified messages.  The effect of processing bogus messages
   depends largely upon the content of the message payload, which is
   handled by the handover services application.  Regardless of the
   variation in effect, message delivery mechanisms need to provide
   protection against tampering, and spoofing.

   Sensitive and identifying information about a mobile device may be
   exchanged during handover service message exchange.  Since handover
   decisions are to be made based upon message exchanges, it may be
   possible to trace a user's movement between cells, or predict future
   movements, by inspecting handover service messages.  In order to
   prevent such tracking, message confidentiality should be available.
   This is particularly important since many mobile devices are
   associated with only one user, as divulgence of such information may
   violate the user's privacy.  Additionally, identifying information
   may be exchanged during security association construction.  As this
   information may be used to trace users across cell boundaries,
   identity protection should be available if possible, when
   establishing SAs.

   In addition, the user should not have to disclose its identity to the
   network (any more than it needed to during authentication) in order
   to access the Mobility Support Services.  For example, if the local
   network is just aware that an anonymous user with a subscription to
   operatorXYX.com is accessing the network, the user should not have to
   divulge their true identity in order to access the Mobility Support
   Services available locally.

   Finally, the network nodes themselves will potentially be subject to
   denial of service attacks from MNs and these problems will be
   exacerbated if operation of the mobility service protocols imposes a
   heavy computational load on the NNs.  The overall design has to
   consider at what stage (e.g. discovery, transport layer
   establishment, service specific protocol exchange) denial of service
   prevention or mitigation should be built in.


6.  Conclusions and Open Issues

   This Internet draft outlined a broad problem statement for the
   signalling of information elements across a network to support media
   independent handover services.  In order to enable this type of
   signalling service, a need for a generic transport solution with
   certain transport and security properties was outlined.  Whilst the
   motivation for considering this problem has come form work within
   IEEE 802.21, a desirable goal is to ensure that solutions to this
   problem are applicable to a wider range of mobility services.




Hepworth, et al.         Expires August 29, 2006               [Page 13]

Internet-Draft               MIH Signalling                February 2006


   One important open issue is the question of how much Mobility Service
   specific functionality (with respect to the structure shown in [])
   should be seen as part of the common problem within IETF scope.  One
   option is that the problem scope is limited strictly to message
   transport requirements, the other extreme is that the full mobility
   service protocols should be defined.  An intermediate stage would be
   to consider message sequences and use cases for different mobility
   services but leave the details of Information Elements by other
   bodies, but potentially including IETF working groups.

   It would be valuable to establish realistic performance goals for the
   solution to this common problem (i.e. transport and security aspects)
   using experience from previous IETF work in this area and knowledge
   about feasible deployment scenarios.  This information could then be
   used as an input to other standards bodies in assisting them to
   design mobility services with feasible performance requirements.

   Much of the functionality required for this problem is available from
   existing IETF protocols or combination thereof.  This document takes
   no position on whether an existing protocol can be adapted for the
   solution or whether new protocol development is required.  In either
   case, we believe that the appropriate skills for development of
   protocols in this area lies in the IETF.

7.  References

   [1]  Faccin, S., "Some Requirements for a Handover Information
        Service", draft-faccin-mih-infoserv-01 (work in progress),
        October 2005.

   [2]  Sreemanthula, S., "A Problem Statement for Event Services and
        Command Services for Media Independent Handovers",
        draft-sreemanthula-es-cs-problem-statement-00 (work in
        progress), October 2005.

   [3]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
        "Diameter Base Protocol", RFC 3588, September 2003.


Appendix A.  Acknowledgements

   Thanks to Robert Hancock, Andrew McDonald and Jari Arkko for their
   inputs.


Appendix B.  Relationship to IEEE 802.21

   The following Appendix provides some further information on the



Hepworth, et al.         Expires August 29, 2006               [Page 14]

Internet-Draft               MIH Signalling                February 2006


   relationship of this problem statement to the work being carried out
   by IEEE 802.21.

   IEEE 802.21 has identified three Mobility Support Services to enable
   better inter-technology handover decisions.  These are:

   1.  the Event Service (ES) which provides indications from lower
       layers about changes in the connectivity state.  This is
       particularly relevant to wireless interfaces.

   2.  the Command Service (CS) which provides a mechanism for
       controlling handovers.  This includes the establishment,
       redirection, or removal of state in either the network or the
       mobile terminal, so that handovers occur smoothly.

   3.  the Information Service (IS) which provides additional handover-
       related information.  This allows the network or host to make
       informed decisions of which handover operations to undertake
       either in response to an event, or when planning controlled or
       commanded handovers.

   Something about formats?





























Hepworth, et al.         Expires August 29, 2006               [Page 15]

Internet-Draft               MIH Signalling                February 2006


Authors' Addresses

   Eleanor Hepworth
   Siemens Roke Manor Research
   Roke Manor
   Romsey,   SO51 5RE
   UK

   Email: eleanor.hepworth@roke.co.uk


   Greg Daley
   Panasonic Digital Networking Laboratory
   2 Research Way
   Princeton, New Jersey  08540
   USA

   Phone: +1 609 734 7334
   Email: greg.daley@research.panasonic.com


   Srivinas Sreemanthula
   Nokia Research Center
   6000 Connection Dr.
   Irving,   TX 75028
   USA

   Email: srinivas.sreemanthula@nokia.com


   Stefano Faccin
   Nokia Research Center
   6000 Connection Dr.
   Irving,   TX 75229
   USA

   Email: stefano.faccin@nokia.com


   Vivek Gupta
   Intel Corporation
   Vivek's Address
   Vivek's Address  00
   USA

   Phone: +1 000 000 0000
   Email: vivek.g.gupta@intel.com




Hepworth, et al.         Expires August 29, 2006               [Page 16]

Internet-Draft               MIH Signalling                February 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Hepworth, et al.         Expires August 29, 2006               [Page 17]