Network Working Group H. Levkowetz, Ed.
Internet-Draft Ericsson
Intended status: Informational P. Roberts
Expires: August 30, 2007 Motorola
February 26, 2007
Network-Based Localised Mobility Management Protocol (NBLM)
draft-levkowetz-netmob-protocol-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 30, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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
Levkowetz & Roberts Expires August 30, 2007 [Page 1]
Internet-Draft The NBLM Protocol February 2007
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
1.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Functional Entities . . . . . . . . . . . . . . . . . . . . . 7
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Mobility Management . . . . . . . . . . . . . . . . . . 10
4.2. Setup and Node Association . . . . . . . . . . . . . . . 13
4.3. Message Transport . . . . . . . . . . . . . . . . . . . 14
4.4. Identity - Locator Split . . . . . . . . . . . . . . . . 17
4.5. Handling of Link-Local Addresses . . . . . . . . . . . . 17
5. Message Format and Message Types . . . . . . . . . . . . . . . 18
5.1. Message Format . . . . . . . . . . . . . . . . . . . . . 18
5.2. Location Registration . . . . . . . . . . . . . . . . . 20
5.3. Location Deregistration . . . . . . . . . . . . . . . . 21
5.4. Association Request . . . . . . . . . . . . . . . . . . 21
5.5. Disassociation Request . . . . . . . . . . . . . . . . . 22
5.6. Heartbeat . . . . . . . . . . . . . . . . . . . . . . . 22
5.7. Acknowledgements . . . . . . . . . . . . . . . . . . . . 24
5.8. Message Status Codes . . . . . . . . . . . . . . . . . . 24
6. Option Format and Option Types . . . . . . . . . . . . . . . . 26
6.1. Option Format . . . . . . . . . . . . . . . . . . . . . 26
6.2. Option Alignment . . . . . . . . . . . . . . . . . . . . 27
6.3. ID Option . . . . . . . . . . . . . . . . . . . . . . . 28
6.4. Handle Option . . . . . . . . . . . . . . . . . . . . . 29
6.5. Prefix Allocation Option . . . . . . . . . . . . . . . . 31
6.6. Prefix Delegation Option . . . . . . . . . . . . . . . . 32
6.7. Data Transport Option . . . . . . . . . . . . . . . . . 34
6.8. Deregistration Timeout Option . . . . . . . . . . . . . 35
6.9. Timestamp Option . . . . . . . . . . . . . . . . . . . . 36
6.10. Vendor-Specific Option . . . . . . . . . . . . . . . . . 37
6.11. Registration Lifetime Option . . . . . . . . . . . . . . 38
6.12. Status Option . . . . . . . . . . . . . . . . . . . . . 39
7. Protocol Specification . . . . . . . . . . . . . . . . . . . . 39
7.1. Mobile Access Gateway Operation . . . . . . . . . . . . 39
7.2. Local Mobility Anchor Operation . . . . . . . . . . . . 44
8. Data Transport . . . . . . . . . . . . . . . . . . . . . . . . 49
8.1. Forwarding of Unicast Data Packets . . . . . . . . . . . 49
8.2. Forwarding of Multicast Data Packets . . . . . . . . . . 50
8.3. Forwarding of Broadcast Data Packets . . . . . . . . . . 52
9. Protocol Constants and Configuration Variables . . . . . . . . 52
10. Security Considerations . . . . . . . . . . . . . . . . . . . 52
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
Levkowetz & Roberts Expires August 30, 2007 [Page 2]
Internet-Draft The NBLM Protocol February 2007
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 54
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 55
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
14.1. Normative References . . . . . . . . . . . . . . . . . . 55
14.2. Informative References . . . . . . . . . . . . . . . . . 56
Appendix A. MN-AR Interface considerations . . . . . . . . . . . 57
Appendix B. Issues with omitting the MN Address Setup and
Routing Setup . . . . . . . . . . . . . . . . . . . . 57
Appendix C. Out of scope . . . . . . . . . . . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58
Intellectual Property and Copyright Statements . . . . . . . . . . 60
Levkowetz & Roberts Expires August 30, 2007 [Page 3]
Internet-Draft The NBLM Protocol February 2007
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
standardisation 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 was developed in response to the
problem statement for network-based localised 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 standardised 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 & Roberts Expires August 30, 2007 [Page 4]
Internet-Draft The NBLM Protocol February 2007
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.
1.1. Contributors
The first version of the protocol described here was developed by the
NetLMM working group design team between January and November of
2006, and described in [I-D.giaretta-netlmm-dt-protocol]. The
continuation of that work, contained in this document, is based
squarely on the good work of the design team. The design team
members, and authors of the design team protocol document, were:
Kent Leung, Cisco, 170 W. Tasman Drive, San Jose, CA 95134, USA.
Phone: +1 408 853 9580, Email: kleung@cisco.com
Gerardo Giaretta, Telecom Italia, via Reiss Romoli 274, 10148 Torino,
Italy.
Phone: +39 011 228 6904, Email: gerardo.giaretta@telecomitalia.it
Marco Liebsch, NEC Network Laboratories, Kurfuersten-Anlage 36,
69115, Heidelberg Germany.
Phone: +49 6221-90511-46, Email: marco.liebsch@netlab.nec.de
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, 356-8502 Saitama, Japan.
Phone: +81 49 278 7894, Email: yokota@kddilabs.jp
Mohan Parthasarathy, Nokia,
Email: mohan.parthasarathy@nokia.com
Phil Roberts, Motorola, 1301 E Algonquin Rd, Schaumberg, IL 60196,
USA.
Email: phil.roberts@motorola.com
Henrik Levkowetz (editor), Ericsson, Torsgatan 71, Stockholm S-113
37, Sweden.
Phone: +46 708 32 16 08 Email: henrik@levkowetz.com
Levkowetz & Roberts Expires August 30, 2007 [Page 5]
Internet-Draft The NBLM Protocol February 2007
2. Terminology
In this document, several words are used to signify the requirements
of the specification. These words are often capitalised. 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 specialised 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
specialised 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.
Localised Mobility Management
Localised Mobility Management is a generic term for protocols
dealing with IP mobility management confined within the access
network. Localised Mobility Management signalling is not routed
outside the access network, although a hand-over may trigger
Global Mobility Management signalling. Localised Mobility
Management protocols exploit the locality of movement by confining
movement related changes to the access network.
Levkowetz & Roberts Expires August 30, 2007 [Page 6]
Internet-Draft The NBLM Protocol February 2007
Localised Mobility Management Protocol
A protocol that supports localised 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 signalling 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 of the MN inside the NetLMM domain. For
IPv6 it is assumed that this is an invariant routable IP address
with global scope.
NetLMM Network Prefix
The NetLMM Network Prefix (NNP) is the IPv6 link prefix of the
NetLMM address.
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
Levkowetz & Roberts Expires August 30, 2007 [Page 7]
Internet-Draft The NBLM Protocol February 2007
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
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
Levkowetz & Roberts Expires August 30, 2007 [Page 8]
Internet-Draft The NBLM Protocol February 2007
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. As
for the relationship between an MN and a MAG, this should preferably
be seen as a relationship between the MN's identity (ID) or IDs and
the MAG or MAGs. From the viewpoint of the NetLMM protocol, each MN
ID, rather than each MN, is treated as a separate entity. Normally,
each MN ID is associated with one MAG, and traffic related to that MN
ID is routed through one MAG; but during hand-over, especially in the
case of make-before-break hand-over, an MN ID may be associated with
multiple MAGs.
Note that the MN ID used by the NetLMM protocol is not necessarily or
maybe not even mostly the same as the ID the MN uses when
authenticating. It could be a technology-specific ID assigned by the
network, or it could be something like the SEND key.
Levkowetz & Roberts Expires August 30, 2007 [Page 9]
Internet-Draft The NBLM Protocol February 2007
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:
* Location Registration / Ack
* Location Deregistration / Ack
When a mobile node first attaches to a NetLMM enabled network, the
network needs to determine if the mobile node should be provided
service. This can be a pre-set policy of providing service to all
attaching nodes, or it could be a more selective policy requiring
some authentication and authorisation. The mechanics of
authentication and authorisation is out of scope for this document.
In order not to keep state in the network, the LMA does no AAA access
to verify whether it may provide service or not - that is done at the
time of authentication, and the information goes to the MAG, not to
the LMA. The MAG is the gateway to NetLMM service, and screens for
authorisation; if authorisation is given, it signals the LMA, which
simply effectuates the commands from the MAG.
The mobile node then needs to acquire an address (see Figure 2).
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 organised 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 an 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 a NetLMM subnet prefix for the MN first, the MAG transfers
this prefix to the LMA via the Location Registration message. This
can happen for instance if the MN acquires its address or delegated
prefix through the use of DHCP, with the MAG acting as a DHCP relay.
The MAG would then see the DHCP response, whereas the LMA would not.
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.
This document assumes that the NetLMM prefix is unique to each MN
Levkowetz & Roberts Expires August 30, 2007 [Page 10]
Internet-Draft The NBLM Protocol February 2007
(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.
At any time while it is attached to the network, the MN may acquire
additional addresses, through DHCP or link-specific means. If this
occurs, the MAG needs to update the routing state by sending a new
Location Registration message to inform the LMA about the current set
of addresses and prefixes allocated and / or delegated to the MN.
Such a Location Registration message MUST contain all the valid
addresses and prefixes associated with the MN, not only the newly
acquired address or prefix.
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 & Roberts Expires August 30, 2007 [Page 11]
Internet-Draft The NBLM Protocol February 2007
+-----+ +-----+ +-----+ +-----+
| MN | | MAG | | LMA | | PDP |
+-----+ +-----+ +-----+ +-----+
| | | |
* 1.MN Attachment | | |
| | | |
| 2."MN_Access_Network API" | |
| (MN ID,LMA handle) | |
| | | |
| * | |
| | | |
| |3.Location Reg. | |
| |(MN ID,MAG handle,LMA handle,{Prefix}) |
| |------------------>| |
| | | |
| |4.Acknowledgement | |
| |(MN ID,MAG handle,LMA handle, |
| | Prefix, Status) | |
| |<------------------| |
. . . .
. . . .
. . . .
| | | |
|5.Router Advertisement | |
| (Prefix) | | |
|<==================| | |
| | | |
|6.IP Address DAD | | |
| (Address) | | |
|==================>| | |
----- NetLMM signalling
===== Link-Layer signalling
{Xxxx} Optional parameter
Figure 2
It is 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 two messages used are Location Deregistration and the
associated Acknowledgement, initiated by the LMA and acknowledged by
the MAG. 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 handle, LMA handle and the MN ID. The LMA responds by
Levkowetz & Roberts Expires August 30, 2007 [Page 12]
Internet-Draft The NBLM Protocol February 2007
sending an acknowledgement to the nMAG that includes the MN ID, the
MAG handle, the LMA handle, and prefix information that the nMAG uses
in the router advertisement for the MN, and then sends a Location
Deregistration message to the old MAG to have it remove the state it
has which is related to the MN.
+-----+ +-------+ +-------+ +-----+
| MN | |old MAG| |new MAG| | LMA |
+-----+ +-------+ +-------+ +-----+
| | | |
* 1.MN Attachment | | |
| | | |
| | 2."MN_Access_Network API" |
| | (MN ID,LMA handle,Prefix) |
| | | |
| | * |
| | | |
| | |3.Location Registration
| | (MN ID,MAG handle,LMA handle,
| | | {Prefix} ) |
| | |------------------>|
| | | |
| | |4.Acknowledgement |
| | (MN ID,MAG handle,LMA handle,
| | | Prefix,Status) |
| | |<------------------|
| | | |
| | 5.Location Deregistration |
| | (MN ID, MAG handle,LMA handle) |
| |<--------------------------------------|
| | | |
| | 6.Acknowledgement | |
| | (MN ID,MAG handle,LMA handle,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
Levkowetz & Roberts Expires August 30, 2007 [Page 13]
Internet-Draft The NBLM Protocol February 2007
* Heartbeat / Ack
A MAG associates itself with an LMA by sending an Association Request
message (see Figure 4) that includes its MAG handle 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,
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 handle, LMA handle, DataTransport) |
|---------------------------------------->|
| |
| Acknowledgement |
| (MAG handle,LMA handle, Data-Transport, Status)
|<----------------------------------------|
. .
. .
. (Regular operation message flows, .
. optionally Heartbeats) .
. .
| Disssociation Request |
| (MAG handle, LMA handle) |
|---------------------------------------->|
| |
| Acknowledgement |
| (MAG handle,LMA handle, 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).
Levkowetz & Roberts Expires August 30, 2007 [Page 14]
Internet-Draft The NBLM Protocol February 2007
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
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
initialises 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.
Levkowetz & Roberts Expires August 30, 2007 [Page 15]
Internet-Draft The NBLM Protocol February 2007
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
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 utilised 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.6.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
4.3.2. Message Re-ordering
If messages from a MAG regarding a specific MN are received out-of-
order, there are cases where an MN may be left without service unless
care is taken to ensure processing of messages in the correct order.
One example of such a situation is if a mobile node acquires multiple
prefixes through DHCP, but the initial Location Registration message,
indicating only one allocated prefix, is lost and subsequently re-
transmitted. Another Location Registration message, generated after
a second prefix allocation or delegation has taken place, will
indicate both prefixes. If the initial Location Registration message
is processed after the second Location Registration message, the
Routing Cache at the LMA will only contain routing information for
the initial prefix, not for the later prefix.
To avoid problems due to out-of-order processing of messages, the MAG
MUST ensure that no message pertaining to a given MN or sets of MNs
are sent until any previous message pertaining to the same MN or MNs
has been acknowledged by the LMA.
Levkowetz & Roberts Expires August 30, 2007 [Page 16]
Internet-Draft The NBLM Protocol February 2007
4.3.3. Message Rate-Limitation
In addition to the retransmission mechanism, NetLMM entities MUST
implement a configurable rate limitation, so that situations where
message storms may occur, there is an upper limit on the number of
messages per second that may be originated by an entity towards
another. The message rate limitation SHOULD be dynamic, so that when
for instance the heartbeat mechanism indicates that the peer is
heavily loaded, the rate limit is lowered.
4.4. Identity - Locator Split
The protocol has been explicitly designed to support the use of
NetLMM node identifiers which are separate from the node locators
(addresses). In addition to what some may claim is a philosophically
pleasing separation of distinct and separate functions, this provides
some direct practical benefits:
With nodes always being identified by their identities (called
handles in this document) rather than by their address, the
protocol has the potential of running unchanged on infrastructure
using different IP addresses types, or even mixing multiple
address types.
A node identified by one identifier may have multiple addresses,
belonging to multiple interfaces. This makes it easier to design
high-availability and high-performance hardware for the NetLMM
nodes, without the nodes having to be individually configured with
knowledge of the multiple interfaces and addresses which may
belong to each of its peers.
Note that this document does not prescribe which kind of identifiers
should be used as LMA and MAG identifiers, and does not prescribe a
mechanism to resolve identifiers to addresses. By default, the
simplest possible resolver mechanism and identifier choice is
assumed: The use of a node's global IPv6 address as identifier, with
the identity to location resolver function being to use the identity
as locator.
4.5. Handling of Link-Local Addresses
Depending on how link-local addresses are handled, their existence
may cause trouble for applications.
There are a number of different ways that link-local addresses could
be handled within a network with NetLMM mobility support:
Levkowetz & Roberts Expires August 30, 2007 [Page 17]
Internet-Draft The NBLM Protocol February 2007
a. Link-local addresses may have network-wide scope. This is
discussed at length in
[I-D.thaler-intarea-multilink-subnet-issues], and is not to be
recommended.
b. Link-local addresses may have MAG-wide scope; i.e., all MNs
attached to the same MAG will have link-local reachability to
each other. The consequence of this is that nodes may discover
they have link-local reachability at one instant in time, but be
deprived of it at the next instant. In other words, because of
node movements, nothing can really be assumed about the
reachability of other nodes through link-local addresses from one
moment to another.
c. Link-local addresses have MN-scope only, or put in a different
way, the MN has a point-to-point link with the MAG. In this
case, the MN will never discover link-local addresses belonging
to other MNs, and applications on the MN will not be in a
position of being able to make erroneous assumptions about link-
local reachability of other nodes.
This document also assumes that link-local addresses are handled
according to method c. above, which is effectively the same manner as
global addresses are handled: The link-local addresses are unique to
each MN, or expressed with different words, the link between the MN
and the MAG is effectively a point-to-point link, with no other nodes
than the MN and the MAG on the link.
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 & Roberts Expires August 30, 2007 [Page 18]
Internet-Draft The NBLM Protocol February 2007
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'.
Sequence numbers are unique to a MAG-LMA association, based on the
MAG handle and LMA handle. If a MAG or an LMA has multiple IP
addresses, they all share one sequence number series.
Levkowetz & Roberts Expires August 30, 2007 [Page 19]
Internet-Draft The NBLM Protocol February 2007
Reserved
32-bit field reserved for future use. The value MUST be
initialised to zero by the sender, and MUST be ignored by the
receiver.
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.
Options
Any other options associated with the message.
5.2. Location Registration
Request Message Type: 1
Required options: MAG handle, LMA handle, MN ID, Timestamp
Acknowledgement Message Type: 65
Required options: MAG handle, LMA handle, 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, or when an MN obtains another prefix/IP address. The
mobility state of the MN, in the MAG and LMA, is created or updated
using this message. The message may contain multiple Prefix
Allocation (Section 6.5) and Prefix Delegation (Section 6.6) Options.
The forwarding state for a MN is fully defined by the Prefix
Allocation and Delegation Options if any are present. On receipt of
a Location Registration message containing one or more Prefix
Allocation and / or Prefix Delegation Options, any old forwarding
state is replaced by the forwarding state defined by the latest
received prefix options. If the Location Registration does not
contain any Prefix Allocation or Prefix Delegation Option, the
forwarding state is unchanged, and Prefix Allocation and Prefix
Delegation Options describing the state are returned from the LMA to
the MAG in the Location Registration Acknowledgement.
The Location Registration Acknowledgement is sent from the LMA to the
MAG to acknowledge the receipt of the Location Registration message.
If the registration is successful, the LMA sends the NetLMM prefix on
this message, which in turn is used for the Router Advertisement sent
Levkowetz & Roberts Expires August 30, 2007 [Page 20]
Internet-Draft The NBLM Protocol February 2007
by the MAG.
5.3. Location Deregistration
Request Message Type: 2
Required options: MAG handle, LMA handle, MN ID
Acknowledgement Message Type: 66
Required options: MAG handle, LMA handle, MN ID, Status
Implementation: Mandatory
Use: Mandatory
The Location Deregistration message is sent from the LMA to a MAG to
delete the mobility state of the MN. The LMA sends this message when
it determines that the MN is at a new location. This message
contains the MN ID, MAG handle, LMA handle and may contain a
Deregistration Timeout option, providing a delayed deregistration.
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
deregistration delay time.
5.4. Association Request
Request Message Type: 16
Required options: MAG handle, LMA handle, Data Transport
Acknowledgement Message Type: 80
Required options: MAG handle, LMA handle, 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
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
Levkowetz & Roberts Expires August 30, 2007 [Page 21]
Internet-Draft The NBLM Protocol February 2007
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.5. Disassociation Request
Request Message Type: 17
Required options: MAG handle, LMA handle
Acknowledgement Message Type: 81
Required options: MAG handle, LMA handle, 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 handle and LMA handle.
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.6. Heartbeat
Request Message Type: 18
Required options: MAG handle, LMA handle
Acknowledgement Message Type: 82
Required options: MAG handle, LMA handle
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 handle
and the LMA handle. 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 handle
and the LMA ID. It MAY contain other options, such as a Timestamp
Option.
Levkowetz & Roberts Expires August 30, 2007 [Page 22]
Internet-Draft The NBLM Protocol February 2007
5.6.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) / (heartbeats_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.
An implementation of the NetLMM protocol may adjust its resend
timeout value (RTO) based on both the heartbeat loss rate and the
Levkowetz & Roberts Expires August 30, 2007 [Page 23]
Internet-Draft The NBLM Protocol February 2007
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.7. 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.12) except in the case of the Heartbeat Acknowledgement,
but may also contain other options which are appropriate in response
to the initial message.
5.8. 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.12).
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 & Roberts Expires August 30, 2007 [Page 24]
Internet-Draft The NBLM Protocol February 2007
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]
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.
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
Levkowetz & Roberts Expires August 30, 2007 [Page 25]
Internet-Draft The NBLM Protocol February 2007
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.
70: Not Associated
The LMA received a Disassociate request from a MAG which was
not in its MAG list.
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.
128: Requested Timeout Modified
Indicates that MAG could not comply with the timeout time
indicated by the LMA in a Location Deregistration message. A
message containing this error code should also contain a
Deregistration Timeout Option indicating the timeout that will
be applied.
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.
Each option is uniquely identified by its combination of Option Type
and Option Sub-Type.
Levkowetz & Roberts Expires August 30, 2007 [Page 26]
Internet-Draft The NBLM Protocol February 2007
Format:
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 unrecognised non-skippable option MUST
silently discard the message. Otherwise, if no unrecognised non-
skippable options are found, the message MUST be processed with
any unrecognised skippable option bypassed (i.e. move to next
option using the Length field of the unrecognised 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
Levkowetz & Roberts Expires August 30, 2007 [Page 27]
Internet-Draft The NBLM Protocol February 2007
and the next 8-octet-aligned boundary are discarded.
In other words, if we include the padding in the figure showing
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. 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 & Roberts Expires August 30, 2007 [Page 28]
Internet-Draft The NBLM Protocol February 2007
Option Type
0
Option Sub-Type
0
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: SEND [RFC3971] public key.
1: NAI according to [RFC4282]
2: Ethernet MAC Address
Additional ID-Types based on cryptographically generated
identifiers are expected to be used, but in order to allocate ID-
Type values for such identifiers it must be clearly specified
exactly what goes into the Identifier field in each case, to
ensure interoperability.
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. Handle Option
The handle option carries LMA and MAG handle entities called handles.
For the purpose of the handle option, the handle itself is viewed as
an octet sequence, but to avoid handle collisions, the handle is
prefixed with an handle type.
Levkowetz & Roberts Expires August 30, 2007 [Page 29]
Internet-Draft The NBLM Protocol February 2007
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Handle-Type | Identifier... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
0
Option Sub-Type
This field indicates what the handle in this option refers to. It
is expected that additional Sub-Types may be defined in the
future.
1: LMA handle
2: MAG handle
Length
The length of the option in octets, excluding the Type, Sub-Type
and Length fields.
Handle-Type
This field indicates the type of handle carried in the remainder
of the option.
*** Note: Check whether there already exists an applicable IANA
registry for handle types which we could use here ***
0: SEND [RFC3971] public key.
1: NAI according to [RFC4282]
2: Ethernet MAC Address
3: IPv6 Address
Additional Handle-Types based on cryptographically generated
identifiers are expected to be used, but in order to allocate
Handle-Type values for such identifiers it must be clearly
Levkowetz & Roberts Expires August 30, 2007 [Page 30]
Internet-Draft The NBLM Protocol February 2007
specified exactly what goes into the Identifier field in each
case, to ensure interoperability.
Identifier
This is a variable-length octet sequence, which is expected to
hold an identifier of the type indicated by the Handle-Type field.
6.5. Prefix Allocation Option
This option defines the address or prefix which has been allocated 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 allocated to the MN. The address or prefix can be either
IPv4 and IPv6.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type |Option Sub-Type| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix | 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.
Levkowetz & Roberts Expires August 30, 2007 [Page 31]
Internet-Draft The NBLM Protocol February 2007
Length
The length of the option in octets, excluding the Type, Sub-Type
and Length fields. When the Option Sub-Type is 0, the Length is
20, and when the Sub-Type is 1, the length is 8.
Prefix
The number of leading 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 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 allocation.
Reserved
Reserved for future use. The value MUST be initialised to zero by
the sender, and MUST be ignored by the receiver.
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.6. Prefix Delegation Option
This option defines a prefix which has been delegated to a mobile
node. It is used by the MAG to inform the LMA about a prefix
delegation to the MN which has been done through for instance DHCP.
The prefix can be either IPv4 and IPv6.
Typically, there will be one address or prefix allocation
(communicated by the presence of the Prefix Allocation Option,
(Section 6.5) taking place when a mobile node first attaches to the
network through a MAG), with address delegations acquired later, for
instance by the use of DHCP, and communicated by the use of the
Prefix Delegation Option. The LMA handles routing in the same way
for allocated and delegated prefixes, but needs to correctly
communicate to a new MAG the allocated and delegated prefixes so that
the MAG can construct its Routing Advertisements correctly, if such
are used.
Levkowetz & Roberts Expires August 30, 2007 [Page 32]
Internet-Draft The NBLM Protocol February 2007
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type |Option Sub-Type| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address (IPv6 case) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
1
Option Sub-Type
2: Indicates that the data in the Address field is an IPv6 address
or address range.
3: 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. When the Option Sub-Type is 2, the Length is
20, and when the Sub-Type is 3, the length is 8.
Prefix
The number of leading bits in the Address that are valid as a
subnet prefix.
Address Prefix
Variable. The value indicates the prefix length of the prefix
delegated to the mobile node.
Reserved
Reserved for future use. The value MUST be initialised to zero by
the sender, and MUST be ignored by the receiver.
Levkowetz & Roberts Expires August 30, 2007 [Page 33]
Internet-Draft The NBLM Protocol February 2007
Address:
If the Option Sub-Type is 2, the value is an IPv6 address, while
if the type is 3, the value is an IPv4 address.
6.7. 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 & Roberts Expires August 30, 2007 [Page 34]
Internet-Draft The NBLM Protocol February 2007
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.8. Deregistration Timeout Option
This option indicates the length, in milliseconds, to keep the
forwarding state of a given MN active after a hand-over. 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 error code "Requested Timeout
Modified" 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 hand-over. The value is in
milliseconds.
Levkowetz & Roberts Expires August 30, 2007 [Page 35]
Internet-Draft The NBLM Protocol February 2007
6.9. 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 hangovers, 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 requires a reliable time distribution method, such as NTP
or GPS time synchronisation, with sufficient accuracy to support fast
moving MNs.
If a Location Registration message received from a MAG has a
timestamp which is earlier than the timestamp of the most recently
received message pertaining to the same MN, special processing has to
be done. If the two messages are from the same MAG it indicates an
error condition, as the lock-step message sending described in
Section 4.3.2 should prevents this from happening. If the two
messages are from different MAGs, the most recently received message,
which has a timestamp older than some previously received message
pertaining to the same mobile node, MUST be discarded and the event
logged.
LMA and MAG nodes MUST support and use message timestamps in the
Location Registration messages.
Acknowledgements of these messages should however 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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Levkowetz & Roberts Expires August 30, 2007 [Page 36]
Internet-Draft The NBLM Protocol February 2007
Option Type
4
Option Sub-Type
0
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.10. Vendor-Specific Option
This option can be used by any vendor or organisation 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 organisation.
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 organisations using the option; only the Value field may be
freely used.
Levkowetz & Roberts Expires August 30, 2007 [Page 37]
Internet-Draft The NBLM Protocol February 2007
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.
Value
Variable. Details defined by individual Vendors / Organisations.
6.11. 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.2) 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 MUST NOT be used.
Levkowetz & Roberts Expires August 30, 2007 [Page 38]
Internet-Draft The NBLM Protocol February 2007
6.12. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.8.
Reserved
24-bit field reserved for future use. The value MUST be
initialised 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:
Levkowetz & Roberts Expires August 30, 2007 [Page 39]
Internet-Draft The NBLM Protocol February 2007
* 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, such as when acting as a DHCP relay (see Section 4.1
and Section 4.3.2). 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 handle of the LMA serving an attached MN. The serving LMA
and its LMA handle is acquired from the LMA selection policy,
which is out of scope of this specification.
Each MAG MUST maintain an LMA List, which identifies all LMAs with
which the MAG is associated. The LMA List is used to perform
heartbeat tests and to map an LMA handle to the associated LMA's IP
address(es). The LMA List also supports the procedure of bulk
deregistrations 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 handle 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. Message sequence numbers are per MAG - LMA
association, based on MAG and LMA handles, not per IP address.
Levkowetz & Roberts Expires August 30, 2007 [Page 40]
Internet-Draft The NBLM Protocol February 2007
* 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 handle 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.
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. 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 handle 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 tunnelling methods that can be
used with the peer LMA. Based on configuration, it is possible
that some tunnelling methods are used only with some LMAs: in this
case, the Association Request message MUST contain only the
tunnelling methods that are administratively permitted with that
specific LMA.
Levkowetz & Roberts Expires August 30, 2007 [Page 41]
Internet-Draft The NBLM Protocol February 2007
When sending an Association Request, the MAG MAY create a tentative
entry in its LMA List, including the LMA handle, 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.
7.1.4. 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.5. 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 handle.
Upon the API notification, the MAG MUST send a Location Registration
Levkowetz & Roberts Expires August 30, 2007 [Page 42]
Internet-Draft The NBLM Protocol February 2007
message to the LMA including its own handle, the handle of the LMA,
and the identity of the MN. How the MAG resolves the LMA handle
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 handle 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 may include 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
if IPv6 stateless address configuration is used. (See
[I-D.ietf-netlmm-mn-ar-if] for a more detailed description of this
case).
The MN can acquire an address through stateless address assignment,
or acquire an address or prefix delegation trough stateful address
assignment, for instance DHCP. When using DHCP, the MAG SHOULD be
configured to act as a DHCP relay. In this case, the MAG may have to
add DHCP options to ensure that address allocation or prefix
delegation is done from the correct address pool, and to ensure that
there is a known binding between the MN ID and the allocated address
or delegated prefix. If DHCP address allocation with the MAG as DHCP
relay occurs after the initial Location Registration message, the MAG
has to send a supplementary Location Registration message which
informs the LMA about the additional address allocation or prefix
delegation received from the DHCP server.
7.1.6. 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 hand-over 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 handle. 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 7.1.5): it sends a
Location Registration message containing the MN ID, the MAG handle
and the LMA handle and receives the Acknowledgement of the Location
Registration message, which includes the Prefixes allocated to and
delegated to the MN.
Levkowetz & Roberts Expires August 30, 2007 [Page 43]
Internet-Draft The NBLM Protocol February 2007
7.1.7. 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.8. Network Detachment
A MAG does not take any action if it detects that a mobile node
detaches, but instead waits for a Location Deregistration message
from the LMA, which will be sent by the LMA once the mobile node has
attached through another MAG. There will however be cases where a
mobile node is taken out of operation, and never re-attaches to
another MAG. In order to handle such cases, a MAG MUST implement
some form of garbage collection of mobile node related state on a
Least Recently Used (LRU) basis. This may be done by simply purging
the oldest mobile node state entries, but this is not recommended.
It is RECOMMENDED to instead purge state for mobile nodes which has
least recently sent or received user traffic, and to do this when the
remaining available resources fall below a threshold, rather than
after fixed or configurable time has elapsed.
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.
* The MAG handle 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
Levkowetz & Roberts Expires August 30, 2007 [Page 44]
Internet-Draft The NBLM Protocol February 2007
message, the MAG handle entry is either initialised, or updated in
case of a hand-over. The MAG handle 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 handle entries to the
associated MAG's IP address(es). The MAG List also supports the
procedure of bulk deregistrations 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.
The MAG List conceptually contains the following fields for each
associated MAG:
* The MAG handle 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.
Availability of multiple MAG IP addresses could support operation
of multi-homed MAGs. Details about how to handle multiple MAG IP
addresses is out of scope of this specification. Message sequence
numbers are per MAG - LMA association, based on MAG and LMA
handles, not per IP address.
* 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
Levkowetz & Roberts Expires August 30, 2007 [Page 45]
Internet-Draft The NBLM Protocol February 2007
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. Association Procedure
When a LMA receives an Association Request message, it MUST look up
in its MAG list the MAG handle contained in the ID option included in
the request. If an entry for that MAG handle is already present in
the MAG list, the LMA MUST send an acknowledgement to the MAG with
status "Already Associated", and log the event.
If an entry for the MAG handle contained in the ID option does not
exist, the LMA MUST create it, including the parameters contained in
the Association Request message (MAG handle, 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
include:
* the LMA handle 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 handle 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.
Levkowetz & Roberts Expires August 30, 2007 [Page 46]
Internet-Draft The NBLM Protocol February 2007
7.2.4. 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, mark
related MN entries in its Routing Cache as unroutable, and send an
Acknowledgement with status 1, "Success". As in all NetLMM messages,
the LMA MUST include the ID option with its identity. If the LMA
does not have an entry in the MAG list, it MUST respond with status
"Not Associated", and log the event.
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, and mark all related
MN entries in its Routing Cache as unroutable.
7.2.5. MN network access procedure
When the local mobility anchor receives a Location Registration
message, it MUST validate it. If the LMA does not have an entry the
MAG list, it MUST respond with status "Not Associated", and log the
event. If the message is badly formed, it MUST respond with status
"Invalid Message" and log the event. 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 hand-over has occurred: the detailed procedure for
this event is described in Section 7.2.7.
If an entry for that MN identifier is not present, the LMA MUST
create a new entry with the MN ID and the MAG handle. After creating
the entry, it MUST send an acknowledgement of the Location
Registration message, with status 1, "Success", including MN ID, LMA
handle, MAG handle. If the Location Registration message contained
one or more Prefix Allocation or Prefix Delegation Options the LMA
registers these in the Routing Cache, otherwise it allocates a prefix
which it associates with the MN ID and returns this prefix to the MAG
as part of the Location Registration Acknowledgement. In this case,
the returned prefix MUST be used by the MAG for 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
Levkowetz & Roberts Expires August 30, 2007 [Page 47]
Internet-Draft The NBLM Protocol February 2007
Acknowledgement with an appropriate Status value.
7.2.6. MN IP address notification procedure
At any time while it is attached to the network, the MN may also
acquire additional addresses, through DHCP or link-specific means.
If this occurs, the MAG will send a new Location Registration message
to inform the LMA about the current set of addresses and prefixes
allocated and / or delegated to the MN. When receiving such a
Location Registration message, the LMA replaces the existing set of
Routing Cache entries for the given MN ID with the new set taken from
the Location Registration message.
7.2.7. 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 7.2.5). If an
entry is already present in the Routing Cache, a hand-over 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 Prefix options which specifies the prefixes
allocated and /or delegated to the MN.
7.2.8. 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 handle and the MAG handle. 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.9. Network Detachment
If a mobile node is taken out of operation, and never re-attaches to
another MAG, the routing state of the LMA will by default remain
unchanged and un-purged. In order to handle such cases, a LMA MUST
implement some form of garbage collection of mobile node related
state on a Least Recently Used (LRU) basis. This may be done by
simply purging the oldest mobile node state entries, but this is not
Levkowetz & Roberts Expires August 30, 2007 [Page 48]
Internet-Draft The NBLM Protocol February 2007
recommended. It is RECOMMENDED to instead purge state for mobile
nodes which has least recently sent or received user traffic, and to
do this when the remaining available resources fall below a
threshold, rather than after fixed or configurable time has elapsed.
8. Data Transport
As soon as a particular MAG has associated with an LMA and an
attached MN has been registered with the LMA, the LMA node and the
MAG node are responsible for forwarding the MN's data traffic
correctly within the NetLMM domain. Associated location and
forwarding information is maintained within the LMA's and the MAG's
Routing Cache. Different forwarding mechanisms between the LMA node
and a particular MAG node might be supported and set up during the
MAG's association procedure.
Network entities which have Version 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 tunnelling has been selected as forwarding approach, it
Levkowetz & Roberts Expires August 30, 2007 [Page 49]
Internet-Draft The NBLM Protocol February 2007
serves as tunnel entry-point. The LMA node decrements the hop limit
of the data packet's IPv6 header by one and encapsulates the packet
in the tunnel IPv6 header. The tunnel IPv6 header might carry one or
more extension headers. The LMA node forwards the tunnel packet to
the MAG node, using its own address as source address and the MAG
node's address as destination address in the outer IPv6 header. The
MAG node terminates the tunnel and MUST process relevant Extension
Headers, which might follow the encapsulating IPv6 header. The MAG
node forwards the data packet towards the MN after decapsulation.
To forward uplink packets, the MAG node serves as tunnel entry-point
and decrements the data packet's hop limit field by one before it
encapsulates the packet in the tunnel IPv6 header. The tunnel IPv6
header might carry one or more extension headers. The MAG node
forwards the tunnel packet to the LMA node, using its own address as
source address and the LMA node's address as destination address in
the outer IPv6 header. The LMA node terminates the tunnel and MUST
process relevant Extension Headers, which might follow the
encapsulating IPv6 header. The LMA node forwards the data packet
towards its final destination after decapsulation.
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.
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.
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 MLD
operation [RFC2710] and communicate with other multicast-enabled
Levkowetz & Roberts Expires August 30, 2007 [Page 50]
Internet-Draft The NBLM Protocol February 2007
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|
+--+ +---+ +---+ +--+
| | | |
| | | |
|-MLD 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 tunnelled
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 & Roberts Expires August 30, 2007 [Page 51]
Internet-Draft The NBLM Protocol February 2007
+--+ +---+ +---+ +--+
|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 consists of messages between MAG and LMA nodes.
The messages are used to create, update and delete mobility state in
MAGs and LMAs. The threats are described in
[I-D.ietf-netlmm-threats]. To address these threats, NetLMM protocol
must support data origin authentication, integrity and replay
protection on a per-packet basis. IPsec [RFC2401] MUST be
implemented and SHOULD be used.
There are several details that should be considered when IPsec is
used for protecting the messages.
Selectors
The IP addresses and NETLMM-UDP-PORT SHOULD be used as selectors
for identifying the control messages. By including the port, only
control messages are protected with IPsec.
Mode
IPsec MUST be used in transport mode between MAG and LMA. Though
AH [RFC4302] provides protection for the addresses in the IP
header, ESP [RFC4303] provides the same by checking the IP address
against the selectors in the SAD [RFC2401]. Thus, ESP [RFC4303]
with non-NULL authentication is sufficient to provide the
Levkowetz & Roberts Expires August 30, 2007 [Page 52]
Internet-Draft The NBLM Protocol February 2007
necessary protection for the control messages.
Key Management
IPsec can provide anti-replay protection when dynamic keying is
used. IPsec does not guarantee correct ordering of packets, only
that they have not been replayed. Hence, when dynamic keying is
used along with the sequence numbers in the NetLMM messages,
replay and re-ordering attacks can be prevented. Note that the
re-ordering attack makes sense only if the messages that are re-
ordered relates to the same mobile node. IKE [RFC2409] MUST be
used for dynamic keying. IKEv2 [RFC4306] MAY be supported.
Authentication
Dynamic keying [RFC2409], [RFC4306] supports several
authentication mechanisms. Pre-shared keys are difficult to
configure and maintain when the number of nodes (MAG and LMA) are
large as there needs to be one pre-shared key between any possible
combination of LMA and MAG. Hence, certificate based IKE
authentication SHOULD be supported. This does not require a
global PKI. The certificates may be signed by the local operator
that deploys the NetLMM service. The use of IKE with certificates
including the various identities is described in
[I-D.ietf-pki4ipsec-ikecert-profile]
Security Policy
MAG can dynamically associate with any LMA in the NetLMM domain.
If the LMA knows the IP addresses of all the MAG in the NetLMM
domain a priori before the IKE session is setup, then the
appropriate SPD entries can be setup beforehand which can be
consulted before engaging in the IKE session. Even if the LMA
does not have any knowledge about the IP addresses of the MAG, it
can use the named SPD entry [RFC2401] and later when the IKE
negotiation is successfully completed, the SPD entry can be added.
IPsec provides data origin authentication based on the identity
verified when the IPsec security association is setup using IKE. The
identity carried within IKE is different from the ID described in
this document. As part of IPsec processing, the receiver of an IPsec
protected datagram verifies that the selectors from the IP header
matches against the values stored in the SAD that were established
during IKE. In the case of NETLMM, the IP address and the port
number would be verified to be consistent with the ones that was
presented during SA establishment. But this verification is not
sufficient to authorise the node (LMA or MAG) to send arbitrary
NetLMM messages.
When the NetLMM message is processed, the source ID should be mapped
to the corresponding IP address using whatever mechanism available
Levkowetz & Roberts Expires August 30, 2007 [Page 53]
Internet-Draft The NBLM Protocol February 2007
(not described in this document) and matched against what was
received in the packet. If there is a mismatch-match, the packet
should be dropped. Additionally, the following checks should be
performed.
* The Location registration can be originated only by the MAG.
Hence, the MAG MUST drop all Location Registration messages
originated by the LMA.
* The Location deregistration message may be originated by the MAG
or LMA to delete the forwarding state. Proper authorisation
checks must be performed to make sure that the forwarding state is
deleted only by the entity (LMA or MAG) that created it. There
are two cases.
- In the hand-over scenario, the deregistration message comes
from the LMA towards the old/previous MAG. The MAG MUST check
to see if the LMA handle in the deregistration request matches
the value stored in the MAG Routing cache entry for the given
MN-ID.
- In case where the MAG detects that the MN has detached, it
sends the deregistration message to the LMA. The LMA MUST
check to see if the MAG-ID in the deregistration request
matches the value stored in the LMA Routing cache entry for the
given MN-ID.
* The MAG MUST drop all associate messages coming from 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.
11. IANA Considerations
12. Contributors
This contribution is a joint effort of the NetLMM design team of the
NetLMM WG. The members include Kent Leung, Gerardo Giaretta, Phil
Roberts, Marco Liebsch, Katsutoshi Nishida, Hidetoshi Yokota, Henrik
Levkowetz, and Mohan Parthasarathy.
Levkowetz & Roberts Expires August 30, 2007 [Page 54]
Internet-Draft The NBLM Protocol February 2007
13. Acknowledgments
14. References
14.1. Normative References
[I-D.ietf-netlmm-nohost-ps]
Kempf, J., "Problem Statement for Network-based Localized
Mobility Management", draft-ietf-netlmm-nohost-ps-05 (work
in progress), September 2006.
[I-D.ietf-netlmm-nohost-req]
Kempf, J., "Goals for Network-based Localized Mobility
Management (NETLMM)", draft-ietf-netlmm-nohost-req-05
(work in progress), October 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.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999.
[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.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
Levkowetz & Roberts Expires August 30, 2007 [Page 55]
Internet-Draft The NBLM Protocol February 2007
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, 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.
[I-D.giaretta-netlmm-dt-protocol]
Giaretta, G., "The NetLMM Protocol",
draft-giaretta-netlmm-dt-protocol-02 (work in progress),
October 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-threats]
Kempf, J. and C. Vogt, "Security Threats to Network-Based
Localized Mobility Management",
draft-ietf-netlmm-threats-04 (work in progress),
September 2006.
[I-D.ietf-pki4ipsec-ikecert-profile]
Korver, B., "The Internet IP Security PKI Profile of
IKEv1/ISAKMP, IKEv2, and PKIX",
draft-ietf-pki4ipsec-ikecert-profile-11 (work in
progress), September 2006.
[I-D.thaler-intarea-multilink-subnet-issues]
Thaler, D., "Issues With Protocols Proposing Multilink
Subnets", draft-thaler-intarea-multilink-subnet-issues-00
(work in progress), March 2006.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[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
Levkowetz & Roberts Expires August 30, 2007 [Page 56]
Internet-Draft The NBLM Protocol February 2007
Protocol", RFC 2960, October 2000.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004.
Appendix A. MN-AR Interface considerations
This document assumes that the MN-AR interface document will describe
the following in more detail:
* - A mechanism for indicating duplicate address to the MN
* - No redirects should be sent by MAG to MN even if the destination
is directly connected to MAG
* - Trigger for IP address configuration
* - MN Identifier option in the trigger ?
* - If SEND is used, Proxy SEND details are needed for defending the
address in the case of a duplicate
* - Router advertisement details : unicast only, what else does it
contain etc."
Appendix B. Issues with omitting the MN Address Setup and Routing Setup
The design team currently considers optimisation of the hand-over
related signalling. This focuses in particular on reducing the hand-
over signalling 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 hand-over cases, explicit signalling 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
Levkowetz & Roberts Expires August 30, 2007 [Page 57]
Internet-Draft The NBLM Protocol February 2007
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
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 C. Out of scope
* Inter-MAP hand-over
* Fast hand-over
* Hierarchical MAP
Levkowetz & Roberts Expires August 30, 2007 [Page 58]
Internet-Draft The NBLM Protocol February 2007
Authors' Addresses
Henrik Levkowetz (editor)
Ericsson
Torsgatan 71
Stockholm S-113 37
SWEDEN
Phone: +46 708 32 16 08
Email: henrik@levkowetz.com
Phil Roberts
Motorola
1301 E Algonquin Rd
Schaumberg, IL 60196
USA
Email: phil.roberts@motorola.com
Levkowetz & Roberts Expires August 30, 2007 [Page 59]
Internet-Draft The NBLM Protocol February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Levkowetz & Roberts Expires August 30, 2007 [Page 60]