NETLMM G. Giaretta
Internet-Draft Telecom Italia
Expires: December 21, 2006 K. Leung
Cisco
M. Liebsch
NEC
P. Roberts
Motorola
K. Nishida
NTT DoCoMo Inc.
H. Yokota
KDDI Labs
M. Parthasarathy
Nokia
H. Levkowetz
Ericsson
June 19, 2006
NetLMM Protocol
draft-giaretta-netlmm-dt-protocol-00.txt
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 December 21, 2006.
Copyright Notice
Giaretta, et al. Expires December 21, 2006 [Page 1]
Internet-Draft NetLMM Protocol June 2006
Copyright (C) The Internet Society (2006).
Abstract
This document specifies a network protocol that allows mobile nodes
to move around in a localized mobility domain, changing their point
of attachment within the domain, but without ever being aware at the
IP layer that their point of attachment has ever changed, and
maintaining seamless communication in the presence of such mobility
events. It defines two protocol entities, a Mobile Access Gateway
and a Local Mobility Anchor, and a set of messages between them, that
together make these mobility events transparent to the mobile nodes
at the IP layer.
Giaretta, et al. Expires December 21, 2006 [Page 2]
Internet-Draft NetLMM Protocol June 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Functional Entities . . . . . . . . . . . . . . . . . . . . . 7
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
5. Message Types . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. LMA Allocation Request / Reply messages . . . . . . . . 10
5.2. Association Request / Reply messages . . . . . . . . . . 10
5.3. Disassociation Request / Reply messages . . . . . . . . 11
5.4. Location Registration / Ack messages . . . . . . . . . . 11
5.5. Location Deregistration / Ack messages . . . . . . . . . 11
5.6. MN Address Setup / Ack messages . . . . . . . . . . . . 12
5.7. MN Address Remove / Ack messages . . . . . . . . . . . . 12
5.8. Routing Setup / Ack messages . . . . . . . . . . . . . . 12
5.9. Routing Remove / Ack messages . . . . . . . . . . . . . 13
5.10. Heartbeat / Ack messages . . . . . . . . . . . . . . . . 13
5.11. Message Transport . . . . . . . . . . . . . . . . . . . 13
5.12. Message Optimization . . . . . . . . . . . . . . . . . . 14
6. Protocol Extensibility . . . . . . . . . . . . . . . . . . . . 14
7. Message and Message Option Formats . . . . . . . . . . . . . . 15
7.1. Message Formats . . . . . . . . . . . . . . . . . . . . 15
7.2. Options . . . . . . . . . . . . . . . . . . . . . . . . 19
8. Protocol Specification . . . . . . . . . . . . . . . . . . . . 26
8.1. Mobile Access Gateway Operation . . . . . . . . . . . . 26
8.2. Local Mobility Anchor Operation . . . . . . . . . . . . 32
9. Data Transport . . . . . . . . . . . . . . . . . . . . . . . . 38
9.1. Forwarding of Unicast Data Packets . . . . . . . . . . . 38
9.2. Forwarding of Multicast Data Packets . . . . . . . . . . 40
9.3. Forwarding of Broadcast Data Packets . . . . . . . . . . 41
10. Protocol Constants and Configuration Variables . . . . . . . . 41
11. Security Considerations . . . . . . . . . . . . . . . . . . . 41
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 43
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
15.1. Normative References . . . . . . . . . . . . . . . . . . 43
15.2. Informative References . . . . . . . . . . . . . . . . . 44
Appendix A. TODO (Things that remain to be specified...) . . . . 44
Appendix B. Using GRE Tunnels with NetLMM . . . . . . . . . . . . 45
Appendix C. Using MPLS with NetLMM . . . . . . . . . . . . . . . 46
Appendix D. TTL Handling . . . . . . . . . . . . . . . . . . . . 46
Appendix E. MN-AR Interface considerations . . . . . . . . . . . 46
Appendix F. Out of scope . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
Intellectual Property and Copyright Statements . . . . . . . . . . 49
Giaretta, et al. Expires December 21, 2006 [Page 3]
Internet-Draft NetLMM Protocol June 2006
1. Introduction
This document specifies a protocol that allows nodes to move around
in an access network attaching to various points of the access
network while maintaining an IP layer configuration that does not
change as the mobile nodes points of attachment change.
This protocol is not intended to solve all the problems of network-
based IP mobility. Over the past decade many companies and forums
have provided many, many staff years of research, development, and
standardization to realize all IP mobile networks and no doubt many
more years of effort are ahead to deliver improvements to realize all
the envisioned usage of such technology. Such systems have added
technology for specific link layers, and carrying IP packets over
those link layers, support for AAA infrastructures, and mobile
security to name a few. Challenges still lie ahead in the form
perhaps of mobile QoS, power management and paging, and management of
changing network conditions in the face of various mobility events.
This protocol is developed in response to the problem statement for
network-based localized mobility [I-D.ietf-netlmm-nohost-ps] and this
protocol attempts to satisfy the goals in the NetLMM goals document
[I-D.ietf-netlmm-nohost-req]. It is intended basically to solve the
problem of packet forwarding to nodes that change their point of
attachment to the network without the use of any protocol support at
the IP layer on the mobile node to support that mobility.
This document defines operation of the protocol for use in an IPv6
infrastructure and in support of IPv6 nodes, but the authors envision
that with modifications the protocol could be productively used with
an IPv4 infrastructure or to support IPv4 nodes. The document refers
conscientiously to mobile nodes rather than mobile hosts because its
operation is not limited in any way to host only support.
This protocol is similar and different to various IP mobility
protocols the IETF has standardized in the past. It is similar in
that it continues the tradition of maintaining address continuity to
mobile nodes regardless of the fact that those nodes have changes
their points of attachment in the network. It differs in that it
does not require any operational changes in protocol operation
between the mobile node and the network at the IP layer, in that it
supports an infrastructure that embraces network controlled mobility
operation, and in that its operation is limited in scope rather than
globally applicable.
The differences between this protocol and previous mobility protocols
are complementary rather than contradictory. It is quite possible to
conceive of deployments in which mobile IP is used in a wide area to
Giaretta, et al. Expires December 21, 2006 [Page 4]
Internet-Draft NetLMM Protocol June 2006
provide mobility services across multiple interface types or separate
local mobility domains while NetLMM is used within a single type of
access network or a single local mobility domain to facilitate
mobility without involving the mobile.
2. Terminology
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. 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 [RFC2119].
Mobility terminology in this document follows that in [RFC3753], with
the added specification of some terms as they are used in this
particular document:
IP Link
A set of routers, mobile nodes, and wireless access points that
share link broadcast capability or its functional equivalent.
This definition covers one or multiple access points under one or
several access routers. In the past, such a set has been called a
subnet, but this term is not strictly correct for IPv6, since
multiple subnet prefixes can be assigned to an IP link in IPv6.
Access Network (revised)
An Access Network consists of following three components: wireless
or other access points, access routers, access network gateways
which form the boundary to other networks and may shield other
networks from the specialized routing protocols (if any) run in
the Access Network; and (optionally) other internal access network
routers which may also be needed in some cases to achieve a
specialized routing protocol.
Local Mobility (revised)
Local Mobility is mobility over a restricted area of the network
topology. Note that, although the area of network topology over
which the mobile node moves may be restricted, the actual
geographic area could be quite large, depending on the mapping
between the network topology and the wireless coverage area.
Localized Mobility Management
Localized Mobility Management is a generic term for protocols
dealing with IP mobility management confined within the access
network. Localized Mobility Management signaling is not routed
outside the access network, although a handover may trigger Global
Mobility Management signaling. Localized Mobility Management
Giaretta, et al. Expires December 21, 2006 [Page 5]
Internet-Draft NetLMM Protocol June 2006
protocols exploit the locality of movement by confining movement
related changes to the access network.
Localized Mobility Management Protocol
A protocol that supports localized mobility management.
Intra-Link Mobility
Intra-Link Mobility is mobility between wireless access points
within an IP Link. Typically, this kind of mobility only involves
Layer 2 mechanisms, so Intra-Link Mobility is often called Layer 2
mobility. No IP link configuration is required upon movement
since the link does not change, but some IP signaling may be
required for the mobile node to confirm whether or not the change
of wireless access point also resulted in a change of IP link. If
the IP link consists of a single access point/router combination,
then this type of mobility is typically absent.
Mobile Access Gateway (MAG)
A Mobile Access Gateway (MAG) is a router embedded in a device
that terminates a specific link layer technology to which mobile
nodes attach themselves. It terminates one end of the MAG of the
connection to one or more Local Mobility Anchors and participates
in the NetLMM protocol exchange.
Local Mobility Anchor (LMA)
A local mobility anchor (LMA) is a router that terminates
connections to multiple Mobile Access Gateways, services mobility
requests for mobile nodes moving within a NetLMM system, and
participates in the NetLMM protocol exchange.
NetLMM Domain
A NetLMM domain is a set of multiple MAGs and a set of one or more
LMAs interconnected within an access network that provides
mobility operations for attached mobile nodes through the
execution of the NetLMM protocol.
NetLMM Address
The invariant IP address on the MN inside the NetLMM domain. For
IPv6 it is assumed that this is an invariant routable IP address
with global scope.
NetLMM Network Prefix
The NetLMM Network Prefix (NNP) is the IPv6 link prefix of the
NetLMM address.
Giaretta, et al. Expires December 21, 2006 [Page 6]
Internet-Draft NetLMM Protocol June 2006
Routing Tag
An opaque identifier that is signaled between MAGs and LMAs and
that can be used to distinguish traffic inside packets when the
contents inside those packets cannot be inspected due to some
operations such as encryption or header compression. It could be
used, for example, in a GRE key field if GRE tunneling were being
used to distinguish internal packets destined for a mobile when
the internal packets headers have been compressed.
3. Functional Entities
The principal functional entities in a NetLMM infrastructure are the
Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA).
There are other entities that will make up a mobile access network
that are used to support various kinds of functionality (mobile
nodes, AAA, routing, DNS, etc.) whose basic functionality may be used
by the MAG and the LMA but whose operation is not changed in any way
for the proper operation of the NetLMM protocol.
Include a diagram. The diagram should show:
1. multiple MAGs
2. multiple LMAs
3. their interconnectivity
Should it show?
4. mobile nodes moving around the edge
5. the possibility of link layer access technologies beneath MAGs
The Mobile Access Gateway
The Mobile Access Gateway (MAG) is a router that a mobile node is
attached to as the first hop router in the NetLMM infrastructure.
The MAG is connected to the mobile node over some specific link
provided by a link layer but the NetLMM infrastructure is agnostic
about the link layer technology that is used. Each MAG has its
own identifier used in NetLMM protocol messaging between the MAG
and the LMA. The important interfaces between link layer specific
functions and the NetLMM function reside on the MAG. There are
multiple MAGs in a NetLMM infrastructure.
The Local Mobility Anchor
The local mobility anchor (LMA) is a router that maintains
reachability to a mobile node's address while the mobile node
moves around within the NetLMM infrastructure. It is responsible
to maintain forwarding information for the mobile nodes which
includes a set of mappings to associate mobile nodes by their
Giaretta, et al. Expires December 21, 2006 [Page 7]
Internet-Draft NetLMM Protocol June 2006
identifiers with their address information, associating the mobile
nodes with their serving MAGs and the relationship between the LMA
and the MAGs. There may be one or more LMAs in a NetLMM
infrastructure.
4. Protocol Overview
The protocol consists of two major phases, an initiation phase and an
operational phase. During the initiation phase the MAGs and an LMA
(or multiple LMAs) establish connectivity between them. Although
this document describes this phase of the protocol operation as an
initiation phase there is no restriction on the ability of adding new
MAGs or new LMAs to a NetLMM infrastructure while other nodes are
already in operation. During the operational phase the MAGs and LMAs
provide mobile connectivity service to mobiles nodes that are
attaching to the infrastructure, leaving the infrastructure, and
moving around within the infrastructure.
It is not assumed that a MAG is associated with only a single LMA.
If there exists multiple LMAs in a NetLMM Domain, each MAG would most
likely be associated with, and potentially communicate with all the
LMAs rather than only a single LMA.
The NetLMM infrastructure uses 6 messages to establish and maintain
associations between the MAGs and the LMAs: Association Request,
Associate Reply, Disassociation Request, Disassociate Reply,
Heartbeat, and Heartbeat Ack.
A MAG associates itself with an LMA by sending an Association Request
message that includes its MAG ID and the supported data forwarding
modes (such as IPv6-in-IPv6). In response the LMA creates an
association with the MAG and populates state information about the
association. The LMA responds, providing its LMA ID and an agreed
upon data forwarding mode to the MAG. The MAG can undo the
relationship with the LMA through sending a Disassociation Request,
to which the LMA responds with a Disassociate Reply. Heartbeat
messages are sent between the MAG and LMA to determine the current
status of the reachability of the other entity. All of these
messages may be sent optionally over an IPsec connection if
additional security is desired.
The NetLMM infrastructure uses 14 messages to manage the attachment,
departure, mobility, and other activities of mobile nodes within the
infrastructure: LMA Allocation Request, LMA Allocation Reply,
Location Registration and Acknowledge, Location Deregistration and
Acknowledgment, Routing Setup and Acknowledgement, Routing Removal
and Acknowledgement, MN Address Setup and Acknowledgement, MN Address
Giaretta, et al. Expires December 21, 2006 [Page 8]
Internet-Draft NetLMM Protocol June 2006
Removal and Acknowledgement.
When a mobile node is to receive service, a policy decision point
entity may send an LMA Allocation Request to the LMA creating state
for the mobile node. The LMA allocation request authorizes service
for a particular Mobile Node ID. This message may contain policy
information for the mobile node. The LMA acknowledge the request
with an LMA allocation reply. It is possible that an LMA is
configured to authorize service for any mobile node and in such a
situation the LMA Allocation Request and reply messages are not
necessary.
When a mobile node connects to the NetLMM infrastructure, it first
needs to configure an address. Whether it is using stateful or
stateless address configuration, the serving LMA needs to be involved
in the address allocation process. So when a mobile node connects,
the MAG sends a location registration message to the LMA containing
its own ID and the Mobile Node's ID. The LMA responds to the message
with a a Location Registration Ack message that includes the NetLMM
prefix that the MAG is to use in its router advertisement toward the
Mobile Node. The MAG in turn sends a router advertisement to the
attached mobile. Once address configuration is complete (through
either stateful or stateless address configuration) the MAG registers
the mobile node's address with the LMA by sending an MN Address Setup
message to the LMA including the MAG's ID, the MN's ID, the NetLMM
address, and a tunnel ID. The LMA creates forwarding state for
packets in response to this message and sends a MN address reply to
the MAG acknowledging the packet setup. The MAG, in receiving a
successful MN Address Setup Reply, creates forwarding state for
packets destined to the mobile node.
When a mobile node then leaves the NetLMM infrastructure, the MAG
sends a Location Deregistration message to the LMA including the
Mobile Node's ID and the MAG's ID. The LMA cleans up all state for
the mobile node identified in the message and sends a Location
Deregistration Acknowledgement message.
It is also possible for the LMA to remove a mobile node from the
network. This could be done for a number of policy specific reasons
in the network. The same two messages are used, Location
Deregistration and Local Deregistration Acknowledgement, but they are
initiated by the LMA and acknowledged by the MAG in this case. The
MAG disconnects the mobile and removes all mobile state in response
to this message.
When a mobile node moves from one MAG to another MAG, the new MAG
(nMAG) sends a Location Registration Message to the LMA with the MAG
ID and the MN ID. The LMA responds by sending a Routing Setup
Giaretta, et al. Expires December 21, 2006 [Page 9]
Internet-Draft NetLMM Protocol June 2006
message to the nMAG that includes the MN ID, the MAG ID, the LMA ID,
NetLMM addresses. The new MAG acknowledges this information with a
Routing Setup Ack message and the LMA responds with a Location
Registration Ack message containing the NetLMM prefix that the nMAG
uses in the router advertisement for the MN.
The mobile node can at any time configure new IP addresses for itself
using stateless address auto-configuration and this operation is
supported in NetLMM. When the mobile issues a new address DAD
request, the MAG sends a MN Address Setup Request to the LMA with the
mobile node's ID and the new NetLMM address. The LMA validates the
usability of the address, updates forwarding state, and acknowledges
the request with the MN Address Setup Reply message to the serving
MAG which then replies to the MN DAD operation. The means through
which the NetLMM infrastructure knows that the mobile node is
attached, leaving, or moving is beyond the scope of this protocol
specification. It is envisioned that this information is largely
access network specific and that the MAG uses an API to trigger much
of the operation described herein.
5. Message Types
This document defines a set of control messages and options for the
NetLMM protocol. The control messages are carried by the User
Datagram Protocol, using a well known port number, as described in
Section 5.11. The messages are presented in this section, and the
message format and option formats are defined later, in Section 7.
5.1. LMA Allocation Request / Reply messages
The LMA Allocation Request message is used to allocate an LMA for the
MN that is initially attached to the network and to validate the
Location Registration message coming later from the MAG to which the
MN is attached. This message containing the MN ID is sent to the
selected LMA and may come from various nodes such as the MAG to which
the MN is attached or the PDP that is involved in the authentication
of the MN. The LMA Allocation Request is optional and the LMA may be
allocated by other means (e.g., static allocation) and can be
configured to serve the MN without this message.
The LMA Allocation Reply message is sent from the LMA to the source
of the LMA Allocation Request message to notify the status of the
request (success or error code).
5.2. Association Request / Reply messages
The Association Request is used to set up the control and data plane
Giaretta, et al. Expires December 21, 2006 [Page 10]
Internet-Draft NetLMM Protocol June 2006
relationship between the MAG and LMA. This message is sent from the
MAG to the LMA in the MAGs initiation phase, before it enters the
operational phase and handles MN Location Registration and Routing
Setup. The message contains the sender's ID, its functional
capabilities and supported data forwarding modes. The data
forwarding mode specifies the tunnel method of the data plane (e.g.,
IP-in-IP). The tunnel between the MAG and LMA is bidirectional,
which is achieved by establishing two unidirectional tunnels in
opposite directions.
The Associate Reply message is sent from the LMA to the MAG to notify
the status of the request (success or error code). If the request is
successful, the receiver of the request also sends its capabilities
(e.g., the receiver's ID, agreed-upon data forwarding mode, etc.) on
this message.
5.3. Disassociation Request / Reply messages
The Disassociation Request message is sent from the MAG to the LMA or
vice versa to tear down the control and data plane relationship
between them. This message contains the MAG ID and LMA ID.
The Disassociate Reply message is sent from the LMN to the MAG or
vice versa to inform the status of the request (success or error
code).
5.4. Location Registration / Ack messages
The Location Registration message is sent from the MAG to the LMA
when the MAG detects the MN having accessed the network without an IP
address. By this message, the MAG and LMA create the mobility state
of the MN. The IP address of the MN is not known at this point and
the MN Address Setup message must follow to update the mobility state
and to set up the routing for the MN. This message contains the MN
ID, MAG ID and LMA ID.
The Location Registration Ack message is sent from the LMA to the MAG
to acknowledge the receipt of the Location Registration message. If
the registration is successful, the LMA sends the NetLMM prefix on
this message, which in turn is used for the Router Advertisement sent
by the MAG.
5.5. Location Deregistration / Ack messages
The Location Deregistration message is sent from the MAG to the LMA
or vice versa to delete the mobility state of the MN. The MAG sends
this message when the MN is detected to have moved away. On the
other hand, the LMA sends this message when it determines that the MN
Giaretta, et al. Expires December 21, 2006 [Page 11]
Internet-Draft NetLMM Protocol June 2006
is at a new location. This message contains the MN ID, MAG ID, LMA
ID and the requested revocation time.
The Location Deregistration Ack is sent back to the source of the
Location Deregistration message to acknowledge the receipt of the
Location Deregistration message. This message contains the agreed
revocation time.
5.6. MN Address Setup / Ack messages
When the MAG determines that the MN has obtained its NetLMM address
by for example the neighbor advertisement (the DAD procedure) or the
DHCP server, the MAG sends he MN Address Setup message to the LMA to
update the mobility state and to create a routing entry for the MN on
the LMA. This message contains the MAG ID, LMA ID and one or more MN
ID(s) and NetLMM address(es) assigned to the MN(s). Optionally, the
Routing Tag(s) for the MN(s) may be included.
The MN Address Setup Ack is sent from the LMA to the MAG to
acknowledge the receipt of the MN Address Setup message and to notify
the MAG if the NetLMM address(es) contained in the MN Address Setup
message are accepted (the DAD procedure). If the Routing Tag is
contained in the Routing Setup message, a corresponding Routing Tag
is returned by the Routing Setup Ack message.
5.7. MN Address Remove / Ack messages
When the MAG determines that one of the MN's NETLMM address(es) is no
longer valid or used, the MAG sends the MN Address Remove message to
the LMA to delete the corresponding mobility state and routing entry
in the LMA. This message contains the MN ID, MAG ID, LMA ID and
corresponding NETLMM address.
The MN Address Remove Ack is sent from the MAG to the LMA to
acknowledge the receipt of the MN Address Remove message.
5.8. Routing Setup / Ack messages
When the MN moves from the previous MAG to the new MAG (inter-MAG
handover), the LMA, which already has the mobility state for the MN,
sends the Routing Setup message to the new MAG in response to the
Location Registration message from the new MAG. This message is used
to update the routing on the new MAG and contains the MN ID, MAG ID,
LMA ID and one or more NetLMM address(es) assigned to the MN.
Optionally, the Routing Tag for the MN may be included.
The Routing Setup Ack message is sent from the MAG to the LMA to
acknowledge the receipt of the Routing Setup message. If the Routing
Giaretta, et al. Expires December 21, 2006 [Page 12]
Internet-Draft NetLMM Protocol June 2006
Tag is included in the Routing Setup message, the corresponding
Routing Tag is returned by the Routing Setup Ack message.
5.9. Routing Remove / Ack messages
When the LMA determines that one or more NetLMM address(es) is/are no
longer valid by for example the DHCP server, the LMA sends the
Routing Remove message to the MAG to delete the corresponding routing
entry/entries on the MAG. This message contains the MN ID, MAG ID,
LMA ID and NetLMM address(es) of the MN.
The Routing Remove Ack is sent from the MAG to the LMA to acknowledge
of the receipt of the Routing Remove message.
5.10. Heartbeat / Ack messages
The Heartbeat message is sent from the MAG to LMA or vice versa to
obtain the connectivity status. This message contains the MAG ID,
LMA ID and the heartbeat number that is separated from the message
sequence number.
The Heartbeat Ack is sent back from the node that received the
Heartbeat message to its peer. This message contains the MAG ID, LMA
ID and the corresponding heartbeat number.
These messages are suppressed when there is data traffic between the
two nodes.
5.11. Message Transport
The new NetLMM control messages defined in this document are carried
by the User Datagram Protocol RFC 768 [RFC0768] using well known port
number TBD (assigned by IANA).
The message sender SHOULD include a non-zero UDP Checksum. The
recipient of the message MUST process and check the UDP checksum. A
Zero checksum SHOULD be accepted by the recipient.
The sender and initiator of a message exchange MUST use the following
UDP ports:
* Source Port: variable
* Destination Port: TBD (Assigned by IANA)
In case the recipient of a NETLMM message has to reply, the following
UDP ports MUST be used:
Giaretta, et al. Expires December 21, 2006 [Page 13]
Internet-Draft NetLMM Protocol June 2006
* Source Port: variable
* Destination Port: Copied from the source port of the received
message.
5.12. Message Optimization
In order to minimize routing establishment delays, e.g., handover
times, it may be important to achieve routing setup or routing
changes with an absolute minimum number of messaging roundtrips
between the MAG and the LMA. However, given the messages described
earlier in this section, there are several cases where 2 messaging
round-trips are needed in order to complete a routing setup.
Future versions of this document will propose optimizations which
reduce the number of messages that must be sent in order to achieve
routing setup or routing changes. It is however deemed important to
have agreement on the base functionality and the base messages before
such optimizations are discussed.
6. Protocol Extensibility
NetLMM consists of a set of new control messages, described in
Section 5 in this document. Up-to-date values for the message types
are maintained in the online IANA registry of assigned numbers.
NetLMM defines a general extension mechanism using options to allow
optional information to be carried in the control messages. The
options are encoded in the Type-Length-Value format, and are
described in detail in Section 7.2. The options carry additional
information used for processing the message. Up-to-date values for
the option types are maintained in the online IANA registry of
assigned numbers.
The Type field in the NetLMM option is split into two ranges: Type
values of 0 through 127 (inclusive) for not skippable options and 128
through 255 (inclusive) for skippable options. The recipient of a
message with an unrecognized non-skippable option MUST silently
discard the message. Otherwise, if no unrecognized non-skippable
options are found, the message MUST be processed with any
unrecognized skippable option bypassed (i.e. move to next option
using the Length field of the unrecognized option) during processing
by the receiver. The Sub-Type field provides efficient use of the
option type numbering space.
Format:
Giaretta, et al. Expires December 21, 2006 [Page 14]
Internet-Draft NetLMM Protocol June 2006
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type |Option Sub-Type| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
This field identifies the particular type of option serving a
specified function.
Option Sub-Type
This field indicates the sub-type of the option, and provides for
up to 256 related Option Sub-Types with the same Option Type
field.
Length
The value represents the length of the "Data" portion of the
option, in unit of octets.
7. Message and Message Option Formats
7.1. Message Formats
An NetLMM message consists of a header followed by one or more
options. The Message header is common and messages are distinguished
by Type field in the header. NetLMM options are in TLV format and
8byte aligned, though Type field divided into two parts; Option Type
and Option Sub-Type. The length field indicates the exact length of
the following value fields in units of 8 octets. All option payloads
whose length is not a unit of 8 octets must be padded to the correct
alignment.
7.1.1. Message Header
All NetLMM messages start with the following common header.
Parameters for each message are contained in the option format (see
following sections).
Giaretta, et al. Expires December 21, 2006 [Page 15]
Internet-Draft NetLMM Protocol June 2006
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Status | Type | Sub-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
An 8-bit number, indicating the NetLMM protocol version. The
version of the NetLMM protocol specified in this document is 1.
Status
An 8-bit number, which indicates the status of the message. When
used for request messages, e.g., Location Registration, the status
code is normally set to 0, indicating 'Not Applicable'. When used
for reply and acknowledgement messages, the status code indicates
the result of processing the associated request message. The
following values are defined by this document:
0: Not Applicable (N/A)
The status code is not applicable for the message. This is
normally the case for request messages.
1: Success Acknowledgement
The associated request message was successfully processed.
2: Administratively Prohibited
An action was refused due to administrative policy reasons.
3: Lack of Resources
The resources needed to provide the requested service was not
available.
4: Unauthorized MN
Used by the LMA in response to Location Registration or Routing
Setup, to notify the MAG of the MN not being authorized for
service.
Giaretta, et al. Expires December 21, 2006 [Page 16]
Internet-Draft NetLMM Protocol June 2006
6: Duplicate Address
Used by the LMA when an MN Address Setup contains an IP address
that is duplicated in the same NetLMM domain. The specific
invalid addresses MUST be specified in Address Options with
Sub-Type TBD, Duplicate Address.
5: Invalid Address
Used by the LMA when an MN Address Setup contains an IP address
that is invalid. The specific invalid addresses MUST be
specified in Address Options with Sub-Type TBD, Invalid
Address.
7: Over IP Address Limit
Used by the LMA on receipt of a Routing Setup or MN Address
Setup message, if the maximum number of IP addresses allowed
for a MN has been exceeded.
8: Invalid Tunnelling Method
The proposed tunnel method is not supported or unavailable.
9: Invalid Message
The NetLMM Request Message was invalid or malformed.
10: Already Associated
The LMA already had the requesting MAG listed as associated.
Type
8-bit indicator, shows NetLMM message types. The message types
are specified in section 5. The values for messages are defined
as follows;
0: LMA Allocation Request/Reply
1: Association Request/Reply
2: Disassociation Request/Reply
3: Location Registration/Ack
4: Location Deregistration/Ack
5: MN Address Setup/Ack
6: MN Address Remove/Ack
Giaretta, et al. Expires December 21, 2006 [Page 17]
Internet-Draft NetLMM Protocol June 2006
7: Routing Setup/Ack
8: Routing Remove/Ack
9: Heartbeat/Ack
Sub-Type
8-bit indicator, this indicator is Type dependent field and can
use to add extra information for the message.
Sub-types defined in this document, valid for all message types
defined in this document:
0: Request
This is the Request message of the given type, with semantics
and format as specified in this document. When message
variations with other semantics or formats are required in the
future, new subtypes should be allocated for them.
1: Ack/Reply
This is the Acknowledgement (or Reply) message to be sent in
response to request messages of the given type. It is seen as
less likely that it will be necessary to allocate new sub-types
for new Ack/Reply messages, but there is no restriction on
doing so.
Sequence Number
16-bit length, used to ensure the correspondence of the request
and ack/reply pair of the same message between the MAG and the
LMA. The sequence number is exchanged between given MAG and LMA,
and configured when MAG has joined to a NetLMM domain through the
exchange of Association Request/Reply messages. Sequence Number
comparisons MUST be performed modulo 2**16, i.e., the number is a
free running counter represented modulo 65536. A Sequence Number
in a received message is considered less than or equal to the last
received number if its value lies in the range of the last
received number and the preceding 32768 values, inclusive. For
instance, if the last received sequence number was 15, then
messages with sequence numbers 0 through 15, as well as 32783
through 65535, would be considered 'less than or equal'.
Reserved
16-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
Giaretta, et al. Expires December 21, 2006 [Page 18]
Internet-Draft NetLMM Protocol June 2006
Options
8 byte aligned field, and can add multiple options. See following
sections for options.
7.2. Options
7.2.1. ID Option
The ID option carries various types of identifiers. All messages
related to a specific MN must include an ID option providing the MN
ID. Multiple ID options can be included in an message. In addition
to that for the MN ID there might for instance be ID options for the
MAG ID and for the LMA ID in a Location Registration. For the
purpose of the ID option, the ID itself is viewed as an octet
sequence, but to avoid ID collisions, the ID is prefixed with an ID
type. An example for the MN ID is a NAI [RFC4282].
This option can also contain Routing Tag which is an identifier
specified by each tunnel method for data transport. The existence or
use of the Routing Tag is also dependent on the tunnel method to use.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type |Option Sub-Type| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID-Type | Identifier... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
0
Option Sub-Type
This field indicates what the ID in this option refers to. It is
expected that additional Sub-Types may be defined in the future.
0: MN ID
Giaretta, et al. Expires December 21, 2006 [Page 19]
Internet-Draft NetLMM Protocol June 2006
1: LMA ID
2: MAG ID
3: Routing Tag
Length
Variable. The value indicates exact length of the option in
octets, excluding the Type, Sub-Type and Length fields.
ID-Type
This field indicates the type of ID carried in the remainder of
the option.
*** Note: Check whether there already exists an applicable IANA
registry for ID types which we could use here ***
0: 128-bit opaque cryptographically generated identifier (such as
proposed ORCHID IDs
1: NAI according to [RFC4282]
2: Ethernet MAC Address
3: IPv6 Address
Identifier
This is a variable-length octet sequence, which is expected to
hold an identifier of the type indicated by the ID-Type field.
7.2.2. NetLMM Address Option
This option conveys NetLMM IP address and the prefix that LMA
advertise for MNs. The NetLMM address can be both IPv4 and IPv6.
This option can also inform LMA prefix only.
Giaretta, et al. Expires December 21, 2006 [Page 20]
Internet-Draft NetLMM Protocol June 2006
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type |Option Sub-Type| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address (IPv6 case) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
1
Option Sub-Type
0: Indicates that the data in the Address field is an IPv6 address
or address range. If Prefix Length is 128 this is an address,
otherwise it is an address range with span determined by the
given prefix length.
1: Indicates that the data in the Address field is an IPv4
address.
2: Indicates that the data in the Address field is an IPv6 network
prefix information.
3: Indicates that the data in the Address field is an IPv4 network
prefix information.
4: Indicates that the address in the Address field is a duplicate
IPv6 address.
5: Indicates that the address in the Address field is a duplicate
IPv4 address.
6: Indicates that the address in the Address field is an invalid
IPv6 address.
Giaretta, et al. Expires December 21, 2006 [Page 21]
Internet-Draft NetLMM Protocol June 2006
7: Indicates that the address in the Address field is an invalid
IPv4 address.
Length
Variable. The value indicates exact length of the option in
octets, excluding the Type, Sub-Type and Length fields.
Prefix Length
Variable. The value indicates the number of leadings bits in the
Address that are valid (as a network prefix).
If the Sub-Type value indicates an invalid or duplicate address,
this field must be set to zero when sending, and ignored on
receipt.
Reserved
16-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
Address:
If the Option Sub-Type is 0 or 2, the value in the IPv6 address
appears, while the type is 1 or 3, the value in the IPv4 address
is presented.
7.2.3. Data Transport Option
This option contains data transport methods capabilities that the MAG
or LMA has. This option is used by Association request/reply
messages to negotiate the data transport method between MAG and LMA.
Multiple methods can be contained in the field with the order of
preference. The mandatory transport method is IPv6-in-IPv6, which
must be listed.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type |Option Sub-Type| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Transport Method 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Transport Method n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Giaretta, et al. Expires December 21, 2006 [Page 22]
Internet-Draft NetLMM Protocol June 2006
Option Type
2
Option Sub-Type
This field is reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
Length
Variable. The value indicates exact length of the option in
octets, excluding the Type, Sub-Type and Length fields. The
number of Data Transport Method fields is equal to the Length
divided by the size, in octets, of the Data Transport Method
field.
Data Transport Method
Present the data transport methods available at the sender of the
Association request/Reply message, i.e., LMA and MAG. The methods
presented in this option are listed in order of the preference.
0: IPv6-in-IPv6
1: GRE
2: IPv4-in-IPv6
7.2.4. Revocation Timer Option
This option indicates the length, by milliseconds, to keep the
forwarding state of a given MN at previous MAG in handover scenario.
This option is included in Location Deregistration and its
acknowledgement. The Revocation Time in the Location Deregistration
Ack is copied from that presented in the receipt option of the
Location Deregistration. If the MAG can not keep the MN state as LMA
has requested for some reason, MAG can input preferable Revocation
time or error code instead of copying original value.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type |Option Sub-Type| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Revocation Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Giaretta, et al. Expires December 21, 2006 [Page 23]
Internet-Draft NetLMM Protocol June 2006
Option Type
3
Option Sub-Type
This field is reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
Length
4. The value indicates exact length of data shown in Revocation
Time field. Shown in octets, network byte order
Revocation Time
Variable. Indicate the preferred delay to delete the MN
forwarding state from previous MAG to LMA in handover. The value
shows in millisecond unit.
7.2.5. Timestamp Option
This option contains the timestamp value in the format of NTP
timestamp, and records the time when the message is sent. This
option can be attached to any message and used to detect an
overtaking message in race condition by comparing the timestamp
values of messages. Especially in handover scenario, if the network
suffers from a sudden propagation delay for some reason or the MN
moves rapidly between MAGs, the timestamp may be used to facilitate
in-order messages processing regardless of message arrival order.
The use of this option is network administrator dependent, and needs
some of the time distribution methods, (e.g., NTP or GPS time
synchronization system), with the high accuracy enough to support
fast moving MNs.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type |Option Sub-Type| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
4
Giaretta, et al. Expires December 21, 2006 [Page 24]
Internet-Draft NetLMM Protocol June 2006
Option Sub-Type
This field is reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
Length
8. The value indicates exact length of Timestamp field Shown in
octets, network byte order.
Timestamp
Follows the 64bit length format of the NTP timestamp [RFC4330]
7.2.6. Vendor Specific Option
This option can be used by any vendor or organization that has an
IANA-allocated SMI Network Management Private Enterprise Code.
Details of the meaning of value field is entirely up to the defining
vendor or organization.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type |Option Sub-Type| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor/Org-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Value .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
5
Option Sub-Type
This field is reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver. This field may not be assigned any value different from
zero by the organizations using the option; only the Value field
may be freely used.
Length
Variable. The value indicates exact length of the option in
octets, excluding the Type, Sub-Type and Length fields.
Giaretta, et al. Expires December 21, 2006 [Page 25]
Internet-Draft NetLMM Protocol June 2006
Vendor/Org-ID
The high-order octet is 0 and the low-order 3 octets are the SMI
Network Management Private Enterprise Number [RFC2578],
[ENTERPRISE-NUM], of the Vendor in network byte order.
Value
Variable. Details defined by individual Vendors / Organizations.
8. Protocol Specification
8.1. Mobile Access Gateway Operation
8.1.1. Conceptual Data Structures
Each MAG MUST maintain a NetLMM Routing Cache and an LMA List.
Each MAG Routing Cache entry conceptually contains the following
fields for each attached MN:
* MN ID of the attached MN. This identifier is learned from the
attach procedure and is used from the MAG to identify the attached
MN in the Location Registration message, which is sent to the
selected LMA.
* One or more global IP addresses of an attached MN. Each IP
address is learned from an LMA through the Routing Setup message
from an LMA or my means of local operation. According to the
context of the received message or local indication, an IP address
is set up, updated or removed from the Routing Cache.
* Routing Tag for the attached MN. Creating the entry and use of
this tag is optional and might support identification of the MN in
the data plane at the LMA and the MAG. In case the LMA and MAG
specify asymmetric tags for the MN, this field MUST draw a
distinction.
* LMA ID of the LMA serving an attached MN. The serving LMA and its
LMA ID is learned from the LMA selection policy, which is out of
scope of this specification.
Each MAG MUST maintain an LMA List, which identifies all LMAs with
which the MAG is associated. The LMA List is used to perform
heartbeat tests and to map an LMA ID to the associated LMA's IP
address(es). The LMA List also supports the procedure of bulk de-
registrations at all or a subset of LMAs.
The LMA List conceptually contains the following fields for each LMA
Giaretta, et al. Expires December 21, 2006 [Page 26]
Internet-Draft NetLMM Protocol June 2006
entry:
* LMA ID of the LMA.
* One or more IP address(es) of the LMA. The LMA's IP address
information is learned through the LMA selection policy, which is
out of scope of this specification. Availability of multiple LMA
IP addresses could support operation of multi-homed LMAs. Details
about how to handle multiple LMA IP addresses is out of scope of
this specification.
* Selected forwarding approach for the association with an LMA.
This field is needed in case a single forwarding approach is set
up for the association with an LMA.
* Forwarding capabilities of the LMA. In case the LMA attaches a
list of its own capabilities to the Associate Reply message, the
MAG SHOULD store them in this field of the LMA List.
Each MAG MIGHT maintain a list of available LMAs. Such a list can
support the LMA selection procedure and the MAG's association
procedure.
The list of available LMAs comprises conceptually the following
fields for each LMA:
* LMA ID of the LMA.
* One or more IP address(es) of the LMA. Availability of multiple
IP addresses could support the operation of multi-homed LMAs.
Details about how to handle multiple IP addresses is out of scope
of this specification.
8.1.2. Processing NetLMM Headers
* The Type and Sub-Type fields MUST have a known value
(Section 7.1.1). Otherwise, the node MUST discard the message and
issue a an Error message with Status field set to 7 ("INVALID
MESSAGE").
8.1.3. Processing NetLMM Messages
8.1.3.1. Association Procedure
Each Mobile Access Gateway sends an Association Request message in
order to set up the control and data plane relationship with a given
local mobility anchor. The actual trigger for this message is out of
scope of this document and may depend on network configuration
Giaretta, et al. Expires December 21, 2006 [Page 27]
Internet-Draft NetLMM Protocol June 2006
peculiarities. For example, the Association Request message may be
sent during the MAG start up procedure.
The Association Request message MUST include:
* the MAG identifier included in a NetLMM ID option. This
identifier is used by the peer to identify the MAG and is included
in all subsequent messages.
* the MAG's capabilities in terms of support of data transport
methods included in a NetLMM Data Transport Option. The MAG MUST
insert in this option all possible tunneling methods that can be
used with the peer LMA. Based on configuration, it is possible
that some tunneling methods are used only with some LMAs: in this
case, the Association Request message MUST contain only the
tunneling methods that are administratively permitted with that
specific LMA.
When sending an Association Request, the MAG MAY create a tentative
entry in its LMA List, including the LMA ID, IP address of the LMA
and the proposed forwarding capabilities. However it may be that the
MAG does not know these data during the association procedure: in
this case, it does not create any tentative entry in the LMA List.
In order to complete the NetLMM association, the MAG MUST receive an
Association Reply from the peer LMA with STATUS 1. In this case, the
MAG MUST create an entry in its LMA List (or update the tentative
entry created earlier), with the messages sent by the LMA in the
Association Reply. The MAG MUST also update the forwarding method
pre
8.1.3.2. Disassociate Procedure
The Disassociation Request can be sent both by the MAG and by the LMA
in order to tear down the control and data plane relationship with
the LMA. The event that triggers this message is out of the scope of
this specification; for example, the MAG may send a Disassociation
Request to all the LMAs present in its LMA List just before shutting
down.
In case the Disassociate Procedure is initiated by the MAG, the MAG
MUST include an ID Option with the its identity in the Disassociation
Request. When sending the Disassociation Request, the MAG MAY set
the LMA entry related to the specific LMA as tentative. When it
receives a Disassociation Reply with Status 1 "SUCCESS", the MAG MUST
delete the correspondent entry in its LMA List.
In case the Disassociate Procedure is initiated by the LMA, when the
Giaretta, et al. Expires December 21, 2006 [Page 28]
Internet-Draft NetLMM Protocol June 2006
MAG receives a Disassociation Request message, it MUST validate it.
If it is correct, it MUST delete the related entry in its LMA List
and send a Disassociate Reply with Status 1 "SUCCESS". As in all
NetLMM messages, the MAG MUST include the ID option with its
identity.
8.1.3.3. MN network access procedure
When a new MN attaches to the network, the Mobile Access Gateway
receives an indication. This indication can be received by very
different means (e.g., L2 mechanisms, AAA infrastructure) that are
out of scope of this specification. In any case, regardless how this
is accomplished, the MAG receives a MN_Access_Network API that
carries the MN identifier (e.g., MAC address of the MN, NAI) and the
LMA identifier.
Upon the API notification, the MAG MUST send a Location Registration
message to the LMA including three different ID options, containing
its own identity, the identity of the MN and the identity of the LMA.
How the MAG resolves the LMA ID received in the API into the LMA IP
address is out of scope of this specification and is part of the
NetLMM bootstrapping procedure. Viable options are pre-configuration
or DNS resolution (in case the LMA ID is the FQDN of the LMA). In
case there is only one LMA in the local domain, this issue does not
exist.
If the location registration is successfully performed, the MAG
receives a Location Registration Acknowledge message from the LMA
with Status value 1 "SUCCESS". This message includes also a NetLMM
Network Prefix that the MAG MUST advertise to the MN. For this
purpose, the MAG takes the prefix parameters from the NetLMM Address
Option in the Location Registration Acknowledge and creates a Router
Advertisement with a correspondent Prefix Option. It then sends a
unicast Router Advertisement to the MN. (Note: how about the
parameters that are carried in a Prefix Option but are not present in
the NetLMM Address Option? e.g., lifetimes?). In the Prefix Option
sent to the MN the L flag MUST be unset and the A flag MUST be set or
unset, depending on the possibility to perform stateless auto-
configuration in the local domain.
8.1.3.4. MN IP address notification procedure
The NetLMM protocol specification is agnostic of how the IP address
is assigned to the MN in the local domain. However, the MAG needs to
know the IP address assigned or auto-configured by the MN in order to
update the routing at the LMA. For this purpose, the MAG needs to
play an active role in the DHCP exchange or needs to receive a
trigger after the MN has configured an IP address via stateless auto-
Giaretta, et al. Expires December 21, 2006 [Page 29]
Internet-Draft NetLMM Protocol June 2006
configuration. How this is done is described later in this section.
As soon as the MAG knows that a specific IP address has been assigned
to a MN, it MUST send a MN Address Setup message to the serving LMA,
including three ID options (MN ID, MAG ID, LMA ID), a NetLMM Address
option containing the address assigned to (or configured by) the MN.
This message is a request to the LMA to start forwarding the packets
destined to that IP address to the MAG. The MAG MAY also add the new
IP address to the Routing Cache entry related to that MN.
When it receives a MN Address Setup Acknowledgement message with
Status 1 "SUCCESS", the MAG MUST add the new IP address to the
Routing Cache entry of the MN (or set it as non tentative if
previously updated) and update its forwarding state. In case the
message contains a different Status value (Values 5 or 6), it MUST
reject the assignment of the IP address to the MN, depending on the
method used by the MN to request the address (i.e., DHCP or stateless
auto-configuration).
In case DHCP is used, the MAG MUST act as DHCP Relay Agent in order
to have an active role in the DHCP exchange. The MAG then receives
from the DHCP server the IP address assigned to the MN in a DHCP
Relay-reply message and updates the routing at the LMA and at the
same time can send a DHCP Reply message to the MN with the assigned
address. It is important that in the DHCP-Relay-forward message, the
MAG includes the identifier of the LMA that is in charge of serving
that MN so that the DHCP server can select the IP address accordingly
(i.e., from the IP subnet of the LMA). In case the MAG receives a MN
Address Setup Acknowledgement message with Status 5 or 6, it MUST
send a DHCP Reply message, refusing the IP address assignment to the
MN.
In case stateless auto-configuration is performed, the trigger to
update the routing at the LMA is the DAD procedure. The DAD
procedure is performed on the MAG link, but the MAG needs to verify
the address uniqueness at the LMA; for this purpose, it sends the MN
Address Setup message. If the LMA replies with a Status value equal
to 5 or 6, the MAG MUST send a Neighbor Advertisement in order to
fake an IP address duplication.
8.1.3.5. MAG to MAG handover procedure
When a MN hands over from one MAG to another, the new MAG may not
know if the event occurred is a handover or a network attach. This
is because the base protocol specified in this document is agnostic
of any MAG to MAG communication that may be in place. Due to this
reason, as for network attach, the MAG will just receive a trigger
that a new MN has attached to the link; this trigger, referred as a
Giaretta, et al. Expires December 21, 2006 [Page 30]
Internet-Draft NetLMM Protocol June 2006
MN_Access_Network API carries the MN ID and the LMA ID. As mentioned
above, this API can be for example based on an AAA exchange.
After receiving this API, the MAG performs the same procedure
described for network access (see section Section 8.1.3.3): it sends
a Location Registration message including three different ID options,
containing the MN ID, the MAG ID and the LMA ID.
In this handover handover case, the MAG does not receive immediately
a Location Registration Acknowledgement message; instead it receives
a Routing Setup message from the LMA that includes all IP addresses
that are assigned to the MN. These addresses are included in one or
more NetLMM Address options. The message contains also some
forwarding state, based on the tunneling mechanism used. (Note: how
the tunnel ID is carried in the message? Is it really needed at this
step?). When the MAG receives this message, it MUST create a new
entry in its Routing Cache for the specific MN and MUST update its
forwarding state. In case no errors occur, the MAG sends back to the
LMA a Routing Setup Acknowledgement message with Status value set to
1 "SUCCESS" and including the forwarding state information.
After that, the MAG receives the Location Registration
Acknowledgement message that includes the NetLMM prefix to be
delivered to the MN. The procedure is the same as described for
network attach in section Section 8.1.3.3.
8.1.3.6. Resource Revocation
If the MAG receives a Location Deregistration message from the LMA,
it MUST delete the entry related to the MN specified in the MN ID
Option in its Routing Cache. Moreover, the MAG MUST remove any
forwarding state for the MN. After doing that, the MAG MUST send a
Location Deregistration Acknowledgement to the LMA with Status 1
"SUCCESS".
In case the Location Deregistration contains a Timer attribute (Note:
it seems to me the Timer option has not been defined yet), the MAG
MAY keep forwarding uplink packets to the LMA for the MN. This may
be useful in case of make before break link layer technologies. The
adopted timer cannot be greater than the one suggested by the LMA and
MUST be sent back to the LMA in the Location Deregistration message
acknowledgement.
8.1.3.7. Network Detachment
In case the MAG has an indication that the MN has detached from the
network (e.g., via AAA architecture), the MAG MUST (Note: if the
protocol is stateful and we do not have a lifetime in the location
Giaretta, et al. Expires December 21, 2006 [Page 31]
Internet-Draft NetLMM Protocol June 2006
registration, this is a MUST, otherwise it can be a SHOULD) send a
Location Deregistration message with an ID option including the MN
ID. After receiving the Location Deregistration Acknowledgement, the
MAG MUST remove any mobility and forwarding state in its Routing
Cache related to that MN.
8.1.3.8. IP address no longer in use
In case the MAG has an indication that an IP address is no longer
used by the MN, it MUST send a MN Address Remove message to the LMA,
including the MN ID and the NetLMM Address that needs to be removed
in a NetLMM Address option. How the MAG detects that an IP address
is no longer used is out of the scope of this document.
8.1.3.9. Link availability test
MAGs should ensure availability of their link to LMAs. To test link
availability, each MAG should periodically send a Heartbeat message
to each LMA with which it has associated according to the entries in
the LMA List. If the Heartbeat Ack message from the LMA is received
within HEARTBEAT_TIMEOUT seconds, availability of the link to the LMA
is proven. If the MAG does not receive the Heartbeat Ack message
within HEARTBEAT_TIMEOUT seconds, the MAG should send
HEARTBEAT_RETRY_MAX further Heartbeat messages with incremented
sequence number. In case none of these Heartbeat messages is
acknowledged by the LMA, the MAG should raise an alarm. Optionally,
the MAG can inform an external OAM function about the broken link.
To avoid superfluous bandwidth consumption, MAGs should send
Heartbeat messages to an LMA only in case there was no traffic on the
associated link for LINK_ACTIVITY_TIMEOUT seconds. MAGs should
perform Heartbeat tests according to the following rule:
In case there was no signaling activity on a link to an LMA for
LINK_ACTIVITY_TIMEOUT seconds, the MAG waits for an additional random
delay time between HEARTBEAT_DELAY_MIN and HEARTBEAT_DELAY_MAX
seconds. After the delay has expired, the MAG sends the Heartbeat
message to the LMA. In case the MAG receives a Heartbeat message
from the LMA while waiting for the additional random delay, the MAG
should reset the delay timer and refrain from sending the Heartbeat
message, but MUST acknowledge the Heartbeat message using the same
sequence number as in the received message.
8.2. Local Mobility Anchor Operation
8.2.1. Conceptual Data Structures
Each LMA MUST maintain a NetLMM Routing Cache and a MAG List.
Giaretta, et al. Expires December 21, 2006 [Page 32]
Internet-Draft NetLMM Protocol June 2006
Each LMA Routing Cache entry conceptually contains the following
fields for each MN:
* MN ID of the registered MN. This Identifier is learned through
the Location Registration message, which registers an attached MN.
Optionally, the MN ID is learned though the LMA Allocation message
beforehand, which could enable service authorization for this
particular MN ID at the LMA.
* Routing Tag for the registered MN. Creating the entry and use of
this tag is optional and might support identification of the MN in
the data plane at the LMA and the MAG. In case the LMA and MAG
specify asymmetric tags for the MN, this field MUST draw a
distinction.
* MAG ID of the registered MN's serving MAG. This identifier is
learned through the Location Registration message, which registers
an attached MN. Dependent on the context of this message, the MAG
ID entry is either initialized or updated in case of the MN's
handover. The MAG ID can be linked to the associated MAG's IP
address With the help of the MAG List.
* One or more global IP addresses of a registered MN. Each IP
address is learned from an MN Address Setup message. According to
the context of the received message, the IP address is set up,
updated or removed from the Routing Cache.
Each LMA MUST maintain a MAG List, which refers to associated MAG
entities. The list of associated MAGs is used to perform heartbeat
tests and to map the Routing Cache's MAG ID entries to the associated
MAG's IP address(es). The MAG List also supports the procedure of
bulk de-registrations at all or a subset of associated MAGs.
The MAG List conceptually contains the following fields for each
associated MAG:
* MAG ID of the associated MAG.
* One or more IP address(es) of the associated MAG. The MAG's IP
address information is learned through the Associate message.
* Forwarding capabilities of the associated MAG. This capability
list is learned from a particular MAG through the Associate
message. From the list of supported forwarding approaches, the
LMA enters only these approaches to the capabilities, which are
supported by the LMA.
Giaretta, et al. Expires December 21, 2006 [Page 33]
Internet-Draft NetLMM Protocol June 2006
* Forwarding setting for the associated MAG. This field is needed
in case the LMA configures a single forwarding approach per MAG
association.
* Capability list of the associated MAG. These capabilities are
learned from a particular MAG through the Associate message.
8.2.2. Processing NetLMM Headers
All NetLMM local mobility anchors MUST observe the rules described in
Section 8.1.2 when processing NetLMM Headers.
8.2.3. Processing NetLMM Messages
8.2.3.1. Associate Procedure
When a LMA receives an Association Request message, it MUST look up
into its MAG list based on the MAG identifier contained in the ID
option included in the request. If an entry for that MAG ID is
already present in the MAG list, the LMA MUST send an Associate Reply
message to the MAG with STATUS 10 "Already Associated" (note: an
alternative may be that the LMA silently discards the message) (note:
another alternative is that the new association request is an
association update, e.g., in order to propose a new forwarding
method. I would keep things simple and not include this case, not
allowing an Association Request if the MAG is already associated).
If an entry for the MAG identifier contained in the ID option does
not exist, the LMA MUST create it, including the parameters contained
in the Association Request message (MAG ID, MAG IP address). Based
on internal policy (e.g., pre-configuration) the LMA MAY accept the
data forwarding method proposed by the MAG or MAY propose other
methods in Access Reply. After creating the entry, the LMA MUST send
an Associate Reply message with STATUS value 1 ("Success"), including
its ID in an ID option. Optionally, it MAY include also a Data
Transport Option included the data forwarding method to be used.
(Note: don't we need a message ID in order to bind the request with
the reply?)
The Association Request message MUST include:
* the LMA identifier included in a NetLMM ID option. This
identifier is used by the peer to identify the LMA and is included
in all subsequent messages.
* the LMA's capabilities in terms of support of data transport
methods included in a NetLMM Data Transport Option. The LMA MUST
insert in this option all possible tunneling methods that can be
Giaretta, et al. Expires December 21, 2006 [Page 34]
Internet-Draft NetLMM Protocol June 2006
used with the peer MAG Based on configuration, it is possible that
some tunneling methods are used only with some MAGs: in this case,
the Association Request message MUST contain only the tunneling
methods that are administratively permitted with that specific
MAG.
8.2.3.2. Disassociate Procedure
In case the Disassociate procedure is initiated by the MAG, when the
LMA receives a Disassociation Request message, the LMA MUST validate
it. If it is correct, it MUST delete the related entry in its MAG
List and send a Disassociate Reply with Status 1 "SUCCESS". As in
all NetLMM messages, the LMA MUST include the ID option with its
identity.
In case the Disassociate Procedure is initiated by the LMA the LMA
MUST include an ID Option with the its identity in the Disassociation
Request. When sending the Disassociation Request, the LMA MAY set
the MAG entry related to the specific MAG as tentative. When it
receives a Disassociation Reply with Status 1 "SUCCESS", the LMA MUST
delete the correspondent entry in its MAG List.
8.2.3.3. MN network access procedure
When the local mobility anchor receives a Location Registration
message, it MUST validate it (note: what does it mean? should it
check if the MAG ID in the message is in the MAG List). If the
message is valid, it MUST check if an entry for the MN identifier
included in the Location Registration is present. If an entry is
already present, it means that a MAG to MAG handover has occurred:
the detailed procedure for this event is described in
Section 8.2.3.5.
If an entry for that MN identifier is not present, the LMA MUST
create a new entry with the MN ID, the MAG ID (?) and the MAG IP
address (?). (Note: the two latter parameters are not present in the
Routing Cache description. How the protocol works without them?).
After creating the entry, it MUST send a Location Registration
Acknowledgement with STATUS 1, including three ID options (MN ID, LMA
ID, MAG ID) and the NetLMM prefix in a NetLMM Address option. The
NetLMM prefix is then forwarded in a Router Advertisement to the MN
by the MAG and used by the MN to auto-configure an IP address using
stateless auto-configuration and/or to detect a change of local
domain.
In case the Location Registration is not valid or the registration
procedure cannot be completed successfully, the LMA MUST send a
Location Registration Acknowledgement with an appropriate Status
Giaretta, et al. Expires December 21, 2006 [Page 35]
Internet-Draft NetLMM Protocol June 2006
value.
8.2.3.4. MN IP address notification procedure
When the MN tries to configure a new IP address on the local domain,
the local mobility anchor receives a MN Address Setup message from
the MAG which the MN is connected to. This message contains the IP
address the MN is trying to configure in a NetLMM Address option.
(Note: in the slides there is also a tunnel ID but I am not sure this
is actually needed).
When it receives this message, the LMA MUST check if the IP address
in the NetLMM Address option is already assigned to another MN. If
the address is a duplicated one, it MUST send a MN Address Setup
Acknowledgement message with Status 5 "INVALID IP ADDRESS". If the
address is not assigned to any other MN, the LMA MUST check if the
number of addresses assigned to that MN does not exceed the maximum
number of addresses that the MN can configure. This check is
performed in the LMA Routing Cache; the maximum number of allowed IP
addresses is a per MN variable that is pre-configured at the LMA. If
the number of IP addresses exceeds the allowed one, the LMA MUST send
a MN Address Setup Acknowledgement message with Status 6 "OVER IP
ADDRESS LIMIT". (Note: the first check is mainly performed for the
stateless configuration case and may be skipped in case DHCP is used.
However the LMA does not know if the address is configured using DHCP
or stateless so I would keep this check in any case)
If the IP address is not a duplicated one and the maximum number of
allowed IP addresses is not reached, the LMA MUST update the Routing
Cache entry indexed by the MN ID contained in the MN Address Setup
message with the new IP address and MUST update its forwarding state,
depending on the tunneling mechanism used.
8.2.3.5. MAG to MAG handover procedure
When the LMA receives a Location Registration message, it MUST check
in its Routing Cache if an entry for the MN ID carried in the message
is already present. If it is not, that means that the MN is
accessing the network for the first time (see section
Section 8.2.3.3). If an entry is already present in the Routing
Cache, a handover has occurred. In this case the LMA MUST send a
Routing Setup message to the MAG, including three ID options (MN ID,
MAG ID, LMA ID), one or more NetLMM Address options containing all
NetLMM addresses configured to the MN and some forwarding state
information that depends on the tunneling method used (e.g., tunnel
ID).(Note: what it the behavior of the LMA during this time interval
when packets arrive? Should it already update the Routing Cache
entry or should it wait for an ack?)
Giaretta, et al. Expires December 21, 2006 [Page 36]
Internet-Draft NetLMM Protocol June 2006
After that the LMA receives a Routing Setup Acknowledgement message;
if the Status of this message is set to SUCCESS, the LMA MUST update
the Routing Cache with the new location of the MN, updating the MAG
ID. The LMA MUST then send back to the MAG a Location Registration
Acknowledgement message with Status value set to 1 "SUCCESS",
including in a NetLMM Address option the NetLMM prefix to be sent to
the MN.
8.2.3.6. Resource Revocation
There are case (e.g. due to administrative reasons) where the
forwarding state of a specific MN must be purged so that the MN is no
more able to use the resources provided by the network. In this
case, based on a trigger received from the network (e.g. AAA), the
LMA MUST send a Location Deregistration message to the peer MAG,
including the MN ID, the LMA ID and the MAG ID. Optionally, the LMA
MAY include a Timer attribute specifying the remaining time to keep
the state of the MN in the MAG. The revocation procedure terminates
when the LMA receives a Resource Revocation Acknowledgement with
Status 1.
8.2.3.7. Network Detachment
When the LMA receives a Location Deregistration message from the peer
MAG, it MUST remove in its Routing Cache the entry of the MN
indicated by the MN ID in the Location Deregistration message. After
that, it MUST send a Location Deregistration Acknowledgement with
Status 1, including the MN ID, the MAG ID and the LMA ID.
8.2.3.8. IP address no longer in use
When the LMA receives a MN Address Remove message, it MUST remove the
NetLMM Address included in the NETLMM Address option from the entry
in its Routing Cache related to the MN indicated in the message.
After that, the LMA MUST respond with a MN Address Remove
Acknowledgement with Status 1.
8.2.3.9. Link availability test
LMAs should ensure availability of their link to MAGs. To test link
availability, each LMA should periodically send a Heartbeat message
to each associated MAG according to the entries in the MAG List. If
the Heartbeat Ack message from the MAG is received within
HEARTBEAT_TIMEOUT seconds, availability of the link to the MAG is
proven. If the LMA does not receive the Heartbeat Ack message within
HEARTBEAT_TIMEOUT seconds, the LMA should send HEARTBEAT_RETRY_MAX
further Heartbeat messages with incremented sequence number. In case
none of these Heartbeat messages is acknowledged by the MAG, the LMA
Giaretta, et al. Expires December 21, 2006 [Page 37]
Internet-Draft NetLMM Protocol June 2006
should raise an alarm. Optionally, the LMA can inform an external
OAM function about the broken link.
To avoid superfluous bandwidth consumption, LMAs should send
Heartbeat messages to a MAG only in case there was no traffic on the
associated link for LINK_ACTIVITY_TIMEOUT seconds. LMAs should
perform Heartbeat tests according to the following rule:
In case there was no signaling activity on a link to a MAG for
LINK_ACTIVITY_TIMEOUT seconds, the LMA waits for an additional random
delay time between HEARTBEAT_DELAY_MIN and HEARTBEAT_DELAY_MAX
seconds. After the delay has expired, the LMA sends the Heartbeat
message to the MAG. In case the LMA receives a Heartbeat message
from a MAG while waiting for the additional random delay, the LMA
should reset the delay timer and refrain from sending the Heartbeat
message, but MUST acknowledge the Heartbeat message using the same
sequence number as in the received message.
9. Data Transport
As soon as a particular MAG has associated with an LMA and an
attached MN has been registered with the LMA, the LMA node and the
MAG node are responsible for forwarding the MN's data traffic
correctly within the NetLMM domain. Associated location and
forwarding information is maintained within the LMA's and the MAG's
Routing Cache. Different forwarding mechanisms between the LMA node
and a particular MAG node might be supported and set up during the
MAG's association procedure.
Network entities, which have Version 0 of the NetLMM protocol
implemented, MUST support IPv6-in-IPv6 encapsulation to tunnel data
packets between an LMA node and an associated MAG node. Support of
other forwarding approaches are for future extensions.
9.1. Forwarding of Unicast Data Packets
9.1.1. Handling of hop limit field in IPv6 data packets
According to the NetLMM default mechanism to forward data packets
between a particular LMA and MAG by means of encapsulation, LMA nodes
and MAG nodes serve as tunnel entry-points and tunnel exit-points
respectively. LMAs and MAGs have to decrement the hop limit field of
the encapsulated IPv6 header properly. The MAG serves as the default
gateway for an attached MN and forwards all packets from the MN into
the tunnel, which in turn encapsulates the packet towards the LMA.
The LMA on receiving the packet from the MAG decapsulates and
forwards the packet using normal forwarding procedures. The packets
Giaretta, et al. Expires December 21, 2006 [Page 38]
Internet-Draft NetLMM Protocol June 2006
destined towards the MN are forwarded in a similar fashion. The
procedure of forwarding the packet decrements the hop limit. Hence,
the hop limit will get decremented twice for any packet traversing
the tunnel between LMA and MAG.
9.1.2. IPv6-in-IPv6 tunnel
LMA and MAG nodes MUST support IPv6-in-IPv6 encapsulation to forward
packets within the NetLMM domain. Support of other forwarding
schemes is optional. When an LMA node receives an IPv6 packet
destined for a registered MN and IPv6-in-IPv6 tunneling has been
selected as forwarding approach, it serves as tunnel entry-point.
The LMA node decrements the hop limit of the data packet's IPv6
header by one and encapsulates the packet in the tunnel IPv6 header.
The tunnel IPv6 header might carry one or more extension headers.
The LMA node forwards the tunnel packet to the MAG node, using its
own address as source address and the MAG node's address as
destination address in the outer IPv6 header. The MAG node
terminates the tunnel and MUST process relevant Extension Headers,
which might follow the encapsulating IPv6 header. The MAG node
forwards the data packet towards the MN after decapsulation.
To forward uplink packets, the MAG node serves as tunnel entry-point
and decrements the data packet's hop limit field by one before it
encapsulates the packet in the tunnel IPv6 header. The tunnel IPv6
header might carry one or more extension headers. The MAG node
forwards the tunnel packet to the LMA node, using its own address as
source address and the LMA node's address as destination address in
the outer IPv6 header. The LMA node terminates the tunnel and MUST
process relevant Extension Headers, which might follow the
encapsulating IPv6 header. The LMA node forwards the data packet
towards its final destination after decapsulation.
9.1.3. Future extensions
Future extensions might support other approaches to forward data
packets between LMA and MAG nodes. Such extensions could include
IPv4-in-IPv6 encapsulation to forward IPv4 data packets of dual stack
hosts within the NetLMM domain. Operators might prefer the use of
other flexible forwarding approaches, such as Generic Routing
Encapsulation (GRE) [RFC2784] or Multi-Protocol Label Switching
(MPLS), and follow [RFC3031] and associated mechanisms to forward
data packets between LMA and MAG nodes. Details about the use of
such extensions are out of scope of this specification.
For now, some suggestions of how GRE tunnelling could be used with
NetLMM can be found in Appendix B, and similarly use with MPLS is
described in Appendix C.
Giaretta, et al. Expires December 21, 2006 [Page 39]
Internet-Draft NetLMM Protocol June 2006
9.2. Forwarding of Multicast Data Packets
9.2.1. Link Local Multicast
The scope of link local multicast packets is confined to the link
between MNs and the associated MAG node. MAG nodes process but do
not forward link local multicast packets. To support some functions,
such as for Duplicate Address Detection (DAD), MAGs might proxy
associated Neighbor Discovery messages to perform DAD procedure with
LMA nodes.
9.2.2. IP Multicast
Three options have been identified to support IP multicast within a
NetLMM domain.
Option 1 implies that MAG nodes are multicast-enabled routers and
support for IP multicast is orthogonal to the NetLMM protocol
operation. According to native multicast support, access routers
terminate a multicast tree and the LMA node does not play any
multicast-specific role in forwarding of IP multicast traffic.
Option 2 implies that MAG nodes are multicast-enabled routers and
IP multicast traffic is tunnelled via the NetLMM domain's LMA
nodes.
Option 3 implies that an NetLMM domain's LMA nodes are multicast-
enabled routers. LMA nodes join a multicast-tree and forward IP
multicast packets to MAG nodes according to the selected
forwarding approach. MAG nodes must coordinate multicast
listeners according to IGMP operation [RFC3376] and communicate
with LMA nodes using PIM control messages [RFC2362] to control IP
multicast forwarding path between LMA nodes and respective MAG
nodes, which have multicast listeners attached. LMA nodes
coordinate multicast listener registration with other multicast
routers, which are outside of an NetLMM domain, by means of PIM
control messages. An exemplary IP multicast join procedure is
illustrated in Fig. *MCJOIN*
The specification of default operation for IP multicast support and
optional enhancements is for further study and t.b.d.
Giaretta, et al. Expires December 21, 2006 [Page 40]
Internet-Draft NetLMM Protocol June 2006
+--+ +---+ +---+ +--+
|MN| |MAG| |LMA| |MR|
+--+ +---+ +---+ +--+
| | | |
| | | |
|----IGMP---->| | |
| |----PIM Join--->| |
| | |----PIM Join----->|
/ / / /
/ / / /
|<------------|<===============|<-----------------|<--MC Data
| | | forward to group |
|-- MC Data-->|===============>|----------------->|-->
Figure *MCJOIN*: IP multicast join procedure for the case that LMA
nodes and MAG nodes are multicast routers.
9.3. Forwarding of Broadcast Data Packets
Version 0 of the NetLMM protocol specification does not consider
forwarding of broadcast data packets.
10. Protocol Constants and Configuration Variables
11. Security Considerations
The NetLMM protocol is executed between the MAG and LMA. The
messages are used to create, update and delete mobility state in MAG
and LMA. If the NetLMM signalling messages are not authenticated,
following attacks are possible.
* A malicious node can pretend to be MAG and associate with the LMA.
This in itself may not create any harm if subsequent messages are
authenticated. But it does allow for the attacker to learn the
capabilities of the LMA which in turn may be used to exploit the
specific weaknesses.
* A malicious node can pretend to be MAG and send a location
registration message to LMA. There are a couple of variants of
this attack.
- The MN is currently attached to MAG-1 and the IP address of the
MN is known. A malicious node MAG-2 sends the location
registration message to redirect all the traffic destined for
the MN to itself. This enables the attacker to steal the MN's
Giaretta, et al. Expires December 21, 2006 [Page 41]
Internet-Draft NetLMM Protocol June 2006
traffic. This attack may be detected by MAG-1 when it receives
the location de-registration message from LMA while the MN is
still attached. The detection of the attack depends on the
security of mechanism used to detect the MN's attachment.
- The MN is currently attached to MAG-1 and the IP address of the
MN is not known. A malicious node MAG-2 sends the location
registration message to redirect all the traffic destined for
the MN to itself. The LMA would update the mobility state for
MN with the ID of MAG-2. Later when the MN-address-setup
messages comes from MAG-1, it would fail because the MAG IDs
don't match.
* A malicious man-in-the-middle node can alter the messages sent
between MAG and LMA that can result in random attacks. For
example, the attacker can modify the MN Identifier in the location
registration message of MN-1 to that of MN-2. When MN-2 moves to
a new link, it results in a new location registration message to
be sent with MN-2 ID. This will cause the traffic destined to
MN-1 address to be destined to the current link causing disruption
for both MN-1 and MN-2.
These attacks can be prevented by providing data origin
authentication for the messages exchanged between LMA and MAG. This
can be achieved by using IPsec ESP [RFC4303] with null-encryption and
non-null authentication between MAG and LMA.
It is possible to filter the signalling messages at the edge of the
network so that a rogue MN or rogue node on the Internet cannot
source such messages. Hence, any messages exchanged between the MAG
and LMA can only come from within the network. This level of
security may be sufficient for some deployments precluding the need
for protecting the signalling messages. In such cases, IPsec may not
be used to protect the signalling messages.
Anomalous events should be logged. For example, once an address is
assigned to the Mobile node, MN address setup message should appear
at the LMA sooner or later. If it does not appear within a certain
period of time, it should be considered as an error and logged.
[TBD: May be document more of such events].
NetLMM messages are triggered by MN attachment and detachment to the
MAG. The threats specific to MN-MAG interface are discussed in
[I-D.ietf-netlmm-threats]. When neighbor discovery messages
[I-D.ietf-ipv6-2461bis] are used as triggers, it should be secured
using [RFC3971].
Giaretta, et al. Expires December 21, 2006 [Page 42]
Internet-Draft NetLMM Protocol June 2006
12. IANA Considerations
13. Contributors
This contribution is a joint effort of the NetLMM design team of the
NetLMM WG. The members include Kent Leung, Gerardo Giaretta, Phil
Roberts, Marco Liebsch, Katsutoshi Nishida, Hidetoshi Yokota, Henrik
Levkowetz, and Mohan Parthasarathy.
14. Acknowledgments
15. References
15.1. Normative References
[I-D.ietf-ipv6-2461bis]
Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
draft-ietf-ipv6-2461bis-07 (work in progress), May 2006.
[I-D.ietf-netlmm-nohost-ps]
Kempf, J., "Problem Statement for Network-based Localized
Mobility Management", draft-ietf-netlmm-nohost-ps-04 (work
in progress), June 2006.
[I-D.ietf-netlmm-nohost-req]
Kempf, J., "Goals for Network-based Localized Mobility
Management (NETLMM)", draft-ietf-netlmm-nohost-req-01
(work in progress), April 2006.
[I-D.ietf-netlmm-threats]
Kempf, J. and C. Vogt, "Security Threats to Network-based
Localized Mobility Management",
draft-ietf-netlmm-threats-00 (work in progress),
April 2006.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering,
S., Handley, M., and V. Jacobson, "Protocol Independent
Multicast-Sparse Mode (PIM-SM): Protocol Specification",
RFC 2362, June 1998.
Giaretta, et al. Expires December 21, 2006 [Page 43]
Internet-Draft NetLMM Protocol June 2006
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", RFC 4330, January 2006.
15.2. Informative References
[ENTERPRISE-NUM]
IANA, "IANA Enterprise Numbers Registry"", 2006.
[RFC4064] Patel, A. and K. Leung, "Experimental Message, Extensions,
and Error Codes for Mobile IPv4", RFC 4064, May 2005.
Appendix A. TODO (Things that remain to be specified...)
This is a short list of things that remain to be specified in future
revisions of this document:
* Describe the re-send mechanism for control messages, in order to
provide reliable delivery.
Giaretta, et al. Expires December 21, 2006 [Page 44]
Internet-Draft NetLMM Protocol June 2006
* Add an "LMA Announce message" which can be multicast from a newly
connected LMA to trigger listening MAGs to send it Association
Requests.
* Add the capability to do bulk MN de-registrations and possibly
registrations.
* A review to ensure that all aspects of the protocol permits
operation with both single /128 addresses and for instance /64
prefix allocations to mobile nodes.
* Add reserved status ranges (Section 7.1.1) for vendor-specific
status, LMA status?, MAG status?.
* Add experimental message, option and status values, in accordance
with [RFC4064].
* Add a Heartbeat Sequence Number Option, to hold heartbeat-specific
sequence numbers needed by algorithms for reacting to missed
heartbeats. Write up suggested algorithm.
* Make sure the use of the identity / locator split paradigm is
consistent and workable throughout the document. Cover resolution
of ID to locator.
* Define how capability exchanges are handled, and how a unique
common capability is derived, for instance to find the tunnelling
method to be used as a result of the Association Request and
Reply.
* Add message and signalling optimization according to Section 5.12.
* Maybe change the range-based skippable or non-skippable nature of
Options to be indicated by a bit instead?
* Point out somewhere that although a NetLMM Domain may have
multiple LMAs, a MN is always served by the same LMA once an LMA
has been assigned.
*
Appendix B. Using GRE Tunnels with NetLMM
** Text to be written **
Giaretta, et al. Expires December 21, 2006 [Page 45]
Internet-Draft NetLMM Protocol June 2006
Appendix C. Using MPLS with NetLMM
** Text to be written **
Appendix D. TTL Handling
** Text to be written **
Appendix E. MN-AR Interface considerations
This document assumes that the MN-AR interface document will describe
the following in more detail:
* - A mechanism for indicating duplicate address to the MN
* - No redirects should be sent by MAG to MN even if the destination
is directly connected to MAG
* - Trigger for IP address configuration
* - MN Identifier option in the trigger ?
* - If SEND is used, Proxy SEND details are needed for defending the
address in the case of a duplicate
* - Router advertisement details : unicast only, what else does it
contain etc."
Appendix F. Out of scope
- Inter-MAP handover - Fast handover - Hierarchical MAP
Giaretta, et al. Expires December 21, 2006 [Page 46]
Internet-Draft NetLMM Protocol June 2006
Authors' Addresses
Gerardo Giaretta
Telecom Italia
via Reiss Romoli 274
Torino 10148
Italy
Phone: +39 011 228 6904
Email: gerardo.giaretta@telecomitalia.it
Kent Leung
Cisco
170 W. Tasman Drive
San Jose, CA 95134
USA
Phone: +1 408 853 9580
Email: kleung@cisco.com
Marco Liebsch
NEC Network Laboratories
Kurfuersten-Anlage 36
Heidelberg, 69115
Germany
Phone: +49 6221-90511-46
Email: marco.liebsch@netlab.nec.de
Phil Roberts
Motorola
1301 E Algonquin Rd
Schaumberg, IL 60196
USA
Email: phil.roberts@motorola.com
Giaretta, et al. Expires December 21, 2006 [Page 47]
Internet-Draft NetLMM Protocol June 2006
Katsutoshi Nishida
NTT DoCoMo Inc.
3-5 Hikarino-oka, Yokosuka-shi
Kanagawa,
Japan
Phone: +81 46 840 3545
Email: nishidak@nttdocomo.co.jp
Hidetoshi Yokota
KDDI R&D Laboratories, Inc.
2-1-15 Ohara, Fujimino
Saitama, 356-8502
Japan
Phone: +81 49 278 7894
Email: yokota@kddilabs.jp
Mohan Parthasarathy
Nokia
Email: mohan.parthasarathy@nokia.com
Henrik Levkowetz
Ericsson
Torsgatan 71
Stockholm S-113 37
SWEDEN
Phone: +46 708 32 16 08
Email: henrik@levkowetz.com
Giaretta, et al. Expires December 21, 2006 [Page 48]
Internet-Draft NetLMM Protocol June 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.
Giaretta, et al. Expires December 21, 2006 [Page 49]