Internet-Draft Yoshihiro Ohba Expires: January, 2002 Nobuyasu Nakajima Toshiba America Research, Inc. Tao Zhang Telcordia Technologies July 13, 2001 Last Hop DMHA (Dormant Mode Host Alerting) Protocol 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 used in the "last hop" networks to support alerting of dormant mode hosts. The proposed protocol conforms with the DMHA (Dormant Mode Host Alerting) protocol requirements discussed in the IETF Seamoby WG, in that it is independent of any mobility management protocol. This protocol supports mobile hosts as well as stationary hosts, provided that a dormant host is able to detect a change in L2, e.g., a change in L2 paging area or a change in L2 attachment point. Expires January 2002 [Page 1] Internet-Draft Last Hop DMHA Protocol July 13, 2001 1. Terminology The following terminology is defined in this document. Host A standard IP host in the sense of STD0003, with an additional capability to enter dormant mode. Paging Server An entity that locates in the same subnet that the Host is connecting to, and has functionalities of both DMA (Dormant Monitoring Agent) and PA (Paging Agent) [1]. Last Hop Subnet 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 paging is alerting a dormant Host when there is an incoming packet to the Host. Last Hop The final hop for a packet to reach a Host on the Last Hop Subnet. 2. Protocol Overview The Last Hop Dormant Mode Host Alerting (LH-DMHA) is a client-server type protocol in which a Host acts as a client and a Paging Server acts as a server. A Paging Server can either be co-located with a last hop router or be a separate box. In the latter case, legacy routers can be used as it is. When a Host which is in active mode decides to enter a dormant mode, it performs paging registration to a Paging Server by sending a Registration message to the Paging Server, specifying at least the hardware address of the interface that is going to be dormant and the lifetime of the registration. The Paging Server then registers the information specified in the received Registration message and returns a Registration ACK message to the Host. The Paging Server also monitors the packets on the subnet, and when it captures a packet that is worth awaking the registered dormant Host, it performs paging. The paging is performed either by triggering L2 paging if the L2 supports it, or by forwarding the Expires January 2002 [Page 2] Internet-Draft Last Hop DMHA Protocol July 13, 2001 packet to the Host in a way that is receivable by the Host. Anyway, paging is performed without using an explicit L3 signaling message. 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 the paging operation, it performs paging deregistration. Paging deregistration is performed in the same way as paging registration except that the lifetime is set to be zero. The protocol conforms with [1] in that it is independent of any mobility management protocol. (On the other hand, the protocol could also be used as a last hop part of a paging protocol (such as [2]) that is dependent on a specific mobility management protocol, though we do not recommend such a usage.) This protocol supports mobile Hosts as well as stationary Hosts, provided that a dormant Host is able to detect a change in L2, e.g., a change in L2 paging area or a change in L2 attachment point. See section 3.9 for details. This version of the document does not yet specify a method to authenticate the message exchange. Next version will come with security support. 3. Protocol Description 3.1. Transport The LH-DMHA uses UDP as its transport for paging server advertisement and paging registration. The UDP port number is TBD. 3.2. Paging Server Advertisement A Paging Server periodically multicasts a Advertisement message on the subnet by using multicast. The scope of the multicast is limited within the advertising subnet. The multicast address for IPv4 is TBD. The multicast address for IPv6 is TBD. A Host joins the multicast group to listen to the Advertisement messages from the Paging Server. When a Host receives an Advertisement while it is in active mode, it registers the source IP address of the Advertisement as the Paging Server address. Alternatively, a Host can manually configure the Paging Server address if it is previously known. 3.3. Paging Registration Before a Host enters a dormant mode, it sends a Registration message to the Paging Server and waits for an Registration ACK message. A Expires January 2002 [Page 3] Internet-Draft Last Hop DMHA Protocol July 13, 2001 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 Paging Server then registers the specified information in the received Registration message and returns a Registration ACK message to the Host. The Registration ACK message contains a status indicating whether the registration is successful or not, the hardware address of the Host that sent the Registration message and the lifetime. The lifetime contained in the Registration ACK message can be different from that is specified by the Host if the specified value is out of the range that the Paging Server is supporting. When the Host that is waiting for an ACK receives the Registration ACK from the Paging Server with a status indicating successful registration , it is able to enter a dormant mode. To refresh the paging registration state, the registered Host sends a Registration message to the Paging Server before the next lifetime expires. The Host SHOULD retransmit the Registering message until Registration ACK or Notification message is received from the Paging Server. If ARP is used in the last hop subnet, the following consideration is needed. o The Paging Server MUST NOT delete its ARP 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 cache entries while it is in dormant mode, as those entries will not be updated and thus will become obsolete. 3.4. Paging Deregistration At the time a Host exits a dormant mode, it sends a Registration message to the Paging Server with specifying the lifetime of zero. The Paging Server then removes the entry for the Host from its database and returns a Registration ACK message to the Host with specifying the lifetime of zero. Note that the Host can enter the active mode before it receives a Registration ACK message for paging deregistration, or even before it sends a Registration message. 3.5. Monitoring Paging Trigger Packets A Paging Server monitors the subnet to which the Hosts are connected Expires January 2002 [Page 4] Internet-Draft Last Hop DMHA Protocol July 13, 2001 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 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. When the Host specifies a set of trigger packets in the Register message, it 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 INVITE message destined for the Host is received at the last hop router, provided that the Paging Server is co-located with the last hop router. 3.6. Paging When a Paging Host captures a paging trigger packet, it takes one of the following actions: o If the underlying L2 technology supports L2 paging, the Paging Server triggers the L2 paging for the registered hardware address. If the control channel used for L2 paging channel supports carrying data packets, the trigger packet is forwarded on the control channel. Otherwise, the captured trigger packets is buffered until the L2 paging completes, and then forwarded on the traffic channel after the completion of L2 paging. o If the underlying L2 technology does not support L2 paging, the Paging Server MUST forward the packet on the traffic channel in a way that is receivable by the dormant host. When the dormant Host eventually receives the trigger packet, it performs paging deregistration. 3.7. 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 Expires January 2002 [Page 5] Internet-Draft Last Hop DMHA Protocol July 13, 2001 same hardware address. To support this, the Paging Server MUST be able to handle multiple IP addresses per hardware address. Last Hop Paging support for this case will be described in detail in the next version. 3.8. 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 Paging Server 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 Paging Server. The Paging Server 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 Paging Server MUST be able to handle multiple hardware addresses per IP address. Last Hop Paging support for this case will be described in detail in the next version. 3.9. Supporting Mobility 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. Dormant host alerting for mobile Hosts is supported in the following way. o In order for a mobility management protocol to enjoy the benefit of DMHA in terms of both power saving and reduced signaling message exchange, the mobility management protocol should have a capability to reduce the frequency of mobility binding update. In addition, if a Host is running a mobility management protocol that has such a capability, the Host should perform an action to reduce the frequency of mobility binding update before it enters a dormant mode. o If underlying L2 does not support paging, a dormant Host should check whether the subnet has changed, when one of the following cases occurs. a) The L2 is a wireless link and there is a change in Base Station or Access Point. b) The L2 is wired link and the wire is detached and then connected again. If the Host detects a change in subnet, it performs paging Expires January 2002 [Page 6] Internet-Draft Last Hop DMHA Protocol July 13, 2001 registration to the Paging Server on the new subnet. In addition, if the Host is running a mobility management protocol, it also performs mobility binding update. o If underlying L2 supports paging, a dormant Host is assumed to have a capability to detect a change in L2 paging area and inform the L2 location registrar of the change. If the Host detects a change in L2 paging area, it checks whether the subnet has also changed, and if a subnet change is detected, it performs paging registration to the Paging Server on the new subnet. In addition, if the Host is running a mobility management protocol, it also performs mobility binding update. o Whenever a Host that has been registering to a Paging Server detects a subnet change, it also performs paging deregistration to the Paging Server in the "old" subnet. Based on the discussion in [4] that a dormant Host can perform mobility binding update when it detects a change in L2, Tracking Agent [1] is not required for this protocol. 4. Message Format All messages defined in the LH-DMHA have the following structure. All fields are transmitted in network byte order. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first 4 octets are the protocol header. Version The version of the protocol. The current version is zero. Type Message type. Length Length of the Payload part in octets. The currently defined message types are shown in Table 1. Expires January 2002 [Page 7] Internet-Draft Last Hop DMHA Protocol July 13, 2001 Type Message Name ----------------------------- 0x01 Advertisement 0x02 Registration 0x03 Registration ACK ----------------------------- Table 1: Message Types 4.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. Table 2 summarizes the defined TLVs. They can appear in any order in the Payload. TLV Name Type Length ------------------------------------------ Hardware Address 0x01 Variable IP Address 0x02 Variable Lifetime 0x03 0x04 Lifetime Range 0x04 0x08 Status 0x05 0x04 Paging Trigger Packets 0x06 Variable ------------------------------------------ Table 2: TLVs 4.2.1. Hardware Address This TLV contains the hardware address of an interface of the host that is performing paging registration. The Value field of has the following format. Expires January 2002 [Page 8] Internet-Draft Last Hop DMHA Protocol July 13, 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Adders Family |Address Length | Address ... +-------------------------------+---------------+---------------+ Address Family Two octet quantity containing a value from ADDRESS FAMILY NUMBERS in RFC1700 that encodes the address family of the hardware address. Address Length The length of the Address field in octets. Address The hardware address. 4.2.2. IP Address This TLV contains an IP address of an interface of the host that is performing paging registration. The Value field of 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Adders Family |Address Length | Address ... +-------------------------------+---------------+---------------+ Address Family Two octet quantity containing a value from ADDRESS FAMILY NUMBERS in RFC1700 that encodes the address family of the IP address. It MUST be either 1 (for IPv4 address) or 2 (for IPv6 address). Address Length The length of the Address field in octets. It MUST be either 4 (for IPv4 address) or 16 (for IPv6 address). Address The IP address. 4.2.3. Lifetime This TLV contains a lifetime of the paging registration, specified in seconds. The value of zero indicates paging deregistration. Expires January 2002 [Page 9] Internet-Draft Last Hop DMHA Protocol July 13, 2001 4.2.4. Lifetime Range This TLV contains two lifetimes, the first one is the minimum lifetime and the second one is the maximum lifetime. Each lifetime contains 2-octet integer value specified in seconds. 4.2.5. Status This TLV contains the result of the paging (de)registration. The Value field contains a 4-octet integer. A value of zero indiciates successful registration. Non-zero values indicates failure. More specific values for failure are to be defined. 4.2.6. Paging Trigger Packets This TLV contains a set of paging trigger packets. The format is to be defined. 4.3. LH-DMHA Messages 4.3.1. Advertisement Message An Advertisement message contains the following TLV. o Lifetime Range TLV 4.3.2. Registration Message A Registration message contains the following TLVs. o Hardware Address TLV o IP Address TLV o Lifetime TLV o Paging Trigger Packets [optional] 4.3.3. Registration ACK Message A Registration ACK message contains the following TLVs. o Hardware Address TLV o IP Address TLV o Lifetime TLV o Paging Trigger Packets [optional] o Status TLV 5. Security Consideration This version of the document does not yet have a method to authenticate the message exchange which is required for standard Seamoby IP Paging protocol [1]. Next version will come with security Expires January 2002 [Page 10] Internet-Draft Last Hop DMHA Protocol July 13, 2001 support. References [1] J. Kempf, et al., "Requirements and Functional Architecture for an IP Host Alerting Protocol", draft-ietf-seamoby-paging-requirements-01.txt, Work in Progress, May 2001. [2] M. Liebsch, et al., "Paging Concept for IP based Networks", draft-renker-paging-ipv6-00.txt, Work in Progress, June 2001. [3] "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications", IEEE Std 802.11, June 1997. [4] J. Kempf, "Dormant Mode Host Alerting ("IP Paging") Problem Statement", RFC 3132, June 2001. 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 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 January 2002 [Page 11] Internet-Draft Last Hop DMHA Protocol July 13, 2001 Appendix A: An LH-DMHA implementation over 802.11 A.1. 802.11 Power Management The power management capability of IEEE 802.11 [3] 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 January 2002 [Page 12] Internet-Draft Last Hop DMHA Protocol July 13, 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 as defined in section 2.3. 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 as defined in section 3.6. A.4. LH-DMHA over 802.11: Paging Server Implementation In this section, it is assumed that a Paging Server is connected to the last hop subnet through wired Ethernet. The Last Hop Paging 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 Paging Server'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 registered Host, and the source MAC address is changed from the original sender's hardware address to the the Paging Server's hardware Expires January 2002 [Page 13] Internet-Draft Last Hop DMHA Protocol July 13, 2001 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 Paging Server. In addition, if the Paging Server is co-located with the last hop router, 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). Expires January 2002 [Page 14]