GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4831

Network Working Group J. Kempf, Ed. Request for Comments: 4831 DoCoMo USA Labs Category: Informational April 2007

  Goals for Network-Based Localized Mobility Management (NETLMM)

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The IETF Trust (2007).

Abstract

 In this document, design goals for a network-based localized mobility
 management (NETLMM) protocol are discussed.

Table of Contents

 1. Introduction ....................................................2
    1.1. Terminology ................................................2
 2. NETLMM Functional Architecture ..................................3
 3. Goals for the NETLMM Protocol ...................................3
    3.1. Goal 1: Handover Performance Improvement ...................4
    3.2. Goal 2: Reduction in Handover-Related Signaling Volume .....5
    3.3. Goal 3: Location Privacy ...................................6
    3.4. Goal 4: Limit Overhead in the Network ......................7
    3.5. Goal 5: Simplify Mobile Node Mobility Management
         Security by Deriving from IP Network Access and/or IP
         Movement Detection Security ................................7
    3.6. Goal 6: Link Technology Agnostic ...........................8
    3.7. Goal 7: Support for Unmodified Mobile Nodes ................8
    3.8. Goal 8: Support for IPv4 and IPv6 ..........................9
    3.9. Goal 9: Reuse of Existing Protocols Where Sensible ........10
    3.10. Goal 10: Localized Mobility Management
          Independent of Global Mobility Management ................10
    3.11. Goal 11: Configurable Data Plane Forwarding
          between Local Mobility Anchor and Mobile Access Gateway ..11
 4. Security Considerations ........................................11
 5. Acknowledgements ...............................................11
 6. Normative References ...........................................12
 7. Informative References .........................................12
 8. Contributors ...................................................13

Kempf Informational [Page 1] RFC 4831 NETLMM Goals April 2007

1. Introduction

 In [1], the basic problems that occur when a global mobility protocol
 is used for managing local mobility are described, and two currently
 used approaches to localized mobility management -- the host-based
 approach that is used by most IETF protocols, and the proprietary
 Wireless LAN (WLAN) switch approach used between WLAN switches in
 different subnets -- are examined.  The conclusion from the problem
 statement document is that none of the approaches has a complete
 solution to the problem.  While the WLAN switch approach is most
 convenient for network operators and users because it requires no
 software on the mobile node other than the standard drivers for WiFi,
 the proprietary nature limits interoperability, and the restriction
 to a single last-hop link type and wired backhaul link type restricts
 scalability.  The IETF host-based protocols require host software
 stack changes that may not be compatible with all global mobility
 protocols.  They also require specialized and complex security
 transactions with the network that may limit deployability.  The
 conclusion is that a localized mobility management protocol that is
 network based and requires no software on the host for localized
 mobility management is desirable.
 This document develops a brief functional architecture and detailed
 goals for a network-based localized mobility management protocol
 (NETLMM).  Section 2 describes the functional architecture of NETLMM.
 In Section 3, a list of goals that is desirable in the NETLMM
 protocol is presented.  Section 4 briefly outlines Security
 Considerations.  More discussion of security can be found in the
 threat analysis document [2].

1.1. Terminology

 Mobility terminology in this document follows that in RFC 3753 [10]
 and in [1].  In addition, the following terms are related to the
 functional architecture described in Section 2:
 Localized Mobility Management Domain
    An Access Network in the sense defined in [1] in which mobility is
    handled by the NETLMM protocol.
 Mobile Access Gateway
    A Mobile Access Gateway (MAG) is a functional network element that
    terminates a specific edge link and tracks mobile node IP-level
    mobility between edge links, through NETLMM signaling with the
    Localized Mobility Anchor.  The MAG also terminates host routed
    data traffic from the Localized Mobility Anchor for mobile nodes

Kempf Informational [Page 2] RFC 4831 NETLMM Goals April 2007

    currently located within the edge link under the MAG's control,
    and forwards data traffic from mobile nodes on the edge link under
    its control to the Localized Mobility Anchor.
 Local Mobility Anchor
    A Local Mobility Anchor (LMA) is a router that maintains a
    collection of host routes and associated forwarding information
    for mobile nodes within a localized mobility management domain
    under its control.  Together with the MAGs associated with it, the
    LMA uses the NETLMM protocol to manage IP node mobility within the
    localized mobility management domain.  Routing of mobile node data
    traffic is anchored at the LMA as the mobile node moves around
    within the localized mobility management domain.

2. NETLMM Functional Architecture

 The NETLMM architecture consists of the following components.
 Localized Mobility Anchors (LMAs) within the backbone network
 maintain a collection of routes for individual mobile nodes within
 the localized mobility management domain.  The routes point to the
 Mobile Access Gateways (MAGs) managing the links on which the mobile
 nodes currently are located.  Packets for a mobile node are routed to
 and from the mobile node through tunnels between the LMA and MAG.
 When a mobile node moves from one link to another, the MAG sends a
 route update to the LMA.  While some mobile node involvement is
 necessary and expected for generic mobility functions such as
 movement detection and to inform the MAG about mobile node movement,
 no specific mobile-node-to-network protocol will be required for
 localized mobility management itself.  Host stack involvement in
 mobility management is thereby limited to generic mobility functions
 at the IP layer, and no specialized localized mobility management
 software is required.

3. Goals for the NETLMM Protocol

 Section 2 of [1] describes three problems with using a global
 mobility management protocol for localized mobility management.  Any
 localized mobility management protocol must naturally address these
 three problems.  In addition, the side effects of introducing such a
 solution into the network need to be limited.  In this section, we
 address goals for NETLMM, including both solving the basic problems
 (Goals 1, 2, and 3) and limiting the side effects (Goals 4+).

Kempf Informational [Page 3] RFC 4831 NETLMM Goals April 2007

 Some basic goals of all IETF protocols are not discussed in detail
 here, but any solution is expected to satisfy them.  These goals are
 fault tolerance, robustness, interoperability, scalability, and
 minimal specialized network equipment.  A good discussion of their
 applicability to IETF protocols can be found in [4].
 Out of scope for the initial goals discussion are Quality of Service
 (QoS) and dormant mode/paging.  While these are important functions
 for mobile nodes, they are not part of the base localized mobility
 management problem.  In addition, mobility between localized mobility
 management domains is not covered here.  It is assumed that this is
 covered by the global mobility management protocols.

3.1. Goal 1: Handover Performance Improvement

 Handover packet loss occurs because there is usually latency between
 when the link handover starts and when the IP subnet configuration
 and global mobility management signaling completes.  During this
 time, the mobile node is unreachable at its former topological
 location on the old link where correspondents are sending packets.
 Such misrouted packets are dropped.  This aspect of handover
 performance optimization has been the subject of much work, both in
 other Standards Development Organizations (SDOs) and in the IETF, in
 order to reduce the latency in IP handover.  Many solutions to this
 problem have been proposed at the link layer and at the IP layer.
 One aspect of this goal for localized mobility management is that the
 processing delay for changing the forwarding after handover must
 approach as closely as possible the sum of the delay associated with
 link-layer handover and the delay required for active IP-layer
 movement detection, in order to avoid excessive packet loss.
 Ideally, if network-side link-layer support is available for handling
 movement detection prior to link handover or as part of the link
 handover process, the routing update should complete within the time
 required for link handover.  This delay is difficult to quantify, but
 for voice traffic, the entire handover delay, including Layer 2
 handover time and IP handover time should be between 40-70 ms to
 avoid any degradation in call quality.  Of course, if the link-layer
 handover latency is too high, sufficient IP-layer handover
 performance for good real-time service cannot be matched.
 A goal of the NETLMM protocol -- in networks where the link-layer
 handover latency allows it -- is to reduce the amount of latency in
 IP handover, so that the combined IP-layer and link-layer handover
 latency is less than 70 ms.

Kempf Informational [Page 4] RFC 4831 NETLMM Goals April 2007

3.2. Goal 2: Reduction in Handover-Related Signaling Volume

 Considering Mobile IPv6 [9] as the global mobility protocol (other
 mobility protocols require about the same or somewhat less), if a
 mobile node using address autoconfiguration is required to
 reconfigure on every move between links, the following signaling must
 be performed:
 1) Link-layer signaling required for handover and reauthentication.
    For example, in 802.11 [7], this is the Reassociate message
    together with 802.1x [8] reauthentication using EAP.
 2) Active IP-level movement detection, including router reachability.
    The Detecting Network Attachment (DNA) protocol [5] uses Router
    Solicitation/Router Advertisement for this purpose.  In addition,
    if SEcure Neighbor Discovery (SEND) [3] is used and the mobile
    node does not have a certificate cached for the router, the mobile
    node must use Certification Path Solicitation/Certification Path
    Advertisement to obtain a certification path.
 3) Two Multicast Listener Discovery (MLD) [14] REPORT messages, one
    for each of the solicited node multicast addresses corresponding
    to the link local address and the global address.
 4) Two Neighbor Solicitation (NS) messages for duplicate address
    detection, one for the link local address and one for the global
    address.  If the addresses are unique, no response will be
    forthcoming.
 5) Two NS messages from the router for address resolution of the link
    local and global addresses, and two Neighbor Advertisement
    messages in response from the mobile node.
 6) Binding Update/Binding Acknowledgement between the mobile node and
    home agent to update the care of address binding.
 7) Return routability signaling between the correspondent node and
    mobile node to establish the binding key, consisting of one Home
    Test Init/Home Test and Care of Test Init/Care of Test.
 8) Binding Update/Binding Acknowledgement between the correspondent
    node and mobile node for route optimization.
 Note that Steps 1-2 may be necessary, even for intra-link mobility,
 if the last-hop link protocol doesn't provide much help for IP
 handover.  Steps 3-5 will be different if stateful address
 configuration is used, since additional messages are required to
 obtain the address.  Steps 6-8 are only necessary when Mobile IPv6 is

Kempf Informational [Page 5] RFC 4831 NETLMM Goals April 2007

 used.  The result is approximately 18 messages at the IP level, where
 the exact number depends on various specific factors, such as whether
 or not the mobile node has a router certificate cached before a
 mobile node can be ensured that it is established on a link and has
 full IP connectivity.  In addition to handover related signaling, if
 the mobile node performs Mobile IPv6 route optimization, it may be
 required to renew its return routability key periodically (on the
 order of every 7 minutes), even if it is not moving, resulting in
 additional signaling.
 The signaling required has a large impact on the performance of
 handover, impacting Goal 1.  Perhaps more importantly, the aggregate
 impact from many mobile nodes of such signaling on expensive shared
 links (such as wireless where the capacity of the link cannot easily
 be expanded) can result in reduced last-hop link capacity for data
 traffic.  Additionally, in links where the end user is charged for IP
 traffic, IP signaling is not without cost.
 To address the issue of signaling impact described above, the goal is
 that handover signaling volume from the mobile node to the network
 should be no more than what is needed for the mobile node to perform
 secure IP-level movement detection, in cases where no link-layer
 support exists.  Furthermore, NETLMM should not introduce any
 additional signaling during handover beyond what is required for IP-
 level movement detection.  If link-layer support exists for IP-level
 movement detection, the mobile node may not need to perform any
 additional IP-level signaling after link-layer handover.

3.3. Goal 3: Location Privacy

 In any IP network, there is a threat that an attacker can determine
 the physical location of a network node from the node's topological
 location.  Depending on how an operator deploys their network, an
 operator may choose to assign subnet coverage in a way that is
 tightly bound to geography at some timescale, or it may choose to
 assign it in ways in which the threat of someone finding a node
 physically based on its IP address is smaller.  Allowing the L2
 attachment and L3 address to be less tightly bound is one tool for
 reducing this threat to location privacy.
 Mobility introduces an additional threat.  An attacker can track a
 mobile node's geographical location in real-time, if the victim
 mobile node must change its IP address as it moves from one subnet to
 another through the covered geographical area.  If the granularity of
 the mapping between the IP subnets and geographical area is small for
 the particular link type in use, the attacker can potentially
 assemble enough information to find the victim in real time.

Kempf Informational [Page 6] RFC 4831 NETLMM Goals April 2007

 In order to reduce the risk from location privacy compromises as a
 result of IP address changes, the goal for NETLMM is to remove the
 need to change IP address as a mobile node moves across links in an
 access network.  Keeping the IP address fixed over a large
 geographical region fuzzes out the resolution of the mapping between
 the IP subnets and geographical area, regardless of how small the
 natural deployment granularity may be.  This reduces the chance that
 the attacker can deduce the precise geographic location of the mobile
 node.

3.4. Goal 4: Limit Overhead in the Network

 Access networks, including both the wired and wireless parts, tend to
 have somewhat stronger bandwidth and router processing constraints
 than the backbone.  In the wired part of the network, these
 constraints are a function of the cost of laying fiber or wiring to
 the wireless access points in a widely dispersed geographic area.  In
 the wireless part of the network, these constraints are due to the
 limitation on the number of bits per Hertz imposed by the physical
 layer protocol.  Therefore, any solutions for localized mobility
 management should minimize overhead within the access network.

3.5. Goal 5: Simplify Mobile Node Mobility Management Security by

    Deriving from IP Network Access and/or IP Movement Detection
    Security
 Localized mobility management protocols that have host involvement
 may require an additional security association between the mobile
 node and the mobility anchor, and establishing this security
 association may require additional signaling between the mobile node
 and the mobility anchor (see [13] for an example).  The additional
 security association requires extra signaling and therefore extra
 time to negotiate.  Reducing the complexity of mobile-node-to-network
 security for localized mobility management can therefore reduce
 barriers to deployment and improve responsiveness.  Naturally, such
 simplification must not come at the expense of maintaining strong
 security guarantees for both the network and mobile node.
 In NETLMM, the network (specifically, the MAG) derives the occurrence
 of a mobility event, requiring a routing update for a mobile node
 from link-layer handover signaling, or IP-layer movement detection
 signaling from the mobile node.  This information is used to update
 routing for the mobile node at the LMA.  The handover, or movement
 detection signaling, must provide the network with proper
 authentication and authorization so that the network can definitively
 identify the mobile node and determine its authorization.  The
 authorization may be at the IP level -- for example, using something
 like SEND [3] to secure IP movement detection signaling -- or it at

Kempf Informational [Page 7] RFC 4831 NETLMM Goals April 2007

 the link level.  Proper authentication and authorization must be
 implemented on link-layer handover signaling and/or IP-level movement
 detection signaling in order for the MAG to securely deduce mobile
 node movement events.  Security threats to the NETLMM protocol are
 discussed in [2].
 The goal is that security for NETLMM mobile node mobility management
 should derive from IP network access and/or IP movement detection
 security, such as SEND or network access authentication, and not
 require any additional security associations or additional signaling
 between the mobile node and the network.

3.6. Goal 6: Link Technology Agnostic

 The number of wireless link technologies available is growing, and
 the growth seems unlikely to slow down.  Since the standardization of
 a wireless link physical and medium access control layers is a time-
 consuming process, reducing the amount of work necessary to interface
 a particular wireless link technology to an IP network is necessary.
 When the last-hop link is a wireless link, a localized mobility
 management solution should ideally require minimal work to interface
 with a new wireless link technology.
 In addition, an edge mobility solution should provide support for
 multiple wireless link technologies.  It is not required that the
 localized mobility management solution support handover from one
 wireless link technology to another without a change in the IP
 address, but this possibility should not be precluded.
 The goal is that the localized mobility management protocol should
 not use any wireless link specific information for basic routing
 management, though it may be used for other purposes, such as
 securely identifying a mobile node.

3.7. Goal 7: Support for Unmodified Mobile Nodes

 In the WLAN switching market, no modification of the software on the
 mobile node is required to achieve localized mobility management.
 Being able to accommodate unmodified mobile nodes enables a service
 provider to offer service to as many customers as possible, the only
 constraint being that the customer is authorized for network access.
 Another advantage of minimizing mobile node software for localized
 mobility management is that multiple global mobility management
 protocols can be supported.  There are a variety of global mobility
 management protocols that might also need support, including
 proprietary or link technology-specific protocols needing support for
 backward compatibility reasons.  Within the Internet, both Host

Kempf Informational [Page 8] RFC 4831 NETLMM Goals April 2007

 Identity Protocol (HIP) [11] and IKEv2 Mobility and Multihoming
 (MOBIKE) [6] are likely to need support in addition to Mobile IPv6
 [9], and Mobile IPv4 [12] support may also be necessary.
 Note that this goal does NOT mean that the mobile node has no
 software at all associated with mobility.  The mobile node must have
 some kind of global mobility protocol if it is to move from one
 domain of edge mobility support to another and maintain session
 continuity, although no global mobility protocol is required if the
 mobile node only moves within the coverage area of the localized
 mobility management protocol or no session continuity is required
 during global movement.  Also, if the last-hop link is a wireless
 link, every wireless link protocol requires handover support on the
 mobile node in the physical and medium access control layers,
 typically in the wireless interface driver.  Information passed from
 the medium access control layer to the IP layer on the mobile node
 may be necessary to trigger IP signaling for IP handover.  Such
 movement detection support at the IP level may be required in order
 to determine whether the mobile node's default router is still
 reachable after the move to a new access point has occurred at the
 medium access control layer.  Whether or not such support is required
 depends on whether the medium access control layer can completely
 hide link movement from the IP layer.  For cellular type wireless
 link protocols, the mobile node and network undergo an extensive
 negotiation at the medium access control layer prior to handover, so
 it may be possible to trigger a routing update without any IP
 protocol involvement.  However, for a wireless link protocol such as
 IEEE 802.11 [7] in which the decision for handover is entirely in the
 hands of the mobile node, IP-layer movement detection signaling from
 the mobile node may be required to trigger a routing update.
 The goal is that the localized mobility management solution should be
 able to support any mobile node that joins the link and that has an
 interface that can communicate with the network, without requiring
 localized mobility management software on the mobile node.

3.8. Goal 8: Support for IPv4 and IPv6

 While most of this document is written with IPv6 in mind, localized
 mobility management is a problem in IPv4 networks as well.  A
 solution for localized mobility that works for both versions of IP is
 desirable, though the actual protocol may be slightly different due
 to the technical details of how each IP version works.  From Goal 7
 (Section 3.7), minimizing mobile node support for localized mobility
 means that ideally no IP version-specific changes should be required
 on the mobile node for localized mobility, and that global mobility
 protocols for both IPv4 and IPv6 should be supported.  Any IP
 version-specific features should be confined to the network protocol.

Kempf Informational [Page 9] RFC 4831 NETLMM Goals April 2007

3.9. Goal 9: Reuse of Existing Protocols Where Sensible

 Many existing protocols are available as Internet Standards upon
 which the NETLMM protocol can be built.  The design of the protocol
 should have a goal to reuse existing protocols where it makes
 architectural and engineering sense to do so.  However, the design
 should not attempt to reuse existing protocols where there is no real
 architectural or engineering reason.  For example, the suite of
 Internet Standards contains several good candidate protocols for the
 transport layer, so there is no real need to develop a new transport
 protocol specifically for NETLMM.  Reuse is clearly a good
 engineering decision in this case, since backward compatibility with
 existing protocol stacks is important.  On the other hand, the
 network-based, localized mobility management functionality being
 introduced by NETLMM is a new piece of functionality, and therefore
 any decision about whether to reuse an existing global mobility
 management protocol should carefully consider whether reusing such a
 protocol really meets the needs of the functional architecture for
 network-based localized mobility management.  The case for reuse is
 not so clear in this case, since there is no compelling backward
 compatibility argument.

3.10. Goal 10: Localized Mobility Management Independent of Global

     Mobility Management
 Localized mobility management should be implementable and deployable
 independently of any global mobility management protocol.  This
 enables the choice of local and global mobility management to be made
 independently of particular protocols that are implemented and
 deployed to solve the two different sorts of mobility management
 problems.  The operator can choose a particular localized mobility
 management protocol according to the specific features of their
 access network.  It can subsequently upgrade the localized mobility
 management protocol on its own, without even informing the mobile
 nodes.  Similarly, the mobile nodes can use a global mobility
 management protocol that best suits their requirements, or not use
 one at all.  Also, a mobile node can move into a new access network
 without having to check that it understands the localized mobility
 management protocol being used there.
 The goal is that the implementation and deployment of the localized
 mobility management protocol should not restrict, or be restricted
 by, the choice of global mobility management protocol.

Kempf Informational [Page 10] RFC 4831 NETLMM Goals April 2007

3.11. Goal 11: Configurable Data Plane Forwarding between Local

     Mobility Anchor and Mobile Access Gateway
 Different network operators may require different types of forwarding
 options between the LMA and the MAGs for mobile node data plane
 traffic.  An obvious forwarding option that has been used in past
 IETF localized mobility management protocols is IP-IP encapsulation
 for bidirectional tunneling.  The tunnel endpoints are the LMA and
 the MAGs.  But other options are possible.  Some network deployments
 may prefer routing-based solutions.  Others may require security
 tunnels using IPsec Encapsulating Security Payload (ESP)
 encapsulation if part of the localized mobility management domain
 runs over a public access network and the network operator wants to
 protect the traffic.
 A goal of the NETLMM protocol is to allow the forwarding between the
 LMA and MAGs to be configurable depending on the particulars of the
 network deployment.  Configurability is not expected to be dynamic,
 as in controlled by the arrival of a mobile node; but rather,
 configuration is expected to be similar in timescale to configuration
 for routing.  The NETLMM protocol may designate a default forwarding
 mechanism.  It is also possible that additional work may be required
 to specify the interaction between a particular forwarding mechanism
 and the NETLMM protocol, but this work is not in scope of the NETLMM
 base protocol.

4. Security Considerations

 There are two kinds of security issues involved in network-based
 localized mobility management: security between the mobile node and
 the network, and security between network elements that participate
 in the NETLMM protocol.  The security-related goals in this document,
 described in Section 3.3 and 3.5, focus on the former, because those
 are unique to network-based mobility management. The threat analysis
 document [2] contains a more detailed discussion of both kinds of
 threats, which the protocol design must address.

5. Acknowledgements

 The authors would like to acknowledge the following people for
 particularly diligent reviewing: Vijay Devarapalli, Peter McCann,
 Gabriel Montenegro, Vidya Narayanan, Pekka Savola, and Fred Templin.

Kempf Informational [Page 11] RFC 4831 NETLMM Goals April 2007

6. Normative References

 [1]  Kempf, J., Ed., "Problem Statement for Network-Based Localized
      Mobility Management (NETLMM)", RFC 4830, April 2007.
 [2]  Vogt, C., and Kempf, J., "Security Threats to Network-Based
      Localized Mobility Management (NETLMM)", RFC 4832, April 2007.

7. Informative References

 [3]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
      Neighbor Discovery (SEND)", RFC 3971, March 2005.
 [4]  Carpenter, B., "Architectural Principles of the Internet", RFC
      1958, June 1996.
 [5]  Choi, JH. and G. Daley, "Goals of Detecting Network Attachment
      in IPv6", RFC 4135, August 2005.
 [6]  Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)",
      RFC 4555, June 2006.
 [7]  IEEE, "Wireless LAN Medium Access Control (MAC)and Physical
      Layer (PHY) specifications", IEEE Std. 802.11, 1999.
 [8]  IEEE, "Port-based Access Control", IEEE LAN/MAN Standard 802.1x,
      June, 2001.
 [9]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
      IPv6", RFC 3775, June 2004.
 [10] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
      3753, June 2004.
 [11] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP)
      Architecture", RFC 4423, May 2006.
 [12] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August
      2002.
 [13] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier,
      "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC
      4140, August 2005.
 [14] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
      (MLDv2) for IPv6", RFC 3810, June 2004.

Kempf Informational [Page 12] RFC 4831 NETLMM Goals April 2007

8. Contributors

 Kent Leung
 Cisco Systems, Inc.
 170 West Tasman Drive
 San Jose, CA 95134
 USA
 EMail: kleung@cisco.com
 Phil Roberts
 Motorola Labs
 Schaumberg, IL
 USA
 EMail: phil.roberts@motorola.com
 Katsutoshi Nishida
 NTT DoCoMo Inc.
 3-5 Hikarino-oka, Yokosuka-shi
 Kanagawa,
 Japan
 Phone: +81 46 840 3545
 EMail: nishidak@nttdocomo.co.jp
 Gerardo Giaretta
 Telecom Italia Lab
 via G. Reiss Romoli, 274
 10148 Torino
 Italy
 Phone: +39 011 2286904
 EMail: gerardo.giaretta@tilab.com
 Marco Liebsch
 NEC Network Laboratories
 Kurfuersten-Anlage 36
 69115 Heidelberg
 Germany
 Phone: +49 6221-90511-46
 EMail: marco.liebsch@ccrle.nec.de

Editor's Address

 James Kempf
 DoCoMo USA Labs
 181 Metro Drive, Suite 300
 San Jose, CA 95110
 USA
 Phone: +1 408 451 4711
 EMail: kempf@docomolabs-usa.com

Kempf Informational [Page 13] RFC 4831 NETLMM Goals April 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
 ietf-ipr@ietf.org.

Acknowledgement

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

Kempf Informational [Page 14]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4831.txt · Last modified: 2007/04/10 21:00 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki