One document matched: draft-giaretta-netlmm-dt-protocol-01.txt
Differences from draft-giaretta-netlmm-dt-protocol-00.txt
NetLMM H. Levkowetz, Ed.
Internet-Draft Ericsson
Expires: March 22, 2007 G. Giaretta
Telecom Italia
K. Leung
Cisco
M. Liebsch
NEC
P. Roberts
Motorola
K. Nishida
NTT DoCoMo Inc.
H. Yokota
KDDI Labs
M. Parthasarathy
Nokia
September 18, 2006
The NetLMM Protocol
draft-giaretta-netlmm-dt-protocol-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 22, 2007.
Copyright Notice
Levkowetz, et al. Expires March 22, 2007 [Page 1]
Internet-Draft The NetLMM Protocol September 2006
Copyright (C) The Internet Society (2006).
Abstract
This document specifies an Internet protocol that allows mobile nodes
to move around in a local 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 changed, and maintaining
seamless communication in the presence of such changes. 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, as
long as they remain within the local mobility domain.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Functional Entities . . . . . . . . . . . . . . . . . . . . . 7
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Mobility Management . . . . . . . . . . . . . . . . . . 8
4.2. Setup and Node Association . . . . . . . . . . . . . . . 12
4.3. Message Transport . . . . . . . . . . . . . . . . . . . 13
5. Message Format and Message Types . . . . . . . . . . . . . . . 15
5.1. Message Format . . . . . . . . . . . . . . . . . . . . . 15
5.2. LMA Allocation Request . . . . . . . . . . . . . . . . . 17
5.3. Location Registration . . . . . . . . . . . . . . . . . 17
5.4. Location Deregistration . . . . . . . . . . . . . . . . 18
5.5. Association Request . . . . . . . . . . . . . . . . . . 18
5.6. Disassociation Request . . . . . . . . . . . . . . . . . 19
5.7. Heartbeat . . . . . . . . . . . . . . . . . . . . . . . 19
5.8. Acknowledgements . . . . . . . . . . . . . . . . . . . . 21
5.9. Message Status Codes . . . . . . . . . . . . . . . . . . 21
6. Option Format and Option Types . . . . . . . . . . . . . . . . 23
6.1. Option Format . . . . . . . . . . . . . . . . . . . . . 23
6.2. Option Alignment . . . . . . . . . . . . . . . . . . . . 24
6.3. ID Option . . . . . . . . . . . . . . . . . . . . . . . 25
6.4. Prefix Option . . . . . . . . . . . . . . . . . . . . . 26
6.5. Data Transport Option . . . . . . . . . . . . . . . . . 28
6.6. Deregistration Timeout Option . . . . . . . . . . . . . 29
6.7. Timestamp Option . . . . . . . . . . . . . . . . . . . . 30
6.8. Vendor-Specific Option . . . . . . . . . . . . . . . . . 31
6.9. Registration Lifetime Option . . . . . . . . . . . . . . 32
6.10. Status Option . . . . . . . . . . . . . . . . . . . . . 32
7. Protocol Specification . . . . . . . . . . . . . . . . . . . . 33
7.1. Mobile Access Gateway Operation . . . . . . . . . . . . 33
7.2. Local Mobility Anchor Operation . . . . . . . . . . . . 38
Levkowetz, et al. Expires March 22, 2007 [Page 2]
Internet-Draft The NetLMM Protocol September 2006
8. Data Transport . . . . . . . . . . . . . . . . . . . . . . . . 41
8.1. Forwarding of Unicast Data Packets . . . . . . . . . . . 42
8.2. Forwarding of Multicast Data Packets . . . . . . . . . . 43
8.3. Forwarding of Broadcast Data Packets . . . . . . . . . . 45
9. Protocol Constants and Configuration Variables . . . . . . . . 45
10. Security Considerations . . . . . . . . . . . . . . . . . . . 45
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
14.1. Normative References . . . . . . . . . . . . . . . . . . 47
14.2. Informative References . . . . . . . . . . . . . . . . . 48
Appendix A. TODO (Things that remain to be specified...) . . . . 48
A.1. Montreal DT Meeting Todo List . . . . . . . . . . . . . 49
A.2. Montreal DT Meeting issues list . . . . . . . . . . . . 50
Appendix B. MN-AR Interface considerations . . . . . . . . . . . 51
Appendix C. Issues with omitting the MN Address Setup and
Routing Setup . . . . . . . . . . . . . . . . . . . . 52
Appendix D. Out of scope . . . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54
Intellectual Property and Copyright Statements . . . . . . . . . . 56
Levkowetz, et al. Expires March 22, 2007 [Page 3]
Internet-Draft The NetLMM Protocol September 2006
1. Introduction
This document specifies a protocol that allows nodes to move around
in an access network, attaching to various points of the 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 of
for instance mobile QoS, power management and paging, and management
of changing network conditions in the face of various mobility
events.
The protocol described in this memo is developed in response to the
problem statement for network-based localized mobility [I-D.ietf-
netlmm-nohost-ps] and 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 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 has both some similarities and some clear differences
with 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 changed 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
Levkowetz, et al. Expires March 22, 2007 [Page 4]
Internet-Draft The NetLMM Protocol September 2006
are complementary rather than contradictory. It is quite possible to
conceive of deployments in which mobile IP is used in a wide area to
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 RFC 3753,
"Mobility Related Terminology" [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.
Levkowetz, et al. Expires March 22, 2007 [Page 5]
Internet-Draft The NetLMM Protocol September 2006
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
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.
Levkowetz, et al. Expires March 22, 2007 [Page 6]
Internet-Draft The NetLMM Protocol September 2006
NetLMM Network Prefix
The NetLMM Network Prefix (NNP) is the IPv6 link prefix of the
NetLMM address.
3. Functional Entities
The principal functional entities in a NetLMM infrastructure are the
Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA). An
access network with NetLMM based mobility support may also have other
nodes which support various other functionality such as AAA, routing,
DNS, etc., and the functionality of these nodes may be used by the
MAG and the LMA, but the operation of such additional nodes need not
be changed in any way for the proper operation of the NetLMM
protocol.
+---------+ +---------+
| LMA La1 | (other LMAs) | LMA Lb1 | (other LMAs)
+---------+ +---------+
@ @ @
@ @ @
@ @ @ (other routers)
@ @ @
@ @ @
@ @ @
+-------+ +-------+ +-------+
|MAG Ra1| |MAG Ra2|(other MAGs) |MAG Rb1| (other MAGs)
+-------+ +-------+ +-------+
* * *
* * * * *
* * * * *
* * * * *
* * * * *
* * * (other APs) * * (other APs)
/\ /\ /\ /\ /\
/AP\ /AP\ /AP\ /AP\ /AP\
/ Pa1\ / Pa2\ / Pa3\ / Pb1\ / Pb2\
------ ------ ------ ------ ------
+--+ +--+ +--+ +--+
|MN|----->|MN|----->|MN|----------->|MN|
+--+ +--+ +--+ +--+
Intra-link Local Global
(Layer 2) Mobility Mobility
Mobility
Levkowetz, et al. Expires March 22, 2007 [Page 7]
Internet-Draft The NetLMM Protocol September 2006
Figure 1
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
for maintaining forwarding information for the mobile nodes which
includes a set of mappings to associate mobile nodes by their
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 groups of messages. The first group
provides the basic mobility support, which is the end purpose of the
protocol, while the second group provides necessary support for
maintaining and managing association and connectivity between the
LMAs and MAGs.
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.
However, the same is not true for mobile nodes. As they move around,
and their traffic is routed through various MAGs, their routing state
is handled by one specific LMA; the serving LMA does not change.
4.1. Mobility Management
The NetLMM infrastructure uses 3 messages pairs to manage the
attachment, departure, mobility, and other activities of mobile nodes
within the infrastructure:
Levkowetz, et al. Expires March 22, 2007 [Page 8]
Internet-Draft The NetLMM Protocol September 2006
* LMA Allocation
* Location Registration
* Location Deregistration
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 acknowledges the request
with an Acknowledgement. It is possible that an LMA is configured to
authorize service for any mobile node and in such a situation the LMA
Allocation Request message is not necessary.
When a mobile node connects to the NetLMM infrastructure (see Figure
2), 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.
This specification assumes that a separate subnet prefix is allocated
to each mobile node, and does not cover the case of the whole NetLMM
domain being organized as a multi-link subnet common to all mobile
nodes in the domain.
As a result of the mobile node connecting, the MAG sends a Location
Registration message to the LMA containing its own ID, the LMA's ID
and the Mobile Node's ID. If no error is found, the LMA responds to
the message with a Location Registration Ack message. If the MAG
obtains the NetLMM subnet prefix for the MN first, the MAG transfers
this prefix to the LMA via the Location Registration message. On the
other hand, if the LMA obtains the NetLMM subnet prefix for the MN,
the LMA transfers the prefix to the MAG via the Location Registration
Ack. The LMA creates forwarding state for packets based on the
subnet prefix allocated to the MN. At this point, it is assumed that
the NetLMM prefix is unique to each MN (per-MN subnet); therefore,
the MAG and the LMA can route packets destined for the MN by the
NetLMM subnet prefix. The case for the shared prefix mode requires
additional messages which are not specified in this memo.
The MAG, when receiving a successful Acknowledgement to the Location
Registration message, creates forwarding state for packets destined
to the mobile node, also based on the subnet prefix. In the case of
stateless address configuration being used, the MAG also sends a
router advertisement to the attached mobile.
Levkowetz, et al. Expires March 22, 2007 [Page 9]
Internet-Draft The NetLMM Protocol September 2006
+-----+ +-----+ +-----+ +-----+
| MN | | MAG | | LMA | | PDP |
+-----+ +-----+ +-----+ +-----+
| | | |
* 0.MN Attachment | | |
| | | |
| | |2.LMA Allocation |
| | | (MN ID) |
| | |<- - - - - - - - - |
| | | |
| | |3.Acknowledgement |
| | | (MN ID,Status) |
| | |- - - - - - - - - >|
| | | |
| 4."MN_Access_Network API" | |
| (MN ID,LMA ID) | |
| | | |
| * | |
| | | |
| |5.Location Reg. | |
| |(MN ID,MAG ID,LMA ID) |
| |------------------>| |
| | | |
| |6.Acknowledgement | |
| |(MN ID,MAG ID,LMA ID,Prefix, Status) |
| |<------------------| |
. . . .
. . . .
. . . .
| | | |
|7.Router Advertisement | |
| (Prefix) | | |
|<==================| | |
| | | |
|8.IP Address DAD | | |
| (Address) | | |
|==================>| | |
..... Non-NetLMM signalling
- - - Optional NetLMM signalling
----- NetLMM signalling
===== Link-Layer signalling
Figure 2
When a mobile node then leaves the NetLMM infrastructure, the MAG
sends a Location Deregistration message to the LMA including the
Levkowetz, et al. Expires March 22, 2007 [Page 10]
Internet-Draft The NetLMM Protocol September 2006
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 an
acknowledgement.
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 the associated 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 (see Figure 3),
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 an
acknowledgement to the nMAG that includes the MN ID, the MAG ID, the
LMA ID, and prefix information that the nMAG uses in the router
advertisement for the MN.
Levkowetz, et al. Expires March 22, 2007 [Page 11]
Internet-Draft The NetLMM Protocol September 2006
+-----+ +-------+ +-------+ +-----+
| MN | |old MAG| |new MAG| | LMA |
+-----+ +-------+ +-------+ +-----+
| | | |
* 0.MN Attachment | | |
| | | |
| | 1."MN_Access_Network API" |
| | (MN ID,LMA ID,Prefix) |
| | | |
| | * |
| | | |
| | |2.Location Registration
| | | (MN ID,MAG ID,LMA ID)
| | |------------------>|
| | | |
| | |3.Acknowledgement |
| | | (MN ID,MAG ID,LMA ID,
| | | Prefix,Status) |
| | |<------------------|
| | | |
| | 4.Location Deregistration |
| | (MN ID, MAG ID,LMA ID) |
| |<--------------------------------------|
| | | |
| | 5.Acknowledgement | |
| | (MN ID,MAG ID,LMA ID,Status) |
| |-------------------------------------->|
| | | |
Figure 3
4.2. Setup and Node Association
The NetLMM infrastructure uses 3 message pairs to establish and
maintain associations between the MAGs and the LMAs:
* Association Request / Ack
* Disassociation Request / Ack
* Heartbeat / Ack
A MAG associates itself with an LMA by sending an Association Request
message (see Figure 4) that includes its MAG ID and the supported
data forwarding modes (such as IPv6-in-IPv6) [RFC2473]. In response
the LMA creates an association with the MAG and populates state
information about the association. The LMA responds, providing an
agreed upon data forwarding mode to the MAG. The MAG can undo the
relationship with the LMA through sending a Disassociation Request,
Levkowetz, et al. Expires March 22, 2007 [Page 12]
Internet-Draft The NetLMM Protocol September 2006
to which the LMA responds with an acknowledgement. Heartbeat
messages MAY be 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.
+-----+ +-----+
| MAG | | LMA |
+-----+ +-----+
| |
| Association Request |
| (MAG ID, LMA ID, DataTransport) |
|---------------------------------------->|
| |
| Acknowledgement |
| (MAG ID,LMA ID, DataTransport, Status) |
|<----------------------------------------|
. .
. .
. (Regular operation message flows, .
. optionally Heartbeats) .
. .
| Disssociation Request |
| (MAG ID, LMA ID) |
|---------------------------------------->|
| |
| Acknowledgement |
| (MAG ID,LMA ID, Status) |
|<----------------------------------------|
Figure 4
4.3. Message Transport
The NetLMM control messages defined in this document are carried by
the User Datagram Protocol RFC 768 [RFC0768] using well known port
number NETLMM_UDP_PORT (TBD -- assigned by IANA -- please replace
'NETLMM_UDP_PORT with the actual port number here and below).
Any implementation of the NetLMM protocol MUST include support for
IPsec protected transport, using Encapsulating Security Payload
[RFC4303] in transport mode. IPsec SHOULD be used unless other means
of protecting the NetLMM control signalling provide enough security
within the NETLMM domain. If IPsec is used, it MUST use a non-NULL
authentication algorithm to provide data origin authentication.
The message sender SHOULD include a non-zero UDP Checksum. The
Levkowetz, et al. Expires March 22, 2007 [Page 13]
Internet-Draft The NetLMM Protocol September 2006
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: NETLMM_UDP_PORT
When the recipient of a NetLMM message sends an Acknowledgement, the
following UDP ports MUST be used:
* Source Port: variable
* Destination Port: Copied from the source port of the received
message.
4.3.1. Message Retransmission
To ensure reliable delivery of control messages, NetLMM requires a
positive acknowledgement from the receiver and retransmission by the
sender for an unacknowledged message.
Each request message has a corresponding acknowledgement message,
which must be used to acknowledge receipt of the request message. In
the acknowledgements, NetLMM entities can append message options
(defined in Section 6) according to the protocol operation (Section 4
and Section 5).
NetLMM entities maintain a retransmission timer T-rtx and MUST
support the basic back-off scheme described below for the
retransmission timeout (RTO).
After a NetLMM control message has been sent, the NetLMM entity
initializes T-rtx with an RTO value of RTO_INIT. If the
acknowledgement of the associated NetLMM control message is received
before T-rtx has expired, T-rtx is stopped. If T-rtx expires before
the acknowledgement is received, the NetLMM entity retransmits the
packet using the same sequence number as for the original packet.
For each retransmission, the NetLMM entity should set the new RTO
value to twice the previous RTO duration (e.g. new_RTO = 2 *
previous_RTO). The RTO value SHOULD not exceed the limit of RTO_MAX
seconds. The value for RTO_INIT and RTO_MAX should be configurable,
with a resolution better than 1 second (such as 1 ms, for instance).
In case a NetLMM entity has multiple associations, an individual RTO
Levkowetz, et al. Expires March 22, 2007 [Page 14]
Internet-Draft The NetLMM Protocol September 2006
must be maintained for each associated NetLMM peer entity.
Optionally, NetLMM entities MAY use more enhanced schemes to
dynamically re-calculate and adjust the RTO. As an example, the RTO
could be derived from periodic round trip time (RTT) measurements and
RTT deviations, as utilized by the Stream Control Transport Protocol
(SCTP) [RFC2960]. If no enhanced approach for RTO derivation is
supported, NetLMM entities MUST use the basic approach as described
above.
Heartbeat messages are not considered NetLMM control messages in the
context of this section; they are handled according to Section 5.7.1
and are not re-transmitted.
The default values for RTO_INIT and RTO_MAX are defined as follows:
RTO_INIT = 1 second
RTO_MAX = 64 seconds
5. Message Format and Message Types
5.1. Message Format
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
8-octet aligned, with a Type field divided into two parts; Option
Type and Option Sub-Type. All option payloads whose length is not a
unit of 8 octets must be padded to the correct alignment.
All NetLMM messages start with the following common header.
Parameters for each message are contained in the option format (see
following sections).
Levkowetz, et al. Expires March 22, 2007 [Page 15]
Internet-Draft The NetLMM Protocol September 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 | Type | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Src ID Option .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Dst ID Option .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
An 8-bit number, indicating the NetLMM protocol version. The
version of the NetLMM protocol specified in this document is 1.
Type
8-bit value indicating the NetLMM message type. The message types
are specified below, in following sections.
Sequence Number
16-bit length, used to ensure the correspondence of request and
acknowledgement messages 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/Acknowledgement 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
32-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
Levkowetz, et al. Expires March 22, 2007 [Page 16]
Internet-Draft The NetLMM Protocol September 2006
Src ID Option
An ID Option (Section 6.3) giving the ID of the source of the
message
Dst ID Option
An ID Option giving the ID of the destination of the message.
5.2. LMA Allocation Request
Request Message Type: 0
Required options: Sender ID, LMA ID, MN ID
Acknowledgement Message Type: 64
Required options: Status
Implementation: Mandatory
Use: Optional
The LMA Allocation Request message MAY be used to allocate an LMA for
the MN that is initially attached to the network so that subsequent
Location Registration messages from MAGs to which the MN is attached
can be validated. 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.
An Acknowledgement of the The LMA Allocation message is sent from the
LMA to the source of the LMA Allocation Request message to indicate
the status of the request (success or error code).
5.3. Location Registration
Request Message Type: 1
Required options: MAG ID, LMA ID, MN ID
Acknowledgement Message Type: 65
Required options: MAG ID, LMA ID, MN ID, Status
Implementation: Mandatory
Use: Mandatory
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. The mobility state of the MN, in the MAG and LMA, is
created or updated using this message.
The Location Registration Acknowledgement is sent from the LMA to the
Levkowetz, et al. Expires March 22, 2007 [Page 17]
Internet-Draft The NetLMM Protocol September 2006
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.4. Location Deregistration
Request Message Type: 2
Required options: MAG ID, LMA ID, MN ID
Acknowledgement Message Type: 66
Required options: MAG ID, LMA ID, MN ID, Status
Implementation: Mandatory
Use: Mandatory
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
is at a new location. This message contains the MN ID, MAG ID, LMA
ID and may contain a Deregistration Timeout option, providing a
delayed de-registration.
An Acknowledgement message is sent back to the source of the Location
Deregistration message to acknowledge the receipt of the Location
Deregistration message. This message may contain the applied de-
registration delay time.
5.5. Association Request
Request Message Type: 16
Required options: MAG ID, LMA ID, Data Transport
Acknowledgement Message Type: 80
Required options: MAG ID, LMA ID, Data Transport, Status
Implementation: Mandatory
Use: Mandatory
The Association Request is used to set up the control and data plane
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. 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
Levkowetz, et al. Expires March 22, 2007 [Page 18]
Internet-Draft The NetLMM Protocol September 2006
unidirectional tunnels in opposite directions.
An acknowledgement to the the Associate Request message is sent from
the LMA to the MAG to indicate the status of the request (success or
error code). If the request is successful, the receiver of the
request also sends back one choice from each set of capabilities
specified in the Association Request, indicating for each capability
the method which will be used by the two nodes.
5.6. Disassociation Request
Request Message Type: 17
Required options: MAG ID, LMA ID
Acknowledgement Message Type: 81
Required options: MAG ID, LMA ID, Status
Implementation: Mandatory
Use: Mandatory
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.
An acknowledgement of the the Disassociate Request message is sent
from the LMN to the MAG or vice versa to indicate the status of the
request (success or error code).
5.7. Heartbeat
Request Message Type: 18
Required options: MAG ID, LMA ID
Acknowledgement Message Type: 82
Required options: MAG ID, LMA ID
Implementation: Mandatory
Use: Optional
The Heartbeat message is sent from the MAG to LMA or vice versa to
obtain the connectivity status. This message contains the MAG ID and
the LMA ID. It MAY contain other options, such as a Timestamp
Option. Contrary to the case for other NetLMM messages, Heartbeat
messages are never re-transmitted.
The Heartbeat Ack is sent back from the node that received the
Heartbeat message to its peer. This message contains the MAG ID and
the LMA ID. It MAY contain other options, such as a Timestamp
Levkowetz, et al. Expires March 22, 2007 [Page 19]
Internet-Draft The NetLMM Protocol September 2006
Option.
5.7.1. Heartbeat Handling
If used, Heartbeats are sent at a fixed, configurable rate,
determined by the HEARTBEAT_SEND_INTERVAL, and a history is kept for
the last HEARTBEAT_HISTORY_SIZE heartbeats. The history has a number
of slots (equal to HEARTBEAT_HISTORY_SIZE), and each slots holds the
Sequence Number of the Heartbeat message sent in that time-slot, the
time at which the Heartbeat message was sent, and the number of
Heartbeat Acknowledgements that were received during that time-slot.
The following algorithm is used to detect connectivity and load
problems:
Each time a Heartbeat message is sent, the message sequence number is
registered in the heartbeat history. A count is also made of the
number of received Heartbeat Acknowledgements recorded in the
heartbeat history. Except during startup, when the number of
heartbeats recorded in the history is less than
HEARTBEAT_HISTORY_SIZE, the heartbeat loss ratio is calculated as
(heartbeats_sent - received_acks) / (hearbeats_sent). If the ratio
is larger than a configurable value HEARTBEAT_LOSS_THRESHOLD, an
alarm should be raised, and the event MUST be logged. (The heartbeat
loss rate can be derived from the heartbeat loss ratio as loss_rate =
loss_ratio / HEARTBEAT_SEND_INTERVAL).
When a Heartbeat message is received by the destination node, it MUST
respond with a Heartbeat Ack with the same Sequence Number as the
received Heartbeat message.
When a Heartbeat Ack is received, the count of received
acknowledgements is increased for the current history time-slot and
the time since the corresponding Heartbeat message was sent is
calculated. If the corresponding heartbeat's Sequence Number is no
longer on record in the heartbeat history, the value
(HEARTBEAT_SEND_INTERVAL * HEARTBEAT_HISTORY_SIZE is used). If this
calculated delay is larger than a configurable value
HEARTBEAT_DELAY_THRESHOLD, an alarm should be raised, and the event
MUST be logged.
The Heartbeat loss rate is primarily an indication of the quality of
the communication link, while the Heartbeat delay is primarily an
indication of the load of the peer. A sudden overload situation can
also manifest as an apparent sudden in crease in loss rate, but in
the absence of link problems, a steady state high load situation will
show an acceptable loss rate, but a large heartbeat delay.
Levkowetz, et al. Expires March 22, 2007 [Page 20]
Internet-Draft The NetLMM Protocol September 2006
An implementation of the NetLMM protocol may adjust its resend
timeout value (RTO) based on both the heartbeat loss rate and the
average heartbeat delay. For instance, a RTO which is lower than the
average heartbeat delay will result in unnecessary re-sends and added
load in a high-load situation.
5.8. Acknowledgements
An acknowledgement MUST be sent in response to any non-
Acknowledgement message. It is sent from the node that received the
initial message to the originator of that message. It indicates that
the initial message has been received, and also carries a status
value which indicates the result of the operation requested by the
initial message.
The Sequence Number field of an acknowledgement message MUST be set
to the same value as the Sequence Number of the message which it
acknowledges, in order to support the message re-send mechanism
described in Section 4.3.
The acknowledgement message MUST contain at least the Status Option
(Section 6.10) except in the case of the Heartbeat Acknowledgement,
but may also contain other options which are appropriate in response
to the initial message.
5.9. Message Status Codes
The status codes used by the NetLMM protocol are used when
acknowledging a message, to indicate the result of processing the
associated request message. The status code is carried in the Status
Option (Section 6.10).
The status codes are allocated in ranges, depending on their usage.
The defined ranges are as follows:
0 - 63: Generic Status
This range is used for status codes which are of a generic nature,
and not specific to MAG or LMA.
64 - 127: LMA-specific Status
This range is used for status codes which are specific to the
LMAs.
128 - 191: MAG-Specific Status
This range is used for status codes which are specific to the
LMAs.
Levkowetz, et al. Expires March 22, 2007 [Page 21]
Internet-Draft The NetLMM Protocol September 2006
192 - 255: Reserved
This range is reserved for future use.
The following values are defined by this document:
0: Not Applicable (N/A)
The status code is not applicable for the message.
1: Success
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: Invalid Message
The NetLMM Request message was invalid or malformed.
62: Vendor-Specific Status (Generic)
For use with vendor-specific messages. Additional status
detail may be provided for instance in vendor-specific options.
63: Experimental Status (Generic)
For use during experimental implementation of new protocol
features, according to "Assigning Experimental and Testing
Numbers Considered Useful" [RFC3692]
64: Unauthorized MN
Used by the LMA in response to Location Registration, to notify
the MAG of the MN not being authorized for service.
65: Duplicate Prefix
Used by the LMA when an Location Registration contains an IP
address or prefix that is duplicated in the same NetLMM domain.
The specific invalid addresses/prefixes MUST be specified in
Address Options.
66: Invalid Prefix
Used by the LMA when an Location Registration contains an IP
address or prefix that is invalid in the same NetLMM domain.
The specific invalid addresses/prefixes MUST be specified in
Address Options.
Levkowetz, et al. Expires March 22, 2007 [Page 22]
Internet-Draft The NetLMM Protocol September 2006
67: Over IP Address Limit
Used by the LMA on receipt of a Location Registration message,
if the maximum number of IP addresses or prefixes allowed for a
MN has been exceeded. The specific addresses/prefixes which
were disallowed MUST be specified in Address Options.
68: Invalid Tunnelling Method
The proposed tunnel method is not supported or unavailable.
69: Already Associated
The LMA already had the requesting MAG listed as associated.
126: Vendor-Specific Status (LMA-specific)
For use with vendor-specific messages. Additional status
detail may be provided for instance in vendor-specific options.
127: Experimental Status (LMA-specific)
For use during experimental implementation of new protocol
features, according to RFC 3692.
190: Vendor-Specific Status (MAG-Specific)
For use with vendor-specific messages. Additional status
detail may be provided for instance in vendor-specific options.
191: Experimental Status (MAG-specific)
For use during experimental implementation of new protocol
features, according to RFC 3692.
6. Option Format and Option Types
6.1. Option Format
NetLMM defines a general extension mechanism using options to allow
optional information to be carried in the control messages. The
options are encoded in a Type-Length-Value format, and are described
in detail in the following. 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.
Format:
Levkowetz, et al. Expires March 22, 2007 [Page 23]
Internet-Draft The NetLMM Protocol September 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option-specific data |
. (up to option length) .
. .
. .
. . . .
Option Type
This field identifies the particular type of option serving a
specified function.
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.
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.
6.2. Option Alignment
Options are always aligned to start on an 8-octet aligned boundary,
relative to the start of the message header. The first 4 octets of
an option has a fixed format, giving the Option type, sub-type, and
length in octets. When assembling a message, for an option which has
a length in octets which is not a multiple of 8, zero octets are
added after the option up to the next 8-octet-aligned boundary. The
option length is not adjusted to include the padding. When parsing
the options of a message, any octets between the end of one option
and the next 8-octet-aligned boundary are discarded.
In other words, if we include the padding in the figure showing
Levkowetz, et al. Expires March 22, 2007 [Page 24]
Internet-Draft The NetLMM Protocol September 2006
option field layout, we get the following for an option of total
length N*8+3. (Total length N*8+3 implies that the Length field has
the value (N*8+3)-4, as the length field indicates the length of the
option data, i.e., does not include the first 4 octets):
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option-specific data |
. (up to option length) .
. .
. +-+-+-+-+-+-+-+-+
| | Padding... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.3. 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].
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... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Levkowetz, et al. Expires March 22, 2007 [Page 25]
Internet-Draft The NetLMM Protocol September 2006
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
1: LMA ID
2: MAG ID
Length
The 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.
6.4. Prefix Option
This option defines the address or prefix which has been allocated or
delegated to a mobile node. If the address prefix length is the same
as the full address length, it describes a single address, otherwise
it describes a prefix delegated to the MN. The NetLMM address can be
both IPv4 and IPv6.
Levkowetz, et al. Expires March 22, 2007 [Page 26]
Internet-Draft The NetLMM Protocol September 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subnet Prefix | Address Prefix| 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 the Address 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.
Length
The length of the option in octets, excluding the Type, Sub-Type
and Length fields.
Subnet Prefix
The number of leadings bits in the Address that are valid as a
subnet prefix.
Address Prefix
Variable. The value indicates the prefix length of the prefix or
address delegated or allocated to the mobile node. If the prefix
length is equal to the full address length, the option describes
an address allocation, otherwise it describes a prefix delegation.
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.
Levkowetz, et al. Expires March 22, 2007 [Page 27]
Internet-Draft The NetLMM Protocol September 2006
Address:
If the Option Sub-Type is 0, the value is an IPv6 address, while
if the type is 1, the value is an IPv4 address.
6.5. Data Transport Option
This option contains data transport methods capabilities that the MAG
or LMA has. This option is used by Association Request message and
Acknowledgement 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
[RFC2473], 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
2
Option Sub-Type
0
Length
The 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
Indicates the data transport methods available at the sender in
the case of the Association Request message. The methods are
listed in order of preference. In the case of the Association
Request Acknowledgement, only one method would be listed,
indicating the chosen data transport method.
Levkowetz, et al. Expires March 22, 2007 [Page 28]
Internet-Draft The NetLMM Protocol September 2006
The following values are defined for the data transport method
field by this memo:
0: IPv6-in-IPv6
1: GRE
2: IPv4-in-IPv6
6.6. Deregistration Timeout Option
This option indicates the length, in milliseconds, to keep the
forwarding state of a given MN active after a handover. When used,
this option is included in the Location Deregistration message and
its acknowledgement. The timeout time in the Location Deregistration
Ack is copied from that given in the Timeout Option of the Location
Deregistration. If the MAG can not keep the MN state alive as long
as the LMA has requested for some reason, the MAG can indicate the
preferred timeout time and return an error code instead of copying
the 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeout Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
3
Option Sub-Type
0
Length
4. The length of the option in octets, excluding the Type, Sub-
Type and Length fields.
Timeout Time
Indicates the preferred delay before deleting the MN forwarding
state from the previous MAG during handover. The value is in
milliseconds.
Levkowetz, et al. Expires March 22, 2007 [Page 29]
Internet-Draft The NetLMM Protocol September 2006
6.7. Timestamp Option
This option contains the timestamp value in the format of an NTP
timestamp (RFC 4330, Section 3 [RFC4330]), and records the time when
the message is sent. This option can be used to detect an overtaking
message in a race condition by comparing the timestamp values of
messages. Especially during handovers, 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 a reliable
time distribution method, such as NTP or GPS time synchronization,
with sufficient accuracy to support fast moving MNs.
LMA and MAG nodes SHOULD support and MAY use message timestamps. To
resolve race conditions, in particular during handover, and for
message synchronization beyond the scope of a particular MAG, the
timestamp option may be attached to the following messages:
* Location Registration
* Location Deregistration
Acknowledgements of these messages should not carry a timestamp
option.
Heartbeat messages and acknowledgements may optionally contain a
timestamp option for informational or diagnostic purposes.
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
Option Sub-Type
0
Levkowetz, et al. Expires March 22, 2007 [Page 30]
Internet-Draft The NetLMM Protocol September 2006
Length
8. The length of the option in octets, excluding the Type, Sub-
Type and Length fields.
Timestamp
A timestamp in the 64 bit format defined for NTP timestamps
[RFC4330].
6.8. 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
0.
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
The length of the option in octets, excluding the Type, Sub-Type
and Length fields.
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.
Levkowetz, et al. Expires March 22, 2007 [Page 31]
Internet-Draft The NetLMM Protocol September 2006
Value
Variable. Details defined by individual Vendors / Organizations.
6.9. Registration Lifetime Option
This option MAY be used to indicate a limited lifetime for the state
created as a result of Location Registration (Section 5.3) messages.
If no Registration Lifetime Option is used, the lifetime of the state
is to be taken as "Infinite", but with the reservation that in cases
where a node experiences an impending lack of resources, the Least
Recently Used (LRU) states may be removed (garbage collected), to
recover resources for continued operation.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
6
Option Sub-Type
0
Length
4. The length of the option in octets, excluding the Type, Sub-
Type and Length fields.
Lifetime
The lifetime in seconds, with a value between 1 and 2^32 - 2. The
values 0 and 2^32 - 1 are reserved, and may not be used.
6.10. Status Option
This option MUST be used in Acknowledgements to indicate the status
result of the acknowledged message.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Levkowetz, et al. Expires March 22, 2007 [Page 32]
Internet-Draft The NetLMM Protocol September 2006
Option Type
7
Option Sub-Type
0
Length
8. The length of the option in octets, excluding the Type, Sub-
Type and Length fields.
Status
An 8-bit number, which indicates the Status result of handling the
acknowledged message. Individual status codes are defined in
Section 5.9.
Reserved
24-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
7. Protocol Specification
7.1. Mobile Access Gateway Operation
7.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:
* The MN ID of the attached MN. This identifier is acquired during
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 or address prefixes of an attached
MN. Each IP address or prefix is acquired from an LMA through the
Location Registration Acknowledgement or by 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.
* The LMA ID of the LMA serving an attached MN. The serving LMA and
its LMA ID is acquired from the LMA selection policy, which is out
of scope of this specification.
Levkowetz, et al. Expires March 22, 2007 [Page 33]
Internet-Draft The NetLMM Protocol September 2006
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 also indicates the forwarding approach which has been
selected for an association between the MAG and a particular LMA.
During the association procedure, an LMA selects a forwarding
approach from the MAG's full set of forwarding capabilities. For
this the MAG appends a Data Transport option, which indicates its
supported forwarding capabilities in decreasing order of preference,
to the Association message. The Data Transport option received back
from the LMA in the resulting Association Acknowledgement indicates a
single, selected forwarding approach in one Data Transport Method
field.
The LMA List conceptually contains the following fields for each LMA
entry:
* The LMA ID of the LMA.
* One or more IP address(es) of the LMA. The LMA's IP address
information is acquired 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.
* The 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.
Each MAG MAY 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:
* The 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.
Levkowetz, et al. Expires March 22, 2007 [Page 34]
Internet-Draft The NetLMM Protocol September 2006
7.1.2. Processing NetLMM Headers
* The Type field MUST have a known value (Section 5.1). Otherwise,
the receiving node MUST discard the message and respond with an
Error message with Status field set to "Invalid Message" ).
7.1.3. Processing NetLMM Messages
7.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
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 Acknowledgement from the peer LMA with status 1,
"Success". 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 acknowledgement. The MAG MUST also
update the forwarding method to the one indicated in the
acknowledgement.
Levkowetz, et al. Expires March 22, 2007 [Page 35]
Internet-Draft The NetLMM Protocol September 2006
7.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 between
MAG and 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 an acknowledgement 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
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 an acknowledgement with status 1, "Success". As in all
NetLMM messages, the MAG MUST include the ID option with its
identity.
7.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 event 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 an Location Registration Acknowledgement message from the
LMA with Status 1, "Success". This message also includes a NetLMM
Network Prefix that the MAG MUST use for any mechanism it provides
for MN address allocation, e.g., when building a Router Advertisement
Levkowetz, et al. Expires March 22, 2007 [Page 36]
Internet-Draft The NetLMM Protocol September 2006
if IPv6 stateless address configuration is used. (See [I-D.ietf-
netlmm-mn-ar-if] for a more detailed description of this case).
7.1.3.4. 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
with respect to 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 to as a MN_Access_Network API event carries the MN ID and
the LMA ID. As mentioned above, this API event can be for example
based on an AAA exchange.
After receiving this API event, the MAG performs the same procedure
as described for network access (see section Section 7.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 and receives
the Acknowledgement of the Location Registration message, which
includes the NetLMM prefix to be used by the MN.
7.1.3.5. 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 an
acknowledgement of the Location Deregistration message to the LMA
with Status 1, "Success".
In case the Location Deregistration contains a Deregistration Timeout
option, 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 timeout cannot be greater than the one
suggested by the LMA and MUST be sent back to the LMA in the Location
Deregistration message Acknowledgement.
7.1.3.6. 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
registration, this is a MUST, otherwise it can be a SHOULD) send a
Location Deregistration message with an ID option containing the MN
ID. After receiving the Acknowledgement of the Location
Deregistration message, the MAG MUST remove any mobility and
forwarding state in its Routing Cache related to that MN.
Levkowetz, et al. Expires March 22, 2007 [Page 37]
Internet-Draft The NetLMM Protocol September 2006
7.2. Local Mobility Anchor Operation
7.2.1. Conceptual Data Structures
Each LMA MUST maintain a NetLMM Routing Cache and a MAG List.
Each LMA Routing Cache entry conceptually contains the following
fields for each MN:
* The MN ID of the registered MN. This Identifier is acquired
through the Location Registration message, which registers an
attached MN. Optionally, the MN ID is acquired though the LMA
Allocation message beforehand, which could enable service
authorization for this particular MN ID at the LMA.
* The MAG ID of the registered MN's serving MAG. This identifier is
acquired 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 a 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 or address prefixes of a
registered MN. Each IP address or prefix is allocated by the LMA
or on request of the LMA. The MAG is informed about the allocated
address or prefix in the Location Registration Ack message.
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 towards all or a subset of associated MAGs.
The MAG List also indicates the forwarding approach which has been
selected for the association between the LMA and a particular MAG.
During the association procedure, an LMA selects a forwarding
approach from the MAG's full set of forwarding capabilities. The LMA
receives a MAG's full set of forwarding capabilities in decreasing
order of preferences in a Data Transport option with the Association
message. The LMA could selects the first forwarding approach which
suits the LMA's forwarding capabilities, starting with the MAG's most
preferable forwarding approach as indicated in the first Data
Transport Method field of the Data Transport option. Other selection
schemes are allowed and optional. The LMA indicates the selected
forwarding approach back to the MAG in the Association
Acknowledgement, which carries a Data Transport option with a single
Data Transport Method field.
Levkowetz, et al. Expires March 22, 2007 [Page 38]
Internet-Draft The NetLMM Protocol September 2006
The MAG List conceptually contains the following fields for each
associated MAG:
* The MAG ID of the associated MAG.
* One or more IP address(es) of the associated MAG. The MAG's IP
address information is acquired through the Associate message.
* The forwarding capabilities of the associated MAG. This
capability list is acquired from a particular MAG through the
Associate message. From the list of supported forwarding
approaches, the LMA enters only the approaches to the capabilities
which are supported by the LMA.
* The forwarding setting for the associated MAG. This field is
needed in case the LMA configures a single forwarding approach per
MAG association.
7.2.2. Processing NetLMM Headers
All NetLMM local mobility anchors MUST observe the rules described in
Section 7.1.2 when processing NetLMM Headers.
7.2.3. Processing NetLMM Messages
7.2.3.1. Association Procedure
When a LMA receives an Association Request message, it MUST look up
in its MAG list 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 acknowledgement to the
MAG with status "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. We should 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 methods proposed by the MAG or MAY indicate a
specific method in the Acknowledgement. After creating the entry,
the LMA MUST send an acknowledgement with STATUS value 1 ("Success")
with the content described below.
The Acknowledgement to the received Association Request message MUST
Levkowetz, et al. Expires March 22, 2007 [Page 39]
Internet-Draft The NetLMM Protocol September 2006
include:
* the LMA ID 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 MAG ID as received from the requesting MAG in the Association
Request message.
* the Data Transport option with the selected data transport method.
The LMA MUST select one forwarding approach from the list of
capabilities as received in the Association Request message.
* the Status option, indicating the result of processing the
Association Request message.
7.2.3.2. Disassociation Procedure
In case the Disassociate procedure is initiated by the MAG, the LMA
MUST validate any Disassociation Request message it receives. If it
is correct, it MUST delete the related entry in its MAG List and send
an Acknowledgement 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 an acknowledgement with status 1, "Success", the LMA MUST
delete the correspondent entry in its MAG List.
7.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 7.2.3.4.
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.
After creating the entry, it MUST send an acknowledgement of the
Location Registration message, with status 1, "Success", including
three ID options (MN ID, LMA ID, MAG ID) and the NetLMM prefix in a
NetLMM Address option. The NetLMM prefix MUST be used by the MAG for
Levkowetz, et al. Expires March 22, 2007 [Page 40]
Internet-Draft The NetLMM Protocol September 2006
any mechanism it provides for MN address allocation, e.g., when
building a Router Advertisement if IPv6 stateless address
configuration is used. (See [I-D.ietf-netlmm-mn-ar-if] for a more
detailed description of this case).
In case the Location Registration is not valid or the registration
procedure cannot be completed successfully, the LMA MUST send a
Acknowledgement with an appropriate Status value.
7.2.3.4. 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 7.2.3.3). If an entry is already present in the Routing
Cache, a handover has occurred. In either case, the LMA MUST send
back an Acknowledgement of the Location Registration message with
Status value set to 1, "Success", including a Prefix option which
specifies the NetLMM prefix to be sent to the MN.
7.2.3.5. Resource Revocation
There are cases (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 Deregistration Timeout option specifying the remaining
time to keep the state of the MN in the MAG.
The revocation procedure terminates when the LMA receives an
Acknowledgement of the Resource Revocation message with status 1,
"Success".
7.2.3.6. 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 an Acknowledgement of the Location Deregistration
message with status 1, "Success", including the MN ID, the MAG ID and
the LMA ID.
8. Data Transport
Levkowetz, et al. Expires March 22, 2007 [Page 41]
Internet-Draft The NetLMM Protocol September 2006
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 1 of the NetLMM protocol
implemented, MUST support IPv6-in-IPv6 encapsulation [RFC2473] to
tunnel data packets between an LMA node and an associated MAG node.
Support of other forwarding approaches are for future extensions.
8.1. Forwarding of Unicast Data Packets
8.1.1. Handling of hop limit field in IPv6 data packets
According to the NetLMM default mechanism for forwarding data packets
between a particular LMA and a 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 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, once at the LMA and once
at the MAG.
8.1.2. IPv6-in-IPv6 tunnel
LMA and MAG nodes MUST support IPv6-in-IPv6 encapsulation according
to RFC 2473 [RFC2473] for forwarding 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
Levkowetz, et al. Expires March 22, 2007 [Page 42]
Internet-Draft The NetLMM Protocol September 2006
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.
8.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 [RFC2473] 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.
8.2. Forwarding of Multicast Data Packets
8.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. (See [I-D.ietf-netlmm-mn-ar-if]).
8.2.2. IP Multicast
The following options have been identified to support IP multicast
within a NetLMM domain.
Native mode: This option 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.
Levkowetz, et al. Expires March 22, 2007 [Page 43]
Internet-Draft The NetLMM Protocol September 2006
Tunnel mode: This option implies that MAG nodes and LMA nodes are
both multicast-enabled routers and the IP multicast traffic is
tunnelled via the two NetLMM nodes. IP Multicast protocol is used
on the tunnel between the MAG nodes and LMA nodes to set up the
multicast forwarding path.
MAG nodes must coordinate multicast listeners according to IGMP
operation [RFC3376] and communicate with other multicast-enabled
routers using IP Multicast protocol (e.g. PIM, based on RFC 2362).
The MAG nodes send multicast control messages in the tunnel or on the
connected interface to reach the LMA nodes or other routers,
respectively. This establishes the multicast forwarding path for
directing multicast packets to the listeners. An example of a IP
multicast join procedure is illustrated in Figure 5. By default, the
native mode of operation is REQUIRED.
+--+ +---+ +---+ +--+
|MN| |MAG| |LMA| |MR|
+--+ +---+ +---+ +--+
| | | |
| | | |
|-IGMP Report->| | |
| |====PIM Join===>| |
| | |----PIM Join----.>|
/ / / /
/ / / /
|<-------------|<===============|<-----------------|<--MC Data
| | | |
Figure 5: Example of IP multicast join procedure for the Tunnel Mode.
The MR is a multicast-enabled router between the multicast source and
the LMA node.
The mobile node may be a multicast sender. The MAG nodes allow
multicast packets to be received on the interface of the mobile node
by successfully passing any Reverse Path Forwarding (RPF) check. All
multicast packets that are sourced from the mobile node are tunneled
to the LMA nodes. The RPF check on the LMA nodes should allow these
packets to be received on the tunnel as well. The multicast packets
are forwarded by the LMA nodes based on the multicast forwarding
table, set up by IP Multicast protocol used among the routers. An
example of a IP multicast source sending multicast packet to the
group is illustrated in Figure 6.
Levkowetz, et al. Expires March 22, 2007 [Page 44]
Internet-Draft The NetLMM Protocol September 2006
+--+ +---+ +---+ +--+
|MN| |MAG| |LMA| |MR|
+--+ +---+ +---+ +--+
| | | |
| | |<----PIM Join-----|
/ / / /
/ / / /
| | | forward to group |
|-- MC Data--.>|===============>|----------------.>|--.>
| | | |
Figure 6: Example of a mobile node sourcing multicast packets to the
group.
8.3. Forwarding of Broadcast Data Packets
Version 1 of the NetLMM protocol specification does not consider
forwarding of broadcast data packets.
9. Protocol Constants and Configuration Variables
10. 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 a MAG and associate with an
LMA. This in itself may not create any harm if subsequent
messages are authenticated. But it does allow 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 a MAG and send a location
registration message to an 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
traffic. This attack may be detected by MAG-1 when it receives
the Location Deregistration message from LMA while the MN is
still attached. The detection of the attack depends on the
Levkowetz, et al. Expires March 22, 2007 [Page 45]
Internet-Draft The NetLMM Protocol September 2006
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, if an MN Address Setup
messages are used and one 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, which 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. If this is done, 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 need to be used to protect the signalling messages.
Anomalous events should be logged. [TBD: Add examples 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].
11. IANA Considerations
12. Contributors
This contribution is a joint effort of the NetLMM design team of the
Levkowetz, et al. Expires March 22, 2007 [Page 46]
Internet-Draft The NetLMM Protocol September 2006
NetLMM WG. The members include Kent Leung, Gerardo Giaretta, Phil
Roberts, Marco Liebsch, Katsutoshi Nishida, Hidetoshi Yokota, Henrik
Levkowetz, and Mohan Parthasarathy.
13. Acknowledgments
14. References
14.1. Normative References
[I-D.ietf-ipv6-2461bis]
Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
draft-ietf-ipv6-2461bis-08 (work in progress),
September 2006.
[I-D.ietf-netlmm-mn-ar-if]
Laganier, J., "Network-based Localized Mobility Management
Interface between Mobile Node and Access Router",
draft-ietf-netlmm-mn-ar-if-01 (work in progress),
June 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-04
(work in progress), August 2006.
[I-D.ietf-netlmm-threats]
Kempf, J. and C. Vogt, "Security Threats to Network-Based
Localized Mobility Management",
draft-ietf-netlmm-threats-04 (work in progress),
September 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.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
Levkowetz, et al. Expires March 22, 2007 [Page 47]
Internet-Draft The NetLMM Protocol September 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.
14.2. Informative References
[ENTERPRISE-NUM]
IANA, "IANA Enterprise Numbers Registry"", 2006.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004.
Appendix A. TODO (Things that remain to be specified...)
Levkowetz, et al. Expires March 22, 2007 [Page 48]
Internet-Draft The NetLMM Protocol September 2006
A.1. Montreal DT Meeting Todo List
a. ***Done*** Describe the re-send mechanism for control messages,
in order to provide reliable delivery.
==> Marco look at SCTP and DCCP
b. ***Later*** Add an "LMA Announce message" which can be multicast
from a newly connected LMA to trigger listening MAGs to send it
Association Requests.
==> Not included in base spec.
c. Add the capability to do bulk MN de-registrations and possibly
registrations.
==> Henrik write up per-LMA ID, per-MAG ID de-registration sub-
type. Also query Ericsson internally about exact needs.
==> Also add text to each message indicating whether it can be
used with multiple entities (often MN IDs)
d. 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.
==> Phil will review for prefix
e. ***Done*** Add reserved status ranges (Section 7.1.1) for vendor-
specific status, LMA status?, MAG status?.
==> Single number for vendor-specific status, ranges for LMA and
MAG status codes -- Henrik
f. ***Done*** Add experimental message, option and status values, in
accordance with RFC 4064.
==> Henrik
g. ***Skip*** Add a Heartbeat Sequence Number Option, to hold
heartbeat-specific sequence numbers needed by algorithms for
reacting to missed heartbeats. Write up suggested algorithm.
==> Henrik.
h. Make sure the use of the identity / locator split paradigm is
consistent and workable throughout the document. Cover
resolution of ID to locator.
==> [Later?] Henrik write up a proposal. Gerardo writes up a
proposal.
i. ***Done*** 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 Acknowledgement.
==> The MAG sends a prioritized list of capabilities, the LMA
Levkowetz, et al. Expires March 22, 2007 [Page 49]
Internet-Draft The NetLMM Protocol September 2006
chooses one and sends that one back. -- Marco
j. ***Done*** Add message and signalling optimization according to
Section 5.12.
==> Wait with this till we have a clear defined functionality.
k. ***Leave*** Maybe change the range-based skippable or non-
skippable nature of Options to be indicated by a bit instead?
==> Leave as-is.
l. ***Done*** Point out somewhere that although a NetLMM Domain may
have multiple LMAs, an MN is always served by the same LMA once
an LMA has been assigned.
==> Phil adds text update.
A.2. Montreal DT Meeting issues list
Additional issues brought up and discussed during the Montreal DT
meeting:
a. ***Settled*** One prefix per MN, or common prefix?
==> DT leaning towards per-MN prefix.
b. Given a MN with multiple interfaces, what is the relationship
between MN ID and prefix? One prefix per MN ID, or multiple
prefixes, one per interface?
==> With multiple simultaneous interfaces the interfaces should
have individual prefixes
c. Add options to transfer multicast state from MAG to LMA (when a
MN joins a multicast group) and from the LMA to the MAG (when a
MN moves to a new MAG and the MAG needs the multicast group
membership)?
==> Not in base - in base, query the MN for the multicast group
membership)
d. ***Later*** Handle multiple MAGs on the same link
==> [Ignore the issue for now?]
e. Should we reserve the zero type and sub-type values, generally?
==> Henrik's proposal: No
f. Do we have magic which lets us send the LMA allocate message at
the right time?
==> Maybe not? The charging system may know - can/should we get
that information down?
Levkowetz, et al. Expires March 22, 2007 [Page 50]
Internet-Draft The NetLMM Protocol September 2006
g. We need one or more applicability descriptions which show how to
resolve all Magic and shows how the base protocol should
interface with surrounding protocols.
==> Write an applicability description for 802.11, resolving all
the Magic
==> Go through the document and mark all Magic so we can see what
needs to be resolved.
h. ***Done*** What about GRE, MPLS and Routing Tag?
==> Drop from from text and appendices.
i. ***Done*** Get the correct RFC to reference for IPv6 in IPv6
tunnelling
==> Kent looks this up.
j. ***Fixed*** Appendix D text
==> Already covered in 9.1.1.
k. Replace all the individual Ack messages with a single Ack
message?
==> ***Done*** Change the names to consistently use 'Ack' for the
return message -- Henrik
l. We're not sure about the details of using the timestamp - should
specify which messages contain a timestamp, and whether the
conceptual data structure should contain the timestamp of the
last message received
==> Marco verifies that it is clearly indicated which messages
MUST contain the timestamp option.
==> We need to describe when and how the timestamp option is to
be used.
m. From Kevin Grace 24 Jun 2006, email item G) Proper MAG/LMA
behavior for reacting to a Disassociation Acknowledgement message
containing an error code is unspecified; is there a recommended
reaction? More generally, should the handling of different error
codes each acknowledgement be documented?
Appendix B. 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
Levkowetz, et al. Expires March 22, 2007 [Page 51]
Internet-Draft The NetLMM Protocol September 2006
* - 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 C. Issues with omitting the MN Address Setup and Routing Setup
The design team currently considers optimization of the handover
related signaling. This focuses in particular on reducing the
handover signaling from two handshakes to one handshake between the
nMAG and the LMA. The 00 version of the draft specifies different
messages to notify the arrival of an MN to the LMA by means of
indicating the MNID (Location Registration) and to setup routing
states by means of indicating the MN's IP address information (MN
Address Setup and Routing Setup).
In most handover cases, explicit signaling of the MN's IP address by
means of the MN Address Setup and Routing Setup is not required in
case the Location Registration Req/Ack could append IP Address
options. This brings up the question whether or not NetLMM operation
needs the MN Address Setup message at all.
The MN Address Setup has been specified in particular to notify an
MN's IP address from a MAG to the LMA, which includes adding new IP
addresses to an existing state at the LMA. Referring to the agreed
per-MN Prefix addressing model for NetLMM, the LMA and MAG could take
routing decisions solely based on the MN's prefix. Since delegation
of the MN's prefix is performed through the LMA, which notifies the
MN through the MAG about the assigned prefix, the LMA is aware of the
MN's (delegated) prefix after having sent the Location Registration
Acknowledgement. Sending the MN's full IP address back to the LMA by
means of the MN Address Setup message is required only if the LMA
takes routing decisions on the full IP address. Other reasons might
exist.
As taking routing decisions on the LMA based on the full IP address
is only mandatory for the shared prefix addressing model, which is
not supported in the base NetLMM protocol, the design team considers
omitting the MN Address Setup message. However, explicit
notification of the MN's full IP address could still be done by means
of appending the NetLMM Address option to an existing message, such
as the Location Registration message. Such an approach conceptually
Levkowetz, et al. Expires March 22, 2007 [Page 52]
Internet-Draft The NetLMM Protocol September 2006
overloads the Location Registration message and eliminates the
conceptual split between messages handling IDs and routing
information. The design team should take a decision from the
following approaches:
1. Keep MN Address Setup and Routing Setup messages and specify an
approach to piggyback these messages with a Location Registration
Req/Ack.
2. Keep MN Address Setup and Routing Setup messages to be flexible
for specific scenarios, such as notification of the full MN IP
address to the LMA, but allow overloading the Location
Registration (append NetLMM Address options).
3. Omit the MN Address Setup message and allow overload the Location
Registration message (append NetLMM Address options).
4. Other alternatives.
Appendix D. Out of scope
* Inter-MAP handover
* Fast handover
* Hierarchical MAP
Levkowetz, et al. Expires March 22, 2007 [Page 53]
Internet-Draft The NetLMM Protocol September 2006
Authors' Addresses
Henrik Levkowetz (editor)
Ericsson
Torsgatan 71
Stockholm S-113 37
SWEDEN
Phone: +46 708 32 16 08
Email: henrik@levkowetz.com
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
Levkowetz, et al. Expires March 22, 2007 [Page 54]
Internet-Draft The NetLMM Protocol September 2006
Phil Roberts
Motorola
1301 E Algonquin Rd
Schaumberg, IL 60196
USA
Email: phil.roberts@motorola.com
Katsutoshi Nishida
NTT DoCoMo Inc.
3-5 Hikarino-oka, Yokosuka-shi
Kanagawa,
Japan
Phone: +81 46 840 3545
Email: nishidak@nttdocomo.co.jp
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
Levkowetz, et al. Expires March 22, 2007 [Page 55]
Internet-Draft The NetLMM Protocol September 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 implementatio | PAFTECH AB 2003-2026 | 2026-04-22 22:55:12 |