Internet-Draft Yoshihiro Ohba, Editor
Expires: March, 2002 Nobuyasu Nakajima
Toshiba America Research, Inc.
Tao Zhang
Telcordia Technologies
September 12, 2001
LH-DMHA - Last Hop DMHA (Dormant Mode Host Alerting) Protocol
<draft-ohba-seamoby-last-hop-dmha-02.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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.
Key Words
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 RFC 2119.
Abstract
This document specifies a protocol for alerting a dormant mode host
of incoming packets. A unique characteristic of the proposed
protocol is that its major operations, namely, paging registration,
monitoring and capturing of paging triggering packets, and initiation
of the paging operation, are performed primarily in a last-hop subnet
(i.e., the edge subnet to which the host is connected before entering
dormant mode). The proposed protocol conforms with the DMHA (Dormant
Mode Host Alerting) protocol requirements discussed in the IETF
Seamoby WG.
Expires March 2002 [Page 1]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
Table of Contents
1. Terminology ............................................. 4
2. Protocol Overview ....................................... 5
3. LH-DMHA Security Model .................................. 9
4. Protocol Description ................................... 10
4.1. Transport .............................................. 10
4.2. DMA Discovery .......................................... 10
4.3. Advertising Paging Area Information .................... 11
4.4. Capability Set ......................................... 11
4.5. Paging Registration .................................... 12
4.6. Paging Area Update ..................................... 13
4.7. Monitoring Paging Trigger Packets ...................... 13
4.8. Paging ................................................. 14
4.9. Detecting Inactive Hosts ............................... 15
4.10. Paging Deregistration .................................. 15
4.11. Configuring Paging Areas ............................... 15
4.12. LH-DMHA Authentication ................................. 16
4.12.1. Authenticating Paging Message .......................... 16
4.12.2. Authenticating Other Messages .......................... 17
4.13. Supporting Multiple IP Addresses Per Hardware Address .. 17
4.14. Supporting Multiple Hardware Addresses ................. 17
4.15. Supporting Mobility Management Protocol ................ 18
4.16. Keep-Alive ............................................. 18
4.17. Robustness Against Failure of Network Elements ......... 19
5. Message Format ......................................... 19
5.1. Payload ................................................ 21
5.1.1. Address List TLV ....................................... 22
5.1.2. Dormant IP Address List TLV ............................ 23
5.1.3. Dormant Hardware Address List TLV ...................... 23
5.1.4. Lifetime TLV ........................................... 23
5.1.5. Lifetime Range TLV ..................................... 23
5.1.6. Status TLV ............................................. 23
5.1.7. Paging Trigger Packets TLV ............................. 24
5.1.8. Capability Set TLV ..................................... 25
5.1.9. Request Message ID TLV ................................. 26
5.1.10. Paging Area List TLV ................................... 26
5.1.11. Terminal Identifier TLV ................................ 26
5.1.12. TA Address TLV ......................................... 26
5.1.13. End-to-end Authentication Data TLV ..................... 27
5.1.14. Hop-by-hop Authentication Data TLV ..................... 27
5.1.15. Op-code TLV ............................................ 27
5.1.16. Optimization Request TLV ............................... 28
5.1.17. Vendor Specific Extension TLV .......................... 28
5.1.18. Extensible Paging Scheme TLV ........................... 28
5.2. LH-DMHA Messages ....................................... 29
5.2.1 DMA Solicitation Message ............................... 29
5.2.2. DMA Advertisement Message .............................. 29
5.2.3. DMA Registration Message ............................... 30
5.2.4. DMA Registration ACK Message ........................... 30
5.2.5. TA Registration Message ................................ 31
5.2.6. TA Registration ACK Message ............................ 32
5.2.7. Paging Area Advertisement Message ...................... 33
5.2.8. Paging Message ......................................... 33
5.2.9. Paging Area Configuration Message ...................... 33
5.2.10. Paging Area Configuration ACK Message .................. 34
5.2.11. Keep-Alive Message ..................................... 34
Expires March 2002 [Page 2]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
5.2.12. Keep-Alive ACK Message ................................. 35
6. Protocol State Information ............................. 35
6.1. Information Maintained by Host ......................... 35
6.1.1. Dormant Monitoring Agent State in Host ................. 35
6.1.2. Tracking Agent State in Host ........................... 36
6.1.3. Paging Agent State in Host ............................. 36
6.2. Information Maintained by Dormant Monitoring Agent ..... 36
6.2.1. Host State in DMA ...................................... 36
6.2.2. Tracking Agent State in DMA ............................ 37
6.3. Information Maintained by Tracking Agent ............... 38
6.3.1. Dormant Monitoring Agent State in TA ................... 38
6.3.2. Paging Agent State in TA ............................... 38
6.4. Information Maintained by Paging Agent ................. 39
6.4.1. Tracking Agent State in Paging Agent ................... 39
6.4.2. Host State in Paging Agent ............................. 39
6.4.3. Other States in Paging Agent ........................... 40
7. Security Consideration ................................. 40
8. References ............................................. 42
9. Authors' Information ................................... 42
A. An LH-DMHA implementation over 802.11 .................. 44
A.1. 802.11 Power Management ................................ 44
A.2. Dormant mode support with 802.11 Power Management ...... 44
A.3. LH-DMHA over 802.11: Host Implementation ............... 45
A.4. LH-DMHA over 802.11: Network Implementation ............ 45
B. RFC 3154 Conformance Check ............................. 46
B.1. Impact on Power Consumption ............................ 46
B.2. Scalability ............................................ 46
B.3. Control of Broadcast/Multicast/Anycast ................. 46
B.4. Efficient Signaling for Inactive Mode .................. 46
B.5. No Routers ............................................. 46
B.6. Multiple Dormant Modes ................................. 47
B.7. Independence of Mobility Protocol ...................... 47
B.8. Support for Existing Mobility Protocols ................ 47
B.9. Dormant Mode Termination ............................... 47
B.10. Network Updates ........................................ 47
B.11. Efficient Utilization of L2 ............................ 47
B.12. Orthogonality of Paging Area and Subnets ............... 48
B.13. Future L3 Paging Support ............................... 48
B.14. Robustness Against Failure of Network Elements ......... 48
B.15. Reliability of Packet Delivery ......................... 48
B.16. Robustness Against Message Loss ........................ 48
B.17. Flexibility of Administration .......................... 48
B.18. Flexibility of Paging Area Design ...................... 48
B.19. Availability of Security Support ....................... 49
B.20. Authentication of Paging Location Registration ......... 49
B.21. Authentication of Paging Area Information .............. 49
B.22. Authentication of Paging Messages ...................... 49
B.23. Paging Volume .......................................... 49
B.24. Parsimonious Security Messaging ........................ 49
B.25. Noninterference with Host's Security Policy ............ 49
B.26. Noninterference with End-to-end Security ............... 49
B.27. Detection of Bogus Correspondent Nodes ................. 50
C. Main Changes from the Previous Version ................. 50
Expires March 2002 [Page 3]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
1. Terminology
The following terminology is defined in this document.
Host (H)
A standard IP host in the sense of STD0003, with an additional
capability to enter dormant mode.
Last Hop Subnet (LHS)
The edge subnet to which a Host is connected. We use the word
"Last Hop Subnet" instead of "Edge Subnet", because the main
purpose of protocol is alerting a dormant mode host of "incoming"
packets.
Last Hop (LH)
The final hop for a packet to reach a Host on the Last Hop Subnet.
Paging Area
Collection of radio access points that are signaled to locate a
dormant mode Host. In this specification, paging area is defined
in the sense of L3 paging and thus it is also referred to as "L3
paging area". An L3 paging area can be configured independently of
L2 technologies or L2 paging areas, even on top of L2 technologies
that do not have L2 paging. The mapping between an L3 paging area
and L2 paging area is entirely an implementation issue and thus out
of scope of this document.
A dormant mode Host may be required to signal to the network when
it crosses a paging area boundary, in order that the network can
maintain a rough idea of where the Host is located.
An arbitrary mapping between subnets and paging areas is allowed in
this protocol.
Tracking Agent (TA)
A node that is responsible for tracking a Host's location while it
is in dormant mode. Each Host is served by a single Tracking
Agent. Multiple Tracking Agents can exist in an administrative
domain in a way that each Tracking Agent keeps track of an
exclusive set of Hosts.
Paging Agent (PA)
A node that is responsible for alerting a dormant Host when there
is an incoming packet for the Host. Additionally, the Paging Agent
Expires March 2002 [Page 4]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
maintains Paging Areas by periodically wide casting information
over the Host's link to identify the Paging Area. The paging area
information may be wide cast at L2 or it may also involve IP. Each
paging area is served by a unique set of Paging Agents.
Note that it is described in the requirements document [DMHA-REQ]
that each paging area is served by a unique functional element
"Paging Agent". In this specification, the Paging Agent
functionality is realized by using one or more protocol entities of
the same name "Paging Agent".
Dormant Monitoring Agent (DMA)
A router in the sense of RFC1812, which locates in a last hop
subnet and detects the delivery of packets to a Host that is in
Dormant Mode (and thus does not have an active L2 connection to the
Internet). It is the responsibility of the Dormant Monitoring
Agent to inform the Paging Agent to page the Host via a Tracking
Agent. Until the Host wakes up with establishing a routable
connection to the Internet, the Dormant Monitoring Agent buffers
the packet destined for the Host.
A Dormant Monitoring Agent can be co-located with Mobile IP Home
Agent or Foreign Agent to realize Home Agent Paging or Foreign
Agent Paging introduced in [RAMJEE2001]. A Dormant Monitoring
Agent can be separated from Home Agent or Foreign Agent, which can
be viewed as a realization of a special case of Domain Paging
[RAMJEE2001].
Agent
An Agent is one of a Dormant Monitoring Agent, a Tracking Agent or
a Paging Agent.
Session
An aggregate state maintained between peering Agents.
2. Protocol Overview
LH-DMHA is an application layer protocol which runs over UDP. LH-
DMHA consists of four basic operations: paging registration, paging
area update, paging, and paging deregistration. Each operation is
illustrated in Figures 1, 2, 3 and 4, respectively.
When a Host which is in active mode decides to enter a dormant mode,
it performs paging registration with the Dormant Monitoring Agent on
the last hop subnet to which it is currently connecting. If the IP
address of the Dormant Monitoring Agent is previously unknown, it
multicasts a DMA Solicitation message on the last hop subnet and the
Dormant Monitoring Agent replies with a DMA Advertisement message.
DMA Advertisement message is also periodically multicast on the last
Expires March 2002 [Page 5]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
hop subnet. Once the IP address of the Dormant Monitoring Agent is
known, the Host sends a DMA Registration message to the Dormant
Monitoring Agent, specifying the lifetime of the registration. Then,
the Dormant Monitoring Agent registers the information specified in
the received message and returns a DMA Registration ACK message to
the Host. If paging area update operation is supported by a Tracking
Agent, the Dormant Monitoring Agent also sends a TA Registration
message to the Tracking Agent on behalf of the Host and waits for a
TA Registration ACK message before returning a DMA Registration ACK
message. When the Host finally receives the DMA Registration ACK
message, it is able to enter dormant mode.
After entering dormant mode, the Host may detect a paging area
change. Then, the Host MAY perform paging area update operation.
There are three methods for paging area update operation. If the L2
supports paging area registration mechanism, the Host MAY perform L2
paging area update, which MAY result in sending a TA Registration
message from a Paging Agent to the Tracking Agent to update the
location of the Host (U1, U2 and U3 in Figure 2). Alternatively, the
Host MAY send a TA Registration message directly to the Tracking
Agent (U1' and U2' in Figure 2). Or the Host MAY perform paging
registration with the Dormant Monitoring Agent that has been taking
care of the dormant Host, with specifying the updated paging area
information, and as a consequence, the Dormant Monitoring Agent sends
a TA Registration message to the Tracking Agent (not illustrated in
Figure 2).
The Dormant Monitoring Agent monitors packets on the subnet, and when
it captures a packet that is worth awaking the registered dormant
Host, it performs paging operation by sending a Paging message to a
set of Paging Agents via Tracking Agent. The Paging message is
delivered to the Tracking Agent by using unicast. The Tracking Agent
forwards the Paging message to Paging Agents by using either unicast
or multicast. When a Paging Agent receives a Paging message, it
performs an action to awake the dormant Host. If L2 supports paging,
the L2 paging SHOULD be involved in the action. The Paging message
MAY be delivered to the dormant Host in a way that is receivable by
the Host. Alternatively, if the Dormant Monitoring Agent is aware of
the exact location of the Host, it MAY directly deliver the paging
trigger packet to the dormant Host. If the Paging message is
delivered to the dormant Host, the Host MUST authenticate the
message. The Dormant Monitoring Agent SHOULD buffer the captured
packet until the Host performs paging deregistration operation or a
paging timeout timer expires.
When the Host exits a dormant mode either spontaneously due to e.g.,
originating a SIP call or starting web-browsing or passively as a
result of receiving a Paging message, a paging trigger packet or an
L2 paging message, it performs paging deregistration operation by
sending a DMA Registration message to the Dormant Monitoring Agent
with which the Host has been registering, with specifying a lifetime
of zero, and then receiving a corresponding DMA Registration ACK
message from the DMA.
Paging area information is advertised by Paging Agents on either
traffic channel or signaling channel or both. When paging area
information is advertised on traffic channel, it is carried in Paging
Expires March 2002 [Page 6]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
Area Advertisement messages periodically multicast.
All messages defined in this specification except for DMA
Solicitation and DMA Advertisement messages MUST be authenticated.
See sections "LH-DMHA Security Model", "LH-DMHA Authentication" and
"Security Consideration" for details.
If any of two Agents or all Agents are co-located in a single node,
it is not needed to carry LH-DMHA messages exchanged between those
Agents over UDP or authenticate the messages. Any mechanism can be
used for exchanging information between those Agents.
(R4) TA Registration (DMA->TA)
+---LHS---+ (R5) TA Registration ACK (TA->DMA)
| +-----+ | +----+
| | DMA |<------------------->| TA |
| +-----+ | +----+
| ^ |
| | |
| | (R1) DMA Solicitation (H->DMA)
| | (R2) DMA Advertisement (DMA->H)
| | (R3) DMA Registration (H->DMA)
| | (R6) DMA Registration ACK (DMA->H)
| | |
| v |
| +---+ |
| | H | |
| +---+ |
+---------+
Figure 1: LH-DMHA registration operation
Expires March 2002 [Page 7]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
+----+
| TA | <--+
+----+ |
^ |
(U2) TA Registration (PA->TA) | |
(U3) TA Registration ACK (TA->PA)| |
v | (U1') TA Registration
+----+ | (H->TA)
| PA | | (U2') TA Registration ACK
+----+ | (TA->H)
^ |
(U1) L2 paging area registration . |
. |
+---LHS---+ . |
| +---+ | +---+ |
| | H | ====================> | H | <--+
| +---+ | (movement) +---+
+---------+
Figure 2: LH-DMHA paging area update operation
+----+
| CN |
+----+
| (P1) Trigger packet arrival
|
v
+-----+ (P2) Paging (DMA->TA) +----+
| DMA |<---------------------->| TA |
+-----+ +----+
|
| (P3) Paging (TA->PA)
+---+--+
| |
v v
+----+ +----+ +----+ +----+
| PA | | PA | | PA |..| PA +
+----+ +----+ +----+ +----+
| |
v v (P4) Paging (PA->H)
+---+
| H |
+---+
Figure 3: LH-DMHA paging operation
Expires March 2002 [Page 8]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
(D3) TA Registration (DMA->TA, with zero lifetime)
(D4) TA Registration ACK (TA->DMA, with zero lifetime)
+-----+ +----+
| DMA |<-----------------------| TA |
+-----+ +----+
^
|
| (D1) DMA Registration (H->DMA, with zero lifetime)
| (D2) DMA Registration ACK (DMA->H, with zero lifetime)
|
| +---+
+----------------------------> | H |
+---+
Figure 4: LH-DMHA deregistration operation
3. LH-DMHA Security Model
LH-DMHA defines its own built-in authentication mechanism, called LH-
DMHA authentication, which is used for authenticating LH-DMHA
messages.
All the LH-DMHA messages exchanged directly or indirectly between the
protocol entities except for DMA Solicitation and DMA Advertisement
message MUST be authenticated by using the LH-DMHA authentication.
The Security Association (SA) which is used for LH-DMHA
authentication is referred to as a DMHA-SA. See Figure 5 for the LH-
DMHA security model.
LH-DMHA does not provide a mechanism to establish the DMHA-SA.
Instead, a number of methods could be used such as IKE, URP and
statically shared key.
The DMHA-SA used for authenticating Paging Area Advertisement
messages is a special SA for which the same shared secret MAY be
shared among all Hosts and all Paging Agents. Such sharing is as a
result of consideration of tradeoff between the security impact of
bogus paging area advertisement and difficulty for establishing an SA
between Paging Agents and a specific Host.
Although LH-DMHA does not have a mechanism to encrypt LH-DMHA
messages, it is possible to use IPsec ESP for message encryption,
provided that an IPsec SA can be established between entities.
See sections "Security Consideration" and "LH-DMHA Authentication"
for details.
Expires March 2002 [Page 9]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
+-----+ DMHA-SA* +----+
| DMA |<------------------------------->| TA |
+-----+ +--------------->+----+
^ | ^
| | |
| | |
| DMHA-SA* | DMHA-SA* | DMHA-SA*
| | |
| | |
v | v
+---+<----------------+ +----+
| H |<-------------------------------> | PA |
+---+ DMHA-SA** +----+
* shared among peering nodes
** shared among all Hosts and PAs
Figure 5: LH-DMHA Security Model
4. Protocol Description
4.1. Transport
The LH-DMHA uses UDP as its transport. The UDP port number is TBD.
4.2. DMA Discovery
If a Host does not know the IP address of the Dormant Monitoring
Agent, it multicasts DMA Solicitation message on the last hop subnet.
A Host MAY also send a DMA Solicitation message whenever it wakes up
from dormant mode, which MAY be used for detecting a subnet change.
The multicast address for IPv4 DMA Solicitation is TBD.
The multicast address for IPv6 DMA Solicitation is TBD.
When a Dormant Monitoring Agent receives a DMA Solicitation message
from a Host, it returns a DMA Advertisement message to the Host. In
addition, a Dormant Monitoring Agent periodically sends a DMA
Advertisement message on the last hop subnet. Solicited DMA
Advertisement messages are unicast to the sender of the DMA
Solicitation message. Unsolicited DMA Advertisement messages are
multicast on the last hop subnet. The scope of the multicast MUST be
limited within the last hop subnet.
The multicast address for IPv4 DMA Advertisement is TBD.
The multicast address for IPv6 DMA Advertisement is TBD.
DMA Solicitation messages and DMA Advertisement messages are not
authenticated.
/* Authors' note : It is also possible to utilize ICMP Router
Solicitation and Router Advertisement for the purpose of DMA
Discovery. */
Expires March 2002 [Page 10]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
4.3. Advertising Paging Area Information
If paging area information is advertised from the network, it is
advertised by Paging Agents on either traffic channel or signaling
channel or both. When paging area information is advertised on
traffic channel, it is carried in Paging Area Advertisement messages
periodically multicast by Dormant Monitoring Agents.
When paging area information is advertised on signaling channel, it
MAY be carried in Paging Area Advertisement messages if the signaling
channel supports carrying IP packets, or it MAY be carried by using
L2 specific method which is not specified in this document.
The multicast address for IPv4 Paging Area Advertisement is TBD.
The multicast address for IPv6 Paging Area Advertisement is TBD.
4.4. Capability Set
A DMA Advertisement message contains a set of capabilities that is
supported by the network. The following capability set is defined in
this version of specification. Each capability can be specified
independently.
o Implicit paging registration: If this capability is supported, a
Host does not need to explicitly perform paging registration
operation before it enters dormant mode. Implicit paging
registration is useful when the Host and Dormant Monitoring Agent
is connected on a point-point link. Implicit paging registration
is also useful when the Dormant Monitoring Agent is co-located with
an access point which is able to know both the dormant state and
the mapping between the hardware address and IP address(es) of the
Host.
o Non-mandatory paging area update: If this capability is supported,
a Host can continue to be dormant when it crosses a paging area
boundary. In other words, Host does not have to perform paging
area update operation each time it crosses a paging area boundary.
Furthermore, if this capability is supported, a Host does not even
have to perform paging area update operation at all. The specific
methods used by a Host to determine when to perform paging update
operation is up to the implementation of specific location update
and paging algorithms.
o TA Registration from Paging Agent: If this capability is supported,
Paging Agents automatically perform paging area update operation on
behalf of a Host when the Host perform L2 paging area registration.
o TA Registration from Host: If this capability is supported, a Host
is allowed to send a TA Registration message to a Tracking Agent to
perform paging area update operation.
o Paging trigger packets specified by Host: If this capability is
supported, a Host is allowed to specify the set of paging trigger
packets in a DMA Registration message.
Expires March 2002 [Page 11]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
o Optimization for mobility management protocol: If this capability
is supported, the Dormant Monitoring Agent advertising this
capability is co-located with a Mobility Agent (e.g., a Home Agent
in Mobile IP or Mobile IPv6 or a Foreign Agent in Mobile IP) and a
Host is exempt from performing periodical mobility binding after
successful paging registration.
4.5. Paging Registration
Before a Host enters dormant mode, it sends a DMA Registration
message to the Dormant Monitoring Agent and waits for a DMA
Registration ACK message. A DMA Registration message contains the
hardware address of the interface of the Host that is going to be
dormant and the lifetime of the registration. The lifetime used for
paging registration MUST be greater than zero.
The Dormant Monitoring Agent then registers the specified information
in the received Registration message and returns a DMA Registration
ACK message to the Host. The DMA Registration ACK message contains a
result of paging registration operation and the lifetime. The
lifetime contained in the DMA Registration ACK message can be
different from that is specified by the Host if the specified value
is out of the range that is supported by the Dormant Monitoring
Agent. If paging area update operation is supported by a Tracking
Agent, the Dormant Monitoring Agent also sends a TA Registration
message to the Tracking Agent on behalf of the Host and waits for a
TA Registration ACK message before returning a DMA Registration ACK
message. Finally, when the Host receives a DMA Registration ACK
message for the DMA Registration message from the Dormant Monitoring
Agent with a result indicating successful registration, it is able to
enter a dormant mode.
To refresh the paging registration state, the registered Host sends a
DMA Registration message to the Dormant Monitoring Agent before the
next lifetime expires.
The Host SHOULD retransmit the DMA Registration message until a
corresponding DMA Registration ACK message is received from the
Dormant Monitoring Agent.
Note that if the Dormant Monitoring Agent supports implicit paging
registration, a Host can enter dormant mode without sending DMA
Registration messages.
If ARP or Neighbor Discovery is used in the last hop subnet, the
following consideration is needed.
o The Dormant Monitoring Agent MUST NOT delete its ARP/Neighbor cache
entry for the dormant Host while the Host is registered.
o If a Host is not able to receive broadcast frames in dormant mode,
it SHOULD delete all the ARP/Neighbor cache entries while it is in
dormant mode, as those entries will not be updated and thus will
Expires March 2002 [Page 12]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
become obsolete.
4.6. Paging Area Update
After entering dormant mode, the Host may detect paging area change
based on the paging area information advertised on traffic channel or
signaling channel (see Section "Advertising Paging Area
Information"). Then, the Host MAY perform paging area update
operation in the following way.
If L2 supports paging area registration mechanism, and the network
supports TA Registration from Paging Agent described in section
"Capability Set", the Host MAY perform L2 paging area update, which
MAY result in sending a TA Registration message from a Paging Agent
to the Tracking Agent to update the location of the Host.
Alternatively, if the network supports TA Registration from Host
described in section "Capability Set", the Host MAY send a TA
Registration message directly to the Tracking Agent. In this case,
if the network supports the capability of "non-mandatory paging area
update" described in section "Capability Set", the Host MAY enter
dormant mode without waiting for a TA Registration ACK message from
the Tracking Agent. In this case, A-flag is set to be zero in the
header of the TA Registration message. See section "Message Format"
for the usage of A-flag.
Alternatively, the Host MAY perform paging registration with the
Dormant Monitoring Agent that has been registering the dormant Host,
with specifying the updated paging area information, and as a
consequence, the Dormant Monitoring Agent sends a TA Registration
message to the Tracking Agent.
In the last two cases, the Host would need to configure a new IP
address before sending the TA Registration message without deleting
the old IP address so that it can receive a TA Registration ACK
message from the Tracking Agent as well as Paging messages from the
Dormant Monitoring Agent regarding the old IP address.
4.7. Monitoring Paging Trigger Packets
A Dormant Monitoring Agent monitors the subnet to which the Hosts are
connected in order to capture paging trigger packets. Currently the
following set of paging trigger packets is defined by default:
o Any unicast IP packet in which the destination IP address matches
the IP address of a registered dormant Host.
o Broadcast ARP REQUEST message in which the target network layer
address matches the IP address of a registered dormant Host.
o In IPv6 case, Neighbor Solicitation message to the target dormant
Expires March 2002 [Page 13]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
Host. The destination address of this message is either the
solicited-node multicast address which corresponds to the target
dormant Host, or the IPv6 address of the target dormant Host.
If the Host performs paging registration with specifying a set of
trigger packets in a DMA Registration message, the specified set of
trigger packets overrides the default set of trigger packets. For
example, a Host MAY specify a set of trigger packets so that it is
awaken only when a SIP message destined for the Host is received at
the Dormant Monitoring Agent.
If the Dormant Monitoring Agent is connected to the last hop subnet
only, and thus is not acting as a gateway to the Internet, the
Dormant Monitoring Agent SHOULD perform proxy- and gratuitous- ARP or
Neighbor Advertisement on behalf of the dormant Host in order to
capture paging trigger packets.
A Dormant Monitoring Agent MAY filter out paging trigger packets
originated from a specific set of correspondent nodes for security
purposes.
/* Authors' note : There is a discussion on the seamoby mailing list
on defining a new ICMP error code used for informing correspondent
nodes of the dormant status of the Host. */
4.8. Paging
When a Dormant Monitoring Agent captures a paging trigger packet, it
sends a Paging message to the Tracking Agent. The Tracking Agent
then determines a set of Paging Agents to forward the Paging message
and forwards it to the Paging Agents. The forwarding is performed by
either unicast or multicast.
When a Paging Agent receives a Paging message, it performs an action
to awake the dormant Host. If L2 supports paging, the L2 paging
SHOULD be involved in the action. The Paging message MAY be
delivered to the dormant Host in a way that is receivable by the
Host. Alternatively, if the Dormant Monitoring Agent is aware of the
exact location of the Host, it MAY directly deliver the paging
trigger packet to the dormant Host. If the Paging message is
delivered to the dormant Host, the Host MUST authenticate the
message.
The Dormant Monitoring Agent SHOULD buffer the captured packet and
retransmit the Paging message until the Host performs paging
deregistration operation or a paging timeout timer expires. The
Paging message is not acknowledged hop-by-hop. Instead, the paging
deregistration attempt by the Host (e.g., arrival of a DMA
Registration message with a lifetime of zero) is used as the end-to-
end acknowledgment for the Paging message. So the Dormant Monitoring
Agent SHOULD retransmit the Paging message until a DMA Registration
message with a lifetime of zero is received from the Host or a paging
timeout timer expires.
Expires March 2002 [Page 14]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
4.9. Detecting Inactive Hosts
A dormant Host may become inactive without performing paging
deregistration for some reasons, such as bad radio conditions or
battery exhaustion. In such a situation, consideration is needed for
not increasing traffic used for paging the Host. To this end, the
Dormant Monitoring Agent considers that the Host becomes inactive
when a paging timeout timer expires. While the Host is considered to
be inactive, the Dormant Monitoring Agent MUST delay the next paging
operation for a while and MUST NOT buffer paging trigger packets
during the delay. The interval between successive paging operations
SHOULD be increased exponentially while the Host is considered to be
inactive.
4.10. Paging Deregistration
When a Host exits a dormant mode either spontaneously due to e.g.,
originating a SIP call or starting web-browsing or passively as a
result of receiving a Paging message, it sends a DMA Registration
message to the Dormant Monitoring Agent with specifying the lifetime
of zero. The Dormant Monitoring Agent then removes the entry for the
Host from its database and returns a DMA Registration ACK message to
the Host with specifying the lifetime of zero. The Dormant
Monitoring Agent also sends a TA Registration message to the Host
with specifying the lifetime of zero and the Tracking Agent returns a
TA Registration ACK with specifying the lifetime of zero to the
Dormant Monitoring Agent.
Alternatively, the Host MAY perform paging registration with a new
Dormant Monitoring Agent of the new last hop subnet where it exits a
dormant mode in order to enter a dormant mode again. In this case,
the Host MAY not need to perform paging deregistration operation with
the old Dormant Monitoring Agent. Instead, the Tracking Agent MAY
perform paging deregistration with the old Dormant Monitoring Agent
on behalf of the Host when it receives TA Registration message from
the new Dormant Monitoring Agent. If this happens, the Tracking
Aegnt sends a DMA Registration message to the old Dormant Monitoring
Agent with specifying a lifetime of zero and waits for a DMA
Registration ACK message from the Dormant Monitoring Agent.
If the Host runs a mobility management protocol, then mobility
binding update MUST be performed when it enters the active mode in
order to re-establish a routable L3 link with the Internet.
Note that the Host can enter the active mode before it receives a DMA
Registration ACK message for paging deregistration, or even before it
sends a DMA Registration message for paging deregistration.
4.11. Configuring Paging Areas
Paging area identifiers to be advertised from a Paging Agent are
configured either manually or automatically at the Paging Agent.
When paging area identifiers are configured automatically, a Tracking
Agent sends a Paging Area Configuration message to a Paging Agent,
Expires March 2002 [Page 15]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
specifying a list of paging area identifiers to be added or deleted.
When a Paging Agent receives a Paging Area Configuration message from
a Tracking Agent, if the paging area identifiers specified in the
received message is successfully added or deleted, it returns a
Paging Area Configuration ACK message to the Tracking Agent.
4.12. LH-DMHA Authentication
All messages defined in this specification except for DMA
Solicitation and DMA Advertisement messages MUST be authenticated. A
DMHA-SA needs to be established between peers that exchange LH-DMHA
messages covered with LH-DMHA authentication either directly or
indirectly.
By default, HMAC-MD5 [HMAC-MD5] is used for calculating any type of
authentication data.
Each LH-DMHA message has a message identifier which monotonically
increases every time a message is transmitted from a node. A node
that performs LH-DMHA authentication for a received message MUST
check the message identifier of the message and MUST NOT accept the
message if the message identifier is out of the expected range in
order to protect the message from reply attacks.
The next two sections explains detail for LH-DMHA authentication.
4.12.1. Authenticating Paging Message
When a Paging message is originated from a Dormant Monitoring Agent,
the Dormant Monitoring Agent MUST calculate two kinds of
authentication data: End-to-end Authentication Data and Hop-by-hop
Authentication Data. End-to-end Authentication Data is calculated by
using the DMHA-SA established between the Dormant Monitoring Agent
and Host. Hop-by-hop Authentication Data is calculated by using the
DMHA-SA established between the Dormant Monitoring Agent and the
Tracking Agent.
When a Tracking Agent or a Paging Agent receives a Paging message, it
MUST calculate the Hop-by-hop Authentication Data by using the DMHA-
SA established between the previous hop Agent and the receiving
Agent. If the calculated Hop-by-hop Authentication Data is not
exactly same as the received one, it MUST discard the message.
When a Tracking Agent forwards a Paging message, it MUST NOT modify
the payload the message except for the Hop-by-hop Authentication
Data. The Tracking Agent MUST recalculate Hop-by-hop Authentication
Data by using the DMHA-SA between Tracking Agent and Paging Agent.
When a Paging Agent forwards a Paging message, it MUST remove the
Hop-by-hop Authentication Data before forwarding the Paging message.
It MUST NOT modify the remaining part of the payload of the message.
When a Host receives a Paging message, it MUST calculate the End-to-
end Authentication Data by using the DMHA-SA established between the
Expires March 2002 [Page 16]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
Dormant Monitoring Agent and Host. If the calculated End-to-end
Authentication Data is not exactly same as the received one, it MUST
silently discard the message.
4.12.2. Authenticating Other Messages
When a node sends a LH-DMHA message except for DMA Solicitation, DMA
Advertisement and Paging messages, it MUST calculate End-to-end
Authentication Data by using the DMHA-SA established between the
originating node and destination node.
When the destination node receives this message, it MUST calculate
End-to-end Authentication Data by using the DMHA-SA established
between the originating node and destination node. If the calculated
End-to-end Authentication Data is not exactly same as the received
one, it MUST discard the message.
4.13. Supporting Multiple IP Addresses Per Hardware Address
In the case of IPv6, it is possible to assign multiple IP addresses
for an interface of a Host. Or if the Host supports both IPv4 and
IPv6 it is possible to assign one IPv4 address and one or more IPv6
addresses for the interface. In such cases, the Host MAY perform
paging registration for different IP addresses with specifying the
same hardware address. To support this, both Dormant Monitoring
Agents and Hosts MUST be able to handle multiple IP addresses per
hardware address.
More specifically, multiple IP addresses can be specified in a DMA
Registration message, and a Dormant Monitoring Agent MUST be able to
perform paging operation when it receives a paging trigger packet
with regard to any of those IP addresses. And the Host MUST perform
paging deregistration for all of those IP addresses when it wakes up
for any of those IP addresses unless the hardware supports different
dormant modes for different IP addresses associated with the same
hardware address.
4.14. Supporting Multiple Hardware Addresses
A Host MAY be equipped with multiple radio interfaces (e.g., both
Bluetooth and IEEE 802.11 interfaces). Each radio interface may be
identified by a separate MAC address. The host MAY use a separate IP
address for each of its radio interface. In this case, different
radio interfaces on the same Host can be treated by the Dormant
Monitoring Agent as different IP hosts, each identified by a separate
IP address. That is, the Host can perform paging registration for
each radio interface separately with the Dormant Monitoring Agent.
The Dormant Monitoring Agent can then maintain paging registration
states for each interface in the same way it handles a single-
interface Host.
On the other hand, a single IP address MAY be used for multiple or
all of the radio interfaces of a multi-interface Host. In this case,
the Dormant Monitoring Agent MUST be able to handle multiple hardware
Expires March 2002 [Page 17]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
addresses per IP address. The Host MAY register multiple hardware
addresses for the same IP address. Since the interfaces on a Host
may not all be connected to the network at any given time or
location, the Dormant Monitoring Agent MUST send a copy of the Paging
message to each hardware address registered for an IP address
registered for an IP address. Upon receiving one or more Paging
messages regardless from which interface or interfaces, at least one
interface on the Host MUST wake up. The Host MAY choose to wake up
all or any subset of its interfaces. How to determine which
interface or interfaces should be waken up is an implementation issue
and is out of the scope of this document.
4.15. Supporting Mobility Management Protocol
If a Host is a mobile node, it is able to move around while it is in
a dormant mode, with changing L2 attachment points or L3 subnets but
without changing its IP address.
It is possible for a Dormant Monitoring Agent to be co-located with a
Home Agent of Mobile IP so that packets destined for the mobile
Host's home address are captured at the Home Agent for triggering
paging operation before it is forwarded to the care-of address,
instead of having a Dormant Monitoring Agent at each last hop subnet
in foreign networks. This is still consistent with the definition of
Dormant Monitoring Agent because the mobile's home network is
considered to be the last hop subnet in terms of home address.
Alternatively, if inter-administrative domain paging is not allowed
due to network management policies, a Dormant Monitoring Agent can be
co-located with a Foreign Agent of Mobile IP.
Although the LH-DMHA protocol is independent of any mobility
management protocol, each mobility management protocol SHOULD have a
capability to reduce the frequency of mobility binding update while
the Host is in dormant mode in order to enjoy the benefit of DMHA in
terms of both power saving and reduced signaling message exchange.
In addition, if a Host is running a mobility management protocol that
has such a capability, the Host SHOULD perform an action which is
specific to the mobility management protocol in order to reduce the
frequency of mobility binding update (e.g., sending a Binding Update
with a longer lifetime in the case of Mobile IPv6) before it enters a
dormant mode, unless the network supports the capability of
optimization for mobility management protocol described in section
"Capability Set". If the network supports the capability of
optimization for mobility management protocol, the lifetime of the
mobility binding cache managed by the Mobility Agent co-located with
Dormant Monitoring Agent can be automatically synchronized with the
lifetime of paging registration. In this case, the Host is exempt
from performing an action which is specific to the mobility
management protocol in order to reduce the frequency of mobility
binding update. In this case, the Host MAY request the above
optimization by including an Optimization Request TLV in a DMA
Registration message (see section "Message Format").
4.16. Keep-Alive
Expires March 2002 [Page 18]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
In order to make sure that a peering Agent is up and running, an
Agent MUST periodically send a Keep-Alive message and to each of its
peering Agents, and the Agent that receives a Keep-Alive message from
its peer MUST return a Keep-Alive ACK message to the peer if
authentication is successful. This operation is referred to as keep-
alive. Keep-alive operation MUST be performed between a Dormant
Monitoring Agent and a Tracking Agent, and between a Tracking Agent
and a Paging Agent. Keep-alive operation MUST be performed bi-
directionally. In other words, if Agent A and B are peering Agents,
both Agent A and B MUST periodically and independently send a Keep-
Alive message.
If an Agent receives a correctly authenticated Keep-Alive ACK message
from an expected peer with which a Session has not been established
yet, a new Session is established for the peer.
If an Agent does not receive a correctly authenticated Keep-Alive ACK
message for a specific period from its peer with which a Session has
been established, it MUST tear down the Session and MUST erase all
the states created as as result of message exchange with the peer.
If an Agent receives an LH-DMHA message except for a Keep-Alive
message from a node with which a Session has not been established, it
MUST be silently discarded without further processing.
4.17. Robustness Against Failure of Network Elements
It is not desired at all for any protocol to have a single point of
failure. LH-DMHA is not an exception. To increase robustness
against failure of network elements, LH-DMHA allows for having
multiple agents that perform the same task. For example, it is
possible to have multiple Dormant Monitoring Agents within the same
subnet. A Host can perform paging registration with any of those
Dormant Monitoring Agents and switch to other Dormant Monitoring
Agent anytime when it realizes that the currently registered Dormant
Monitoring Agent is down.
It is also possible to have multiple Tracking Agents. Then, a
Dormant Monitoring Agent can choose any of those Tracking Agent when
sending a TA Registration message and switch to other Tracking Agent
anytime when it realizes that the currently registered Tracking Agent
is down.
It is also possible to have multiple Paging Agents serving the same
paging area so that a dormant Host can receive Paging messages at
least one of those Paging Agents.
5. Message Format
All messages defined in the LH-DMHA have the following structure.
All fields are transmitted in network byte order without padding.
Expires March 2002 [Page 19]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
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|A|0|0|0| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first 8 octets are the protocol header.
Version
The version of the protocol. The current version is zero.
A-flag
When this bit is set to be one, it indicates that an
acknowledgment MUST be returned from the receiver of the
message.
Type
Message type.
Length
Length of the Payload part in octets. The currently defined
message types are shown in Table 1.
Message ID
This unsigned 32-bit field contains a monotonically increasing
counter value (sequence number) given by the originator of the
message. This is used for matching ACKs against requests as
well as for replay protection. The Message ID is initialized to
be zero when a node starts up or when the Message ID reaches its
maximum value.
Expires March 2002 [Page 20]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
Table 1: Message Types
Type Message Name A-flag
---------------------------------------------------------
0x01 DMA Solicitation 1
0x02 DMA Advertisement 0
0x03 DMA Registration 1
0x04 DMA Registration ACK 0
0x05 TA Registration (see Note 1)
0x06 TA Registration ACK 0
0x07 Paging Area Advertisement 0
0x08 Paging 0
0x09 Paging Area Configuration 1
0x0a Paging Area Configuration ACK 0
0x0b Keep-Alive 1
0x0c Keep-Alive ACK 0
---------------------------------------------------------
Note 1: The A-flag for a TA Registration message MAY be set to 0 if
the message is originated by a Host when the network supports
the capability of "non-mandatory paging area update" described in
section "Capability Set". Otherwise, the
A-flag is set to 1.
5.1. Payload
The Payload part is composed of one or more TLVs (Type-Length-Value
objects), where each TLV has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
The type of this TLV.
Length
The length of the Value field in octets.
Value
The value of this TLV. This field is null if the value of the
Length field is zero.
A TLV can contain other TLV(s). In other words, TLV can be nested.
Each TLV can appear in any order in the Payload except for End-to-end
Authentication Data TLV and Hop-by-hop Authentication Data TLV, which
MUST be placed at the end of the message if included. If both an
End-to-end Authentication Data TLV and a Hop-by-hop Authentication
Data TLV are included in the message, the End-to-end Authentication
Expires March 2002 [Page 21]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
Data TLV MUST be placed before the Hop-by-hop Authentication Data
TLV.
Table 2 summarizes the defined TLVs.
Table 2: TLVs
TLV Name Type Length
-----------------------------------------------
Address List 0x01 Variable
Dormant IP Address List 0x02 Variable
Dormant Hardware Address List 0x03 Variable
Lifetime 0x04 0x04
Lifetime Range 0x05 0x08
Status 0x06 0x04
Paging Trigger Packets 0x07 Variable
Capability Set 0x09 0x04
Request Message ID 0x0a 0x04
Paging Area List 0x0b Variable
Terminal Identifier 0x0c Variable
TA Address 0x0d Variable
End-to-end Authentication Data 0x0e Variable
Hop-by-hop Authentication Data 0x0f Variable
Op-code 0x10 0x04
Optimization Request 0x11 0x00
Vendor Specific Extension 0x12 Variable
Extensible Paging Scheme 0x13 Variable
-----------------------------------------------
5.1.1. Address List TLV
This TLV contains either a list of IP addresses or a list of hardware
addresses of the host that is performing paging registration. A
sequence of Address fields are contained in the Value field of this
TLV as follows:
Address 1
Address 2
.
.
.
Address N
Each Address field has the following structure.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adders Family |Address Length | Address Value..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Family
Expires March 2002 [Page 22]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
Two octet quantity containing a value from ADDRESS FAMILY
NUMBERS in RFC1700 that encodes the address family of the
address specified in this Address field.
Address Length
The length of the Address Value field in octets.
Address Value
The value of address.
5.1.2. Dormant IP Address List TLV
This TLV contains a list of IP addresses of the Host. The Value
field contains an Address List TLV in which the list of IP addresses
is specified.
5.1.3. Dormant Hardware Address List TLV
This TLV contains a list of hardware addresses of the Host. The
Value field contains an Address List TLV in which the list of
hardware addresses is specified.
5.1.4. Lifetime TLV
This TLV contains a lifetime of the paging registration, specified in
seconds. The value of zero indicates paging deregistration.
5.1.5. Lifetime Range TLV
This TLV contains two lifetimes, the first one is the minimum
lifetime and the second one is the maximum lifetime. Each lifetime
contains 4-octet integer value specified in seconds.
5.1.6. Status TLV
This TLV contains a result of message processing. The Value field
contains a one-bit flag (F-flag) for indicating a fatal error and a
31-bit integer for representing Status Code. If a message containing
a Status TLV with a F-flag set to be one is sent to or received from
a peering entity, the states created as a result of exchanging
messages with the peer, including Session state, MUST be deleted
immediately.
Detailed values for Status Code are defined in Table 3.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Expires March 2002 [Page 23]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
Table 3: Values for Status TLV
Status Name F-flag Status Code
--------------------------------------------------------
Success 0 0x00000000
Unsupported Version 1 0x00000001
Invalid Header Flag 1 0x00000002
Unknown Message Type 0 0x00000003
Invalid Message Length 1 0x00000004
Unexpected Message ID 0 0x00000005
Unsupported TLV Type 0 0x00000006
Invalid TLV Length 1 0x00000007
Invalid TLV Value 0 0x00000008
Missing TLV 0 0x00000009
Resource Unavailable 0 0x0000000a
Unsupported Authentication Algorithm 1 0x0000000b
Unknown Terminal Identifier 0 0x0000000c
ICV Mismatch 0 0x0000000d
Session Lifetime Expired 1 0x0000000e
Unsupported Paging Scheme 0 0x0000000f
--------------------------------------------------------
5.1.7. Paging Trigger Packets TLV
This TLV contains a set of paging trigger packets. The Value field
of this TLV has the following format.
Protocol Number 1
Port/Type List 1
Protocol Number 2
Port/Type List 2
.
.
.
Protocol Number N
Port/Type List N
Each Protocol Number field has the following structure.
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Protocol |
+-+-+-+-+-+-+-+-+
The Protocol field contains protocol number assigned by IANA, such as
0x01 (ICMP), 0x06 (TCP) and 0x11 (UDP).
If TCP or UDP is specified in the Protocol Number field, the
Port/Type field contains a list of destination port numbers assigned
by IANA, where the list of destination port numbers has the following
format:
Expires March 2002 [Page 24]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port 1 | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Port M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If ICMP is specified in the Protocol Number field, the Port/Type
field contains a list of ICMP types assigned by IANA, where the list
of ICMP types has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type 1 | Type 2 | ...
+-------------------------------+-------------------------------+
Type M |
+---------------+
5.1.8. Capability Set TLV
This TLV contains a capability set of LH-DMHA. The Value field has
4-octet bitmap in which each bit corresponds to a specific capability
as follows.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |O|P|T|T|N|I|
| for future extension |M|T|H|P|P|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IR (Implicit paging registration)
If this bit is 1, a Host does not need to explicitly perform
paging registration procedure before it enters a dormant mode.
See section "Capability Set" for details.
NP (Non-mandatory paging area update support)
If this bit is 1, a Host can continue to be dormant when it
crosses a paging area boundary.
TP (TA Registration from Paging Agent)
If this bit is 1, Paging Agents automatically perform paging
area update operation on behalf of a Host when the Host performs
L2 paging area registration.
TH (TA Registration from Host)
If this bit is 1, a Host is allowed to send a TA Registration
message to a Tracking Agent to perform paging area update
Expires March 2002 [Page 25]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
operation.
PT (Paging trigger packets specified by Host)
If this bit is 1, a Host is allowed to specify a set of paging
trigger packets in a DMA Registration message.
OM (Optimization for mobility management protocol)
If this bit is 1, a Host is allowed to include an Optimization
Request TLV in a DMA Registration message.
5.1.9. Request Message ID TLV
This TLV contains a 4-octet value of Message ID that was contained in
DMA Registration or TA Registration messages. This TLV is contained
in DMA Registration ACK or TA Registration messages and used by the
receiver of the ACK to match the ACK against pending request.
5.1.10. Paging Area List TLV
This TLV contains a list of 4-octet identifiers which is used to
identify paging area. The Value field of this TLV has the following
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Paging Area Identifier 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Paging Area Identifier N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.1.11. Terminal Identifier TLV
This TLV contains a terminal identifier that is used for identifying
a DMHA-SA. The Value field of this TLV contains a single Address
field for one of the IP addresses of the Host. See section "Address
List" for the format of Address field.
If Host supports Mobile IP [MOBILEIP] or Mobile IPv6 [MOBILEIP-V6],
the Home Address of the Host MAY be specified in this TLV.
5.1.12. TA Address TLV
This TLV contains an IP address of Tracking Agent. The Value field
of this TLV contains a single Address field for one of the IP
addresses of the Tracking Agent. See section "Address List" for the
format of Address field.
Expires March 2002 [Page 26]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
5.1.13. End-to-end Authentication Data TLV
This TLV contains an Algorithm field which specifies the
authentication algorithm and an Integrity Check Value (ICV)
calculated against the message including the header and excluding
this TLV and Hop-by-hop Authentication Data TLV if exists. If a Hop-
by-hop Authentication Data TLV is also included in the message, the
value of the Length field of the message header MUST be temporarily
decreased by the number of octets of the Hop-by-hop Authentication
Data TLV when calculating the ICV of the End-to-end Authentication
Data TLV and the original value MUST be restored after calculating
the ICV.
The Value field of this TLV has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Terminal Identifier TLV ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | ICV ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Table 4 describes the codes used in the Algorithm field.
Table 4: Algorithm Codes
Algorithm Name Algorithm Code Value
----------------------------------------
HMAC-MD5 0x01
----------------------------------------
5.1.14. Hop-by-hop Authentication Data TLV
This TLV contains an Integrity Check Value (ICV) calculated against
the message including the header and excluding this TLV. The Value
field of this TLV has the same format as specified in End-to-end
Authentication Data TLV.
5.1.15. Op-code TLV
This TLV contains a 4-octet integer operation code. The currently
defined set of operation codes is shown in Table 5.
Table 5: Operation Codes
Operation Name Operation Code Value
----------------------------------------
Add 0x01
Delete 0x02
Delete-all 0x03
----------------------------------------
Expires March 2002 [Page 27]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
5.1.16. Optimization Request TLV
This TLV is used for requesting for the optimization for mobility
management protocol, which is described in section "Supporting
Mobility Management Protocol". This TLV MUST NOT contain a Value
field and the value of the Length field MUST be zero.
5.1.17. Vendor Specific Extension TLV
This TLV contains information which is specific to a particular
vendor's implementation.
The Value field of this TLV has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| VSE Type | VSE Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor ID
The high-order octet is set to be zero and the low-order 3
octets contain the SMI Network Management Private Enterprise
Code of the vendor in network byte order, as defined in RFC
1700.
C-flag (Critical flag)
If this bit is 1 and the receiving node does not recognize the
contents of this TLV, the entire message MUST be silently
discarded. If this bit is 0 and the receiving node does not
recognize the contents of this TLV, only this TLV MUST be
silently discarded and processing of remaining TLVs MUST be
continued.
VSE Type
Indicates the particular type of this TLV. The administration
of the VSE Types is done by the vendor.
VSE Value
Vendor specific data of this TLV. These data fields may be
published in future RFCs. This field has zero or more octets.
The length of this field can be computed from the Length field
of this TLV.
5.1.18. Extensible Paging Scheme TLV
This TLV contains information which is specific to a particular
location update and/or paging area configuration scheme but not
Expires March 2002 [Page 28]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
tightly coupled with a specific vendor. For example, information
specified in [DPAC] MAY be carried in this TLV.
The Value field of this TLV has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Paging Scheme Type | Paging Scheme Specific Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Paging Scheme Type
This field contains an integer to distinguish a paging scheme
type. Number assignment for this field must be done by IANA.
Paging Scheme Specific Data
This field contains information which is specific to the paging
scheme type specified in the Paging Scheme Type field. The
length of this field can be computed from the Length field of
this TLV.
5.2. LH-DMHA Messages
5.2.1 DMA Solicitation Message
A DMA Solicitation Message contains no TLV.
5.2.2. DMA Advertisement Message
A DMA Advertisement message contains the following TLVs.
o Terminal Identifier TLV
This TLV contains the terminal identifier for the Dormant Monitoring
Agent that originates this message.
o Lifetime Range TLV
This TLV contains the range of lifetime supported by the Dormant
Monitoring Agent that originates this message.
o Capability Set TLV
This TLV contains the LH-DMHA capability set supported by the Dormant
Monitoring Agent that originates this message.
o Vendor Specific Extension TLV [optional]
Expires March 2002 [Page 29]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
5.2.3. DMA Registration Message
A DMA Registration message contains the following TLVs.
o Dormant IP Address List TLV
This TLV contains the list of IP addresses of the Host
that is going to enter dormant mode.
o Dormant Hardware Address List TLV
This TLV contains the list of hardware addresses that is associated
with the IP address(es) specified in the Dormant IP Address List TLV.
o Lifetime TLV
This TLV contains the requested lifetime of paging registration. When
paging registration is performed, a lifetime of non-zero value MUST be
specified. When paging deregistration is performed, a lifetime of
zero MUST be specified.
o Paging Trigger Packets [optional]
This TLV contains the set of requested paging trigger packets.
o Paging Area List TLV [optional]
This TLV contains a list of paging area identifiers assigned to or
chosen by the Host.
o Optimization Request TLV [optional]
This TLV is included when the Host requests the optimization for
mobility management protocol, which is described in section
"Supporting Mobility Management Protocol".
o Vendor Specific Extension TLV [optional]
o Extensible Paging Scheme TLV [optional]
o End-to-end Authentication Data TLV
This TLV contains the authentication data.
5.2.4. DMA Registration ACK Message
A DMA Registration ACK message contains the following TLVs.
o Request Message ID TLV
This TLV contains the Message ID of the DMA Registration message
to be acknowledged with this message.
o Dormant IP Address List TLV
This TLV contains the list of IP addresses of the Host
that is going to enter dormant mode.
Expires March 2002 [Page 30]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
o Dormant Hardware Address List TLV
This TLV contains the list of hardware addresses that is associated
with the IP address(es) specified in the Dormant IP Address List TLV.
o Lifetime TLV
This TLV contains the accepted lifetime of paging registration.
o Paging Trigger Packets [optional]
This TLV contains the set of accepted paging trigger packets.
o Paging Area List TLV [optional]
This TLV contains a list of paging area identifiers assigned to or
chosen by the Host.
o TA Address TLV [optional]
This TLV contains the IP address of the Tracking Agent. The
information is used when the Host performs paging area update
operation by sending a TA Registration message directly to the
Tracking Agent.
o Status TLV
This TLV contains the result of paging registration operation.
o Vendor Specific Extension TLV [optional]
o Extensible Paging Scheme TLV [optional]
o End-to-end Authentication Data TLV
This TLV contains the authentication data.
5.2.5. TA Registration Message
A TA Registration message contains the following TLVs.
o Dormant IP Address List TLV
This TLV contains the list of IP addresses of the Host
that is going to enter dormant mode.
o Dormant Hardware Address List TLV
This TLV contains the list of hardware addresses that is associated
with the IP address(es) specified in the Dormant IP Address List TLV.
o Lifetime TLV
This TLV contains the requested lifetime of paging registration. When
paging registration is performed, a lifetime of non-zero value MUST be
Expires March 2002 [Page 31]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
specified. When paging deregistration is performed, a lifetime of
zero MUST be specified.
o Vendor Specific Extension TLV [optional]
o Extensible Paging Scheme TLV [optional]
o End-to-end Authentication Data TLV
This TLV contains the authentication data.
5.2.6. TA Registration ACK Message
A TA Registration ACK message contains the following TLVs.
o Request Message ID TLV
This TLV contains the Message ID of the TA Registration message
to be acknowledged with this message.
o Dormant IP Address List TLV
This TLV contains the list of IP addresses of the Host
that is going to enter dormant mode.
o Dormant Hardware Address List TLV
This TLV contains the list of hardware addresses that is associated
with the IP address(es) specified in the Dormant IP Address List TLV.
o Lifetime TLV
This TLV contains the accepted lifetime of paging registration.
o Paging Area List TLV
This TLV contains a list of paging area identifiers
assigned to the Host.
o TA Address TLV [optional]
This TLV contains the IP address of the Tracking Agent, which is to be
carried in a DMA Registration ACK message returned to the Host.
o Status TLV
This TLV contains the result of paging registration operation.
o Vendor Specific Extension TLV [optional]
o Extensible Paging Scheme TLV [optional]
o End-to-end Authentication Data TLV
This TLV contains the authentication data.
Expires March 2002 [Page 32]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
5.2.7. Paging Area Advertisement Message
A Paging Area Advertisement message contains the following TLVs.
o Paging Area List TLV
This TLV contains a list of paging area identifier advertised
by the Paging Agent originating this message.
o End-to-end Authentication Data TLV
This TLV contains the authentication data.
o Vendor Specific Extension TLV [optional]
o Extensible Paging Scheme TLV [optional]
5.2.8. Paging Message
A Paging message contains the following TLVs.
o Dormant IP Address List TLV
This TLV contains the list of IP addresses of the Host
that is going to enter dormant mode.
o Dormant Hardware Address List TLV
This TLV contains the list of hardware addresses that is associated
with the IP address(es) specified in the Dormant IP Address List TLV.
o Vendor Specific Extension TLV [optional]
o Extensible Paging Scheme TLV [optional]
o End-to-end Authentication Data TLV
This TLV contains the authentication data calculated by
the originating Dormant Monitoring Agent.
o Hop-by-hop Authentication Data TLV [optional]
This TLV contains the authentication data calculated by
the previous hop agent. If the previous hop agent is Paging Agent
this TLV is not included.
5.2.9. Paging Area Configuration Message
A Paging Area Configuration message contains the following TLVs.
o Op-code TLV
This TLV contains an operation code indicating "Add",
"Delete", or "Delete-all". See section "Op-code" for the operation
Expires March 2002 [Page 33]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
code value for each operation code.
o Paging Area List TLV [optional]
This TLV contains a list of paging area identifier to be added or
deleted. This TLV MUST NOT be included when the operation code
specified in the Op-code TLV indicates "Delete-all".
o Vendor Specific Extension TLV [optional]
o Extensible Paging Scheme TLV [optional]
o End-to-end Authentication Data TLV
This TLV contains the authentication data.
5.2.10. Paging Area Configuration ACK Message
A Paging Area Configuration ACK message contains the following TLVs.
o Request Message ID TLV
This TLV contains the Message ID of the Paging Area Configuration
message to be acknowledged with this message.
o Op-code TLV
This TLV contains an operation code specified in the corresponding
Paging Area Configuration message.
o Paging Area List TLV [optional]
This TLV contains a list of paging area identifier that is
successfully added or deleted by the Paging Agent that returns this
message. This TLV MUST NOT be included when the operation code
specified in the Op-code TLV indicates "Add-all" or "Delete-all".
o Status TLV
This TLV contains the result of paging area configuration.
o Vendor Specific Extension TLV [optional]
o Extensible Paging Scheme TLV [optional]
o End-to-end Authentication Data TLV
This TLV contains the authentication data.
5.2.11. Keep-Alive Message
A Keep-Alive message contains the following TLV.
o Vendor Specific Extension TLV [optional]
Expires March 2002 [Page 34]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
o End-to-end Authentication Data TLV
This TLV contains the authentication data.
5.2.12. Keep-Alive ACK Message
A Keep-Alive ACK message contains the following TLV.
o Request Message ID TLV
This TLV contains the Message ID of the Keep-Alive message to be
acknowledged with this message.
o Vendor Specific Extension TLV [optional]
o End-to-end Authentication Data TLV
This TLV contains the authentication data.
6. Protocol State Information
This section describes the state information maintained at each
protocol entity.
6.1. Information Maintained by Host
6.1.1. Dormant Monitoring Agent State in Host
At least the following information is maintained per Dormant
Monitoring Agent.
o The Terminal Identifier of DMA.
o The Terminal Identifier of Host.
o The shared secret for DMA.
o The content of Dormant IP Address List TLV.
o The content of Dormant Hardware Address List TLV.
o The content of Lifetime TLV.
o The contents of Request Message ID TLV contained in the most
recently and correctly received DMA Registration ACK message.
o Message ID contained in the most recently sent DMA Registration
message.
o The contents of TA Address TLV.
o The contents of Paging Trigger Packets TLV.
o The contents of Paging Area List TLV.
Expires March 2002 [Page 35]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
o The contents of Capability Set TLV.
o Retransmission timer for DMA Registration message.
o Timer for deleting this Dormant Monitoring Agent State entry.
6.1.2. Tracking Agent State in Host
At least the following information is maintained per Tracking
Agent.
o The Terminal Identifier of TA which is also same as the
the contents of TA Address TLV in the DMA State.
o The shared secret for TA.
o The contents of Request Message ID TLV contained in the most
recently and correctly received TA Registration ACK message.
o The Message ID contained in the most recently sent TA Registration
message.
o Retransmission timer for TA Registration message.
6.1.3. Paging Agent State in Host
At least the following information is shared among all Paging Agents.
o Shared secret for authenticating Paging Area Advertisement messages.
At least the following information is maintained per Paging Agent.
o The Terminal Identifier of PA.
o The Message ID contained in the most recently sent Paging Area
Advertisement message.
o Timer for deleting this Paging Agent State entry.
o The content of Lifetime TLV.
o The contents of Request Message ID TLV contained in the most
recently and correctly received DMA Registration ACK message.
o Message ID contained in the most recently sent DMA Registration
message.
6.2. Information Maintained by Dormant Monitoring Agent
6.2.1. Host State in DMA
At least the following information is maintained per Host.
Expires March 2002 [Page 36]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
o The Terminal Identifier of Dormant Monitoring Agent.
o The Terminal Identifier of Host.
o The shared secret for Host.
o The contents of Dormant IP Address List TLV.
o The contents of Dormant Hardware Address List TLV.
o The contents of Lifetime TLV.
o The Message ID contained in the most recently and correctly received
DMA Registration message.
o The Message ID contained in the most recently sent DMA Registration ACK
message.
o The contents of TA Address TLV.
o The contents of Paging Trigger Packets TLV.
o The contents of Paging Area List TLV.
o The contents of Capability Set TLV.
o A flag indicating whether Optimization Request TLV is received from
Host.
o Packet buffer for paging trigger packets.
o Retransmission timer for TA Registration message.
o Retransmission timer for Paging message.
o Timer for next round of paging operation
o Timer for deleting this Paging Agent State entry.
6.2.2. Tracking Agent State in DMA
At least the following information is maintained for a Tracking Agent.
o The Terminal Identifier of Dormant Monitoring Agent.
o The Terminal Identifier of TA.
o The Session state for TA.
o The shared secret for TA.
o The lifetime of this Tracking Agent State entry.
o The Message ID contained in the most recently and correctly received
message from TA.
Expires March 2002 [Page 37]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
o The Message ID contained in the most recent message sent to TA.
o Retransmission timer for Keep-Alive message
o The timer for deleting this Tracking Agent State entry.
6.3. Information Maintained by Tracking Agent
6.3.1. Dormant Monitoring Agent State in TA
At least the following information is maintained per Dormant
Monitoring Agent.
o The Terminal Identifier of DMA.
o The Terminal Identifier of TA.
o The Session state for TA.
o The shared secret for DMA.
o The lifetime of this Dormant Monitoring Agent State entry.
o The Message ID contained in the most recently and correctly received
message from DMA.
o The Message ID contained in the most recently sent message to DMA.
o Retransmission timer for Keep-Alive message
o The timer for deleting this Dormant Monitoring Agent State entry.
o The list of Host States for dormant Hosts that is registered in DMA.
Each Host State contains the following information on a particular Host.
o The contents of Paging Area List TLV
o The contents of Dormant IP Address List TLV.
o The contents of Dormant Hardware Address List TLV.
o The contents of Lifetime TLV.
o The timer for deleting this Host State entry.
6.3.2. Paging Agent State in TA
At least the following information is maintained per Paging Agent.
o The Terminal Identifier of PA.
o The Terminal Identifier of TA.
o The shared secret for PA.
Expires March 2002 [Page 38]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
o The Session state for PA.
o The lifetime of this Paging Agent State entry.
o The Message ID contained in the most recently and correctly received
message from PA.
o The Message ID contained in the most recent message sent to PA.
/* Authors' note: If multicast is used for sending Paging messages,
different Message ID spaces would be necessary for Paging messages and
Keep-Alive messages. */
o Retransmission timer for Keep-Alive message
o The timer for deleting this Paging Agent State entry.
o The list of paging area identifiers to be advertised by PA.
6.4. Information Maintained by Paging Agent
6.4.1. Tracking Agent State in Paging Agent
At least the following information is maintained per Tracking Agent.
o The Terminal Identifier of TA.
o The Terminal Identifier of PA.
o The shared secret for TA.
o The Session state for TA.
o The lifetime of this Tracking Agent State entry.
o The Message ID contained in the most recently and correctly received
message from TA.
/* Authors' note: If multicast is used for sending Paging messages,
different Message ID spaces would be necessary for Paging messages and
Keep-Alive messages. */
o The Message ID contained in the most recent message sent to TA.
o Retransmission timer for Keep-Alive message
o The timer for deleting this Tracking Agent State entry.
o The list of paging area identifiers to be advertised by PA.
6.4.2. Host State in Paging Agent
At least the following information is shared among all Hosts.
o Shared secret used for creating Paging Area Advertisement messages.
Expires March 2002 [Page 39]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
6.4.3. Other States in Paging Agent
The following additional information MAY be maintained.
o A list of Access Routers through which Paging messages are carried
on traffic channel.
o Any L2 dependent information needed for performing L2 paging. The
L2 dependent information MAY include the list of Access Points that
are not able to receive and process Paging messages at L3. Note that
how to page Hosts through those Access Points depends on L2 and out of
the scope of this document.
/* Authors' note: if an Access Point is able to receive and process
Paging messages at L3, then it can be a separated Paging Agent and
SHOULD NOT be included in the above list. */
7. Security Consideration
LH-DMHA provides a method to authenticate message exchanges which is
required for standard Seamoby IP Paging protocol [DMHA-REQ,DMHA-PROB].
For this purpose, LH-DMHA defines its own built-in authentication
mechanism, called LH-DMHA authentication, which is used for
authenticating LH-DMHA messages.
All the LH-DMHA messages exchanged directly or indirectly between the
protocol entities except for DMA Solicitation and DMA Advertisement
message MUST be authenticated by using the LH-DMHA authentication.
The Security Association (SA) which is used for LH-DMHA authentication
is referred to as a DMHA-SA.
Omitting authentication for DMA Solicitation and DMA Advertisement
messages would not impact on the security aspect of LH-DMHA protocol,
in that they do not contain important information except for Terminal
Identifier of the Dormant Monitoring Agent contained in DMA
Advertisement. Even if someone creates a DMA Advertisement message
with a bogus Terminal Identifier, it does not matter because further
message exchange (e.g., exchanging DMA Registration and DMA
Registration ACK) between Host and Dormant Monitoring Agent is
mutually authenticated. In addition, if paging registration operation
fails several times due to receiving bogus DMA Advertisement messages,
a Host is able to ignore subsequent DMA Advertisement messages
advertised from the source. However, this protocol is vulnerable to
attacks of sending DMA Advertisement messages with frequently changed
bogus source IP addresses. Note that this kind of attack is common
for all protocols such as DHCP, IPv6 Neighbor Discovery, etc., that
may use unauthenticated multicast messages.
LH-DMHA does not provide a mechanism to establish the DMHA-SA.
Instead, a number of methods could be used such as IKE, URP and
statically shared key.
One of the main reasons for using LH-DMHA authentication instead of
using IPsec is due to the difficulty for authenticating Paging
messages at Hosts. There are two approaches to authenticate Paging
Expires March 2002 [Page 40]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
messages. One approach is based on hop-by-hop authentication in which
Paging messages are authenticated at each hop by using the SA between
the adjacent nodes of each hop (e.g., between DMA and TA, TA and PA,
and PA and H). However, establishing such an SA between Paging Agents
and a specific Host is difficult since the Host cannot determine the
Paging Agent that will page it beforehand.
The other approach is based on authenticating Paging messages in
different levels, one performed at each hop except for the one between
Paging Agent and the Host, and the other performed in an end-to-end
fashion by using the SA between Dormant Monitoring Agent and Host. The
latter approach seems to be better because no SA is needed between
Paging Agent and Host.
There are two choices in the latter approach regarding the layer in
which end-to-end authentication is performed for Paging messages. The
first choice is based on higher layer authentication mechanism (i.e.,
DMHA authentication). The second choice is based on IPsec with
IP-in-IP encapsulation in which the inner IP packet containing a
Paging message is covered by end-to-end IPsec AH (and the outer IP
packet is used to route the packet along the "forwarding path" of the
Paging message). Considering the fact that application level
forwarding is needed for Paging messages, the first choice is better
than the IP-in-IP based one, because in the case of IP-in-IP,
forwarding is entirely performed at L3 and the contents of the inner
packet are transparent at intermediate nodes (e.g., Tracking Agent and
Paging Agent). Thus, IP-in-IP based approach is not suitable for
carrying and authenticating Paging messages.
The other reason for using LH-DMHA authentication instead of using
IPsec is that the IP address of the Host may change from that was used
for paging registration when it performs paging deregistration or
paging area update. If IPsec is used, a new IPsec SA needs to be
established when the Host changes the IP address, which would increase
signaling delay. If the Host uses Mobile IP or Mobile IPv6, and the
Home Address of the Host is used for the identifier of the IPsec SA, a
new IPsec SA would not have to be established when the Host changes
its Care-of Address. However, in this case, the Host needs to perform
mobility binding update in order for signaling packets to reach the
Host, which would increase signaling traffic.
The DMHA-SA used for authenticating Paging Area Advertisement messages
is a special SA for which the same shared secret MAY be shared among
all Hosts and all Paging Agents. Such sharing is as a result of
consideration of tradeoff between the security impact of bogus paging
area advertisement and difficulty for establishing an SA between
Paging Agents and a specific Host. Even a malicious user that is
aware of the shared secret advertises bogus Paging Area Advertisement
messages, a dormant Host would not wake up as long as it also receives
Paging Area Advertisement messages from correct Paging Agents,
assuming that the Host waits for some time to correct a set of Paging
Area Advertisement messages. Basically, a Host SHOULD NOT determine
that it has crossed a paging area boundary immediately after receiving
a Paging Area Advertisement message which includes a new paging area
identifier, as multiple Paging Agents MAY advertise different paging
area identifiers.
Expires March 2002 [Page 41]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
The only attack by using bogus Paging Area Advertisement messages is
that it is possible to prevent a Host from exiting dormant mode even
if the Host is actually out of the paging area. However, this attack
would not be serious because it is possible only when the Host is
mobile and both the Host and attacker is on the same shared media,
which would be rare. If the attacker is not on the same shared media,
there are three cases. First, for attackers from the edge subnets in
the administrative domain, an access router is able to prohibit
forwarding any Paging Area Advertisement message received on an
interface to edge subnet(s). Second, for attackers outside the
administrative domain, any Paging Area Advertisement message that is
not originated from the administrative domain can be also filtered
out. Third, for attackers inside the core network of the
administrative domain, the attackers' network access can be physically
prevented.
/* Authors' note : Based on the above discussion, authentication
Paging Area Advertisement messages may not be necessary. */
8. References
[DMHA-PROB] J. Kempf, "Dormant Mode Host Alerting ("IP Paging")
Problem Statement", RFC 3132, June 2001.
[DMHA-REQ] J. Kempf, et al., "Requirements and Functional Architecture
for an IP Host Alerting Protocol", RFC 3154, August 2001.
[DPAC] P. Mutaf, et al., "DPAC: Dynamic Paging Area Configuration",
Inter-Draft, Work in Progress, August 2001.
[HMAC-MD5] H. Krawczyk, "HMAC: Keyed-Hashing for Message
Authentication", RFC 2104, February 1997.
[IEEE802.11] "Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) specifications", IEEE Std 802.11, June 1997.
[MOBILEIP] C. Perkins, "IP Mobility Support", RFC 2002, October 1996.
[MOBILEIP-V6] D. Johnson, et al., "Mobility Support in IPv6",
Internet-Draft, Work in Progress.
[RAMJEE2001] R. Ramjee, et al., "IP Paging Service for Mobile Host",
Proceedings of MOBICOM 2001, July 2001.
9. Authors' Information
Yoshihiro Ohba
Toshiba America Research, Inc.
P.O. Box 136
Convent Station, NJ
07961-0136
USA
Phone: +1 973 829 5174
Fax: +1 973 829 5601
Email: yohba@tari.toshiba.com
Expires March 2002 [Page 42]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
Nobuyasu Nakajima
Toshiba America Research, Inc.
P.O. Box 136
Convent Station, NJ
07961-0136
USA
Phone: +1 973 829 4752
Email: nnakajima@tari.toshiba.com
Tao Zhang
Telcordia Technologies, Inc.
445 South Street, Room 1J-214B
Morristown, NJ 07960
USA
Phone: +1 973 829 4539
Fax: +1 973 829 5889
Email: tao@research.telcordia.com
Expires March 2002 [Page 43]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
A. An LH-DMHA implementation over 802.11
A.1. 802.11 Power Management
The power management capability of IEEE 802.11 [IEEE802.11] for an
infrastructure network can be summarized as follows. A station
changing Power Management mode informs the Access Point (AP) of this
fact using the Power Management bits in the Frame Control field of the
transmitted MAC frames. An AP periodically broadcasts beacon signals
to provide time synchronization information and inform stations in
Power Save mode of arriving frames. A station uses the time
synchronization information received from the AP to determine when it
should wake up periodically from Power Save mode. The AP buffers the
MAC frames destined to the station in Power Save mode and transmit
them at designated times.
Unicast frames destined to a host in Power Save mode are transmitted
by the AP and received by the station in different ways from
broadcast/multicast frames. With every beacon transmission, the AP
informs each station in Power Save mode of the unicast frames buffered
by the AP for the station and whether these frames are to be sent to
the station during a content-free or a contention time period. If a
unicast frame is to be sent in a contention period, the station will
poll the AP to receive the unicast frame. If a frame is to be sent
during a contention-free period, the station will not poll the AP but
will instead remain active until the frame is received or the
contention-free period ends.
The AP notifies the stations of the existence of broadcast/multicast
frames only via selected beacons periodically and the
broadcast/multicast frames are sent immediately after these beacons.
A.2. Dormant mode support with 802.11 Power Management
By utilizing the timing differences for multicast/broadcast frames and
unicast frames, three different dormant modes can be realized in the
single Power Save mode.
o All Mode: Both unicast and multicast/broadcast frames are received.
o Unicast Only Mode: Only unicast frames are received.
o Multicast Only Mode: Only multicast/broadcast frames are received.
The dormancy levels of Unicast Only Mode and Multicast Only Mode are
higher than that of All Mode. Unicast Only Mode is effective in terms
of battery saving especially for a Host connecting to the network
where broadcast/multicast traffic is high and most of the
broadcast/multicast traffic is not important to the dormant station.
On the other hand, there are also important broadcast/multicast frames
that need to be received by the dormant Host in order to to receive
Expires March 2002 [Page 44]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
incoming SIP calls. One example is ARP REQUEST packets which are
broadcast by a node in the last hop subnet in order to obtain the MAC
address for an IP address of the Host.
Section A.3 describes an implementation of the Last Hop IP Paging
Protocol that allows a Host to stay in the Unicast Only Mode while in
power saving mode and will still be able to receive both unicast and
selected types of broadcast traffic.
A.3. LH-DMHA over 802.11: Host Implementation
The LH-DMHA over 802.11 for IPv4 is implemented in a Host in
the following way.
1) The Host monitors its own IP activity.
2) The Host stays in active mode while IP packets are sent or received.
3) If no IP packet is sent or received during a certain period, it
performs paging registration.
4) If paging registration is successful, the Host enters the Unicast
Only Mode, otherwise, enters the All Mode.
5) If the Host receives a paging trigger packet as a result paging, it
performs paging deregistration.
A.4. LH-DMHA over 802.11: Network Implementation
In this section, it is assumed that a Dormant Monitoring Agent is
co-located with Tracking Agent and Paging Agent in a single node and
is referred to as a Paging Server. The Paging Server is assumed to
be connected to the last hop subnet through wired Ethernet.
The LH-DMHA over 802.11 is implemented in a Paging Server in the
following way.
1) The Paging Server monitors packets on the last hop subnet.
2) If it captures a paging trigger packet for a registered Host, it
forwards the packet to the Host to registered hardware address, with
specifying the hardware address of the registered Host as the
destination MAC address and the Dormant Monitoring Agent's hardware
address on the monitoring interface as the source MAC address.
For example, if the paging trigger packet is a broadcast ARP REQUEST
message, the destination MAC address of the forwarded packet is
changed from ff:ff:ff:ff:ff:ff to the hardware address of the
Expires March 2002 [Page 45]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
registered Host, and the source MAC address is changed from the
original sender's hardware address to the Paging Server's
hardware address on the monitoring interface. The body of the ARP
REQUEST is not modified. Since the Host in operating in Unicast Only
Mode, it can receive the unicast ARP REQUEST. Then, it returns an ARP
REPLY to the original sender, not to the Dormant Monitoring Agent.
In addition, if the Paging Server is co-located with the last hop
access router or gateway, there is also a case in which it receives a
unicast IP packet that is destined for the dormant Host and needs to
be forwarded from other interface to the last hop interface. In this
case it can use the ARP cache entry as usual to forward the packet to
the dormant Host, since the ARP cache entry is not deleted during the
lifetime of the paging registration (see section 3.3).
B. RFC 3154 Conformance Check
B.1. Impact on Power Consumption
The LH-DMHA protocol minimizes impact on the Host's dormant mode
operation, because it allows the Host to stay dormant without
configuring IP address while it is roaming.
The LH-DMHA protocol conforms to RFC3154 with this regard.
B.2. Scalability
The LH-DMHA protocol is scalable to support millions of Hosts, because
multiple Tracking Agents can exist in an administrative domain in a
way that each Tracking Agent keeps track of an exclusive set of Hosts.
The LH-DMHA protocol conforms to RFC3154 with this regard.
B.3. Control of Broadcast/Multicast/Anycast
The LH-DMHA protocol provides a filter mechanism to allow a Host prior
to entering dormant mode to filter which broadcast/multicast/anycast
packets active a page by defining a default set of paging packets and
allowing a Host to explicitly specify the set of paging trigger
packets. This prevents the Host from awakening out of dormant mode
for all broadcast/multicast/anycast traffic. The LH-DMHA protocol
conforms to RFC3154 with this regard.
B.4. Efficient Signaling for Inactive Mode
The LH-DMHA protocol supports inactive mode detection mechanism for
Hosts that are registered with Dormant Monitoring Agents. A back-off
mechanism is defined to reduce the traffic volume of Paging messages
for Hosts that are considered to be inactive. The LH-DMHA protocol
conforms to RFC3154 with this regard.
B.5. No Routers
The LH-DMHA protocol does not support alerting mobile routers.
Expires March 2002 [Page 46]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
The LH-DMHA protocol conforms to RFC3154 with this regard.
B.6. Multiple Dormant Modes
It is possible for a Host running LH-DMHA protocol to have multiple
dormant modes. An example for such usage is described in Appendix "An
LH-DMHA implementation over 802.11".
The LH-DMHA protocol conforms to RFC3154 with this regard.
B.7. Independence of Mobility Protocol
The LH-DMHA protocol is independent of any mobility protocol. It can
also support stationary dormant Hosts.
The LH-DMHA protocol conforms to RFC3154 with this regard.
B.8. Support for Existing Mobility Protocols
The LH-DMHA works with any mobility protocol. The only requirement
for existing mobility protocol is to have a capability to reduce the
frequency of mobility binding update while the Host is in dormant mode
in order to enjoy the benefit of DMHA in terms of both power saving
and reduced signaling message exchange. In addition, the LH-DMHA
protocol supports optimization for mobility management protocol in
order to perform paging registration and mobility binding update at
the same time in a single message. The LH-DMHA protocol conforms to
RFC3154 with this regard.
B.9. Dormant Mode Termination
Upon receipt of a page (either with or without an accompanying L3
packet), the LH-DMHA forces a Host to execute the steps in its
mobility protocol to re-establish a routable L3 link with the
Internet. The LH-DMHA protocol conforms to RFC3154 with this regard.
B.10. Network Updates
The LH-DMHA has a paging area update mechanism in which Paging Agent
advertises paging area information and a dormant Host is able to
directly or indirectly inform Tracking Agent what paging area it is in
when when it changes paging area. The LH-DMHA protocol conforms to
RFC3154 with this regard.
B.11. Efficient Utilization of L2
One of the design policies of the LH-DMHA protocol is utilizing
underlying L2 paging mechanisms as much as possible. It is able for
the LH-DMHA protocol to use L2 paging mechanism in paging operation
and L2 paging area update mechanism in paging area update operation.
In addition, the LH-DMHA has a mechanism to advertise a capability set
in order to efficiently utilize L2. The LH-DMHA protocol conforms to
RFC3154 with this regard.
Expires March 2002 [Page 47]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
B.12. Orthogonality of Paging Area and Subnets
The LH-DMHA allows an arbitrary mapping between subnets and paging
areas. The LH-DMHA protocol conforms to RFC3154 with this regard.
B.13. Future L3 Paging Support
The LH-DMHA does not require L2 support for paging. For example,
the LH-DMHA works over 802.11 LANs that do not have paging.
The LH-DMHA protocol conforms to RFC3154 with this regard.
B.14. Robustness Against Failure of Network Elements
The LH-DMHA protocol supports Keep-Alive mechanism between peering
Agents. The protocol also supports for having multiple backup Agents
in order to avoid creating a single point of failure. The LH-DMHA
protocol conforms to RFC3154 with this regard.
B.15. Reliability of Packet Delivery
The LH-DMHA runs over unreliable transport (i.e., UDP). However, it
supports retransmission and acknowledgement mechanism at application
layer in order to increase the level of reliable delivery of messages.
The LH-DMHA protocol conforms to RFC3154 with this regard.
B.16. Robustness Against Message Loss
The LH-DMHA protocol has retransmission and acknowledgement mechanism,
it is fairly robust against message loss. The LH-DMHA protocol
conforms to RFC3154 with this regard.
B.17. Flexibility of Administration
The LH-DMHA supports automatic configuration of paging area
identifiers to be advertised from Paging Agents. The configuration at
each Paging Agent is controllable by Tracking Agents. The LH-DMHA
protocol conforms to RFC3154 with this regard.
B.18. Flexibility of Paging Area Design
LH-DMHA supports flexible design of Paging Areas. For example, it
supports both fixed and dynamically customized Paging Areas. It
provides ways for hosts and networks to exchange customized
information regarding Paging Areas which in turn allows any current or
future paging area composing algorithm to be for determining how
paging areas should be composed. DPAC is an existing paging area
composing algorithm which is supportable in this protocol by using
Extensible Paging Scheme TLV. It allows different paging area
composing algorithms to be used in different parts of a network
provider's network as well as in different network providers'
networks. It supports arbitrary location update mechanisms and paging
algorithms.
Expires March 2002 [Page 48]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
B.19. Availability of Security Support
LH-DMHA provides an authentication mechanism (LH-DMHA authentication)
which is equivalent to the one provided by IPsec AH. LH-DMHA does not
have a mechanism to encrypt messages, but allows the use of IPsec ESP
if available. The LH-DMHA protocol conforms to RFC3154 with this
regard.
B.20. Authentication of Paging Location Registration
The LH-DMHA provides a way to authenticate LH-DMHA messages used for
paging registration operation with replay protection. The LH-DMHA
protocol conforms to RFC3154 with this regard.
B.21. Authentication of Paging Area Information
The LH-DMHA protocol provides a mechanism for authenticating paging
area information distributed by the Paging Agent. The LH-DMHA
protocol conforms to RFC3154 with this regard.
B.22. Authentication of Paging Messages
The LH-DMHA protocol provides a mechanism for authenticating Paging
messages generated by Dormant Monitoring Agent and distributed by
Paging Agents. The LH-DMHA protocol conforms to RFC3154 with this
regard.
B.23. Paging Volume
Since only authenticated Paging message is processed, neither access
to any legitimate Host is denied nor performance of the Host is
degraded. The LH-DMHA protocol conforms to RFC3154 with this regard.
B.24. Parsimonious Security Messaging
The additional power consumption for authenticating the message at dormant
Hosts depends on the calculation complexity of HMAC-MD5.
B.25. Noninterference with Host's Security Policy
The LH-DMHA does not impose any limitations on a Host's security
policies.
B.26. Noninterference with End-to-end Security
The LH-DMHA protocol does not impose any limitations on a Host's
ability to conduct end-to-end security. The LH-DMHA protocol conforms
to RFC3154 with this regard.
B.27. Detection of Bogus Correspondent Nodes
Expires March 2002 [Page 49]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
The LH-DMHA protocol allows a Dormant Monitoring Agent for filtering
out paging trigger packets originated from a specific set of
correspondent nodes. The LH-DMHA protocol conforms to RFC3154 with
this regard.
C. Main Changes from the Previous Version
o This appendix is added.
o Abstract is modified.
o In section "Terminology", the definition of "Last Hop Subnet" is
modified.
o A new terminologies "Agent" and "Session" is added to section
"Terminology".
o In section "DMA Discovery", a statement is added so that a Host is
able to send a DMA Solicitation message whenever it wakes up from
dormant mode for detecting a subnet change.
o In section "Advertising Paging Area Information", the first sentence
is modified in order to indicate that paging area information
advertisement is not mandatory.
o In section "Capability Set", the first sentence is changed from "A
DMA Advertisement message contains a set of capabilities that is
supported by the advertising Dormant Monitoring Agent" to
"A DMA Advertisement message contains a set of
capabilities that is supported by the network".
o In section "Capability Set", the word "Heuristic paging" is replaced
with "non-mandatory paging area update" and more detailed description
is added.
o In section "Capability Set", a new capability "optimization for
mobility management protocol" is added.
o In section "Supporting Mobility Management Protocol", the usage of
the capability of optimization for mobility management protocol is
added. According to this, a new TLV "Optimization Request" is added
in section "Message Format".
o In section "Paging Area Update", a statement is added for the case
Expires March 2002 [Page 50]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
in which TA Registration ACK message is not necessary for a TA
Registration message sent from a Host when the network supports the
capability of "non-mandatory paging area update" described in section
"Capability Set".
o In section "Message Format", A-flag is added in message header.
o In sections "DMA Registration Message", "DMA Registration ACK
Message" and "TA Registration ACK Message" , a Paging Area List TLV is
allowed to carry multiple paging area identifiers while only a single
paging area identifier was allowed in the previous version.
o Sections "Keep-Alive", "Keep-Alive Message" and "Keep-Alive ACK
Message" are added in order to support keep-alive.
o Sections "Configuring Paging Areas", "Op-code TLV", "Paging Area
Configuration Message" and "Paging Area Configuration ACK Message",
are added in order to support automatic paging area configuration.
o In section "End-to-end Authentication Data TLV", the format of
End-to-end Authentication Data TLV is changed so that multiple
authentication algorithms are supported in the future. However,
HMAC-MD5 is the only algorithm supported by this protocol.
o In sections "End-to-end Authentication Data TLV" and "Hop-by-hop
Authentication Data TLV", the calculation rule of ICV is changed.
o "Vendor Specific Extension TLV" is added.
o "Extensible Paging Scheme TLV" is added.
o Section "Protocol State Information" is added.
o More detailed explanation is added to Section "Security
Consideration".
o Appendix "Support for Existing Mobility Protocols" are updated so
that added capability of "optimization for mobility management
protocol" is reflected.
o Appendixes "Robustness Against Failure of Network Elements" and
"Flexibility of Administration" are updated so that added capabilities
of Keep-Alive and Paging Area Configuration are reflected.
Expires March 2002 [Page 51]
Internet-Draft Last Hop DMHA Protocol September 12, 2001
o In appendix B, section for "Flexibility of Paging Area Design" was
missing and thus added to the current version of document.
Expires March 2002 [Page 52]