NETLMM Working Group R. Koodli Internet-Draft Starent Networks Intended status: Standards Track J. Laganier Expires: January 4, 2009 DOCOMO Euro-Labs July 3, 2008 Path and Session Management in Proxy Mobile IPv6 draft-koodli-netlmm-path-and-session-management-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 4, 2009. Abstract In a distributed network environment such as a Proxy Mobile IPv6 domain, it is often necessary to know that a peer is alive and, if not, detect quickly that a peer has failed and subsequently re- started. It is also necessary to detect failures where only a subset of the existing mobility sessions are affected. Furthermore, failure indication should be possible without waiting for an explicit query from a peer. This document outlines a protocol to address such path and session reliability for Proxy Mobile IPv6. Koodli & Laganier Expires January 4, 2009 [Page 1] Internet-Draft Path and Session Management July 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Conceptual Data Structures Extensions . . . . . . . . . . . . 5 4.1. Binding Cache Entry Data Structure Extension . . . . . . . 6 4.2. Binding Update List Entry Data Structure Extension . . . . 6 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Mobility Options . . . . . . . . . . . . . . . . . . . . . 7 5.1.1. Restart Counter Mobility Option . . . . . . . . . . . 7 5.1.2. Session Set Identifier Mobility Option . . . . . . . . 8 5.1.3. MN-Identifier Mobility Option . . . . . . . . . . . . 9 6. Protocol Configuration Variables . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Koodli & Laganier Expires January 4, 2009 [Page 2] Internet-Draft Path and Session Management July 2008 1. Introduction Proxy Mobile IPv6 [pmipv6] describes the protocol operations to maintain reachability and session persistence for a Mobile Node (MN) without the explicit participation from the MN in signaling operations at the Internet Protocol (IP) layer. In order to facilitate the network-based mobility, the PMIPv6 protocol defines a Mobility Anchor Gateway (MAG), which acts as a proxy for the Mobile IPv6 [rfc3775] signaling, and the Local Mobility Anchor (LMA) which acts similar to a Home Agent. The LMA and the MAG estalish a bidirectional tunnel for forwarding all data traffic belonging to the Mobile Nodes. In a distributed environment such as a PMIPv6 domain consisting of LMA and MAGs, it is often necessary to quickly inform peers of entire node failures and failure of a subset of PMIPv6 sessions in the event of partial failure of a node. Furthermore, when packets arrive, but no session (i.e., Binding Cache Entry) exists for a specific MN due to a failure, a node needs to inform the peer about the concerned MN's (absence of) session. These actions are necessary in addition to exchanging periodic "hello" messages to verify that a peer is alive. This document defines a protocol to achieve the above requirements. In this "Path And Session Management", we address the following: o Quick indication of full or partial node failures o Indication of affected PMIPv6 sessions o Indication of absence of a (previously present) BCE for a particular MN, and o Periodic exchange of "hello" messages between peers for verifying reachability Similar problems are addressed in a system such as the one described in [3GPP-GTP]. A PMIPv6-based system, such as the one described in [3GPP-PMIP] is expected to address the above problems. 2. Terminology 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 [RFC2119]. Koodli & Laganier Expires January 4, 2009 [Page 3] Internet-Draft Path and Session Management July 2008 The document uses the terminology specified in [pmipv6] and in [rfc3775]. In addition, this document defines the following: Full Node Failure: A failure in which an entire node, such as an LMA or a MAG, undergoes failure. Partial Node Failure: A failure in which part of a node, such as a network interface card or a storage disk, undergoes failure that affects a subset of the PMIPv6 sessions. Node Echo Request (NERQ): A message sent by a PMIPv6 node to verify if its peer is alive and reachable Node Echo Reply (NERP): Either a reply to the NERQ message, or sent unsolicited. Contains such information as affected sessions, a specific MN's BCE etc. Session Set Identifier: An identifier used by a PMIPv6 peer to represent to its peer a (potentially large) set of PMIPv6 sessions (i.e., Binding Cache Entries, or Binding Update List Entries). When sent in a NERP message, indicates that those PMIPv6 sessions are affected. When sent in a PBU or a PBA, indicates that the PMIPv6 session being established belongs to the corresponding set of PMIPv6 sessions on the sending side. 3. Protocol There are two modes in which the protocol operates. In the 'solicited mode', a node sends a NERQ message to its peer every NERQ_PERIOD seconds, and expects a NERP message as a response. This mode, similar to that in [3GPP-GTP], is used to verify that a peer is alive and that the path to the peer is working. In the 'unsolicited mode', a node sends a NERP message to its peer without being first prompted by a NERQ message. This mode is used to quickly indicate to the peer about full or partial failures. For instance, when a node re-starts after a failure, it can immediately send an unsolicited NERP message without first waiting for the NERQ message. As another instance, a node whose storage containing a set of PMIPv6 sessions has been affected by a failure can send an unsolicited NERP message with a suitable Session Set Identifier (defined in Section 2). Both NERQ and NERP contain a variable called Restart Counter [3GPP-GTP] in both the modes of operation. If the received value of Restart Counter in a NERP message matches the Restart Counter value sent in the corresponding NERQ message, then the peer is alive and the state at both the peers is consistent since the last re-start (of Koodli & Laganier Expires January 4, 2009 [Page 4] Internet-Draft Path and Session Management July 2008 either of the peers). If the received Restart Counter value is higher than the one in the sent NERQ message, the receiving node MUST assume that the sender (of NERP message) has re-started. Subsequently, the nodes may need to take actions to synchronize their state, and these actions are beyond the reach of this specification. After recovering from a Full Node Failure, a node SHOULD immediately send an unsolicited NERP (U-NERP) message without waiting for a NERQ message. The U-NERP message MUST contain a new value for the Restart Counter incremented from its previous value. If the node receives a NERQ message after it has sent a U-NERP message, it MUST still respond with a corresponding NERP message. The receiving node MUST store the new Restart Counter corresponding to its peer. No reply to U-NERP is necessary; the nodes will exchange the messages once the NERQ_PERIOD expires at either one of them. After detecting that a Partial Node Failure has affected a subset of its PMIPv6 sessions, a node SHOULD immediately send a U-NERP message without waiting for a NERQ message. The U-NERP message MUST contain a Session Set Identifier that represents the affected sessions. More than one Session Set Identifier may be present. A given Session Set Identifier is associated to the corresponding set of PMIPv6 sessions thanks to the the Session Set Identifiers present in the extended data structures (see Section 4) which were exchanged in the PBU/PBA exchange that occured at the time the session is established. The Restart Counter MUST be the same as previously exchanged. When a node receives a U-NERP message whose Restart Counter is the same as the locally stored value and a Session Set Identifier is present, the receiver determines that it is a partial failure. It subsequently takes action to synchronize its state corresponding to the affected sessions. Again, the specific actions are beyond the scope of this document. No response to U-NERP is necessary. Due to a full or partial failure, a node may no longer have session information (i.e., BCE) for some MN. When a packet from its peer for such a MN is received (e.g., LMA receives a packet from a MAG), the node SHOULD immediately send a U-NERP message containing the MN- Identifier. This informs the peer of the absence of a BCE for the MN identified by the MN-Identifier. The Restart Counter MUST be the same as previously exchanged. The receiving node then takes actions to synchronize its state corresponding to the affected MN, and such actions are beyond the scope of this document. 4. Conceptual Data Structures Extensions This sections details the extensions that this specification Koodli & Laganier Expires January 4, 2009 [Page 5] Internet-Draft Path and Session Management July 2008 introduces to the Binding Cache Entry data structure on the local mobility anchor and to the Binding Update List Entry data structure on the mobile access gateway. 4.1. Binding Cache Entry Data Structure Extension Every local mobility anchor maintains a Binding Cache entry for each currently registered mobile node as described in Section 5.1 of the PMIPv6 specification [pmipv6]. This specification extends the Binding Cache Entry data structure with the following additional fields: o The Local Session Set Identifier to which the PMIPv6 session belongs locally (i.e. on the local mobility anchor). o The Remote Session Set Identifier to which the PMIPv6 session belongs on the remote PMIPv6 peer (i.e. the mobile access gateway). 4.2. Binding Update List Entry Data Structure Extension Every mobile access gateway maintains a Binding Update List. Each Entry in the Binding Update List represents a mobile node's mobility binding with its local mobility anchor, as described in Section 6.1 of the PMIPv6 specification [pmipv6]. This specification extends the Binding Update List Entry data structure with the following additional fields: o The Local Session Set Identifier to which the PMIPv6 session belongs locally (i.e. on the mobile access gateway). o The Remote Session Set Identifier to which the PMIPv6 session belongs on the remote PMIPv6 peer (i.e. the local mobility anchor). 5. Message Formats Both NERQ and NERP use the same message format shown below. The Type value in the Mobility Header message identifies them as a NERQ or a NERP message. Koodli & Laganier Expires January 4, 2009 [Page 6] Internet-Draft Path and Session Management July 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|U| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Node Echo Request and Node Echo Reply Messages 'R' flag: Set to 0 in NERQ message and set to 1 NERP message. 'U' flag: Set to 1 in Unsolicited NERP. Otherwise set to 0. Reserved: This field is unused. MUST be set zero. Sequence Number: A monotonically increasing integer. Set by a sending node in a request message, and used to match a reply to the request. Ignored in an Unsolicited NERP message (i.e., when 'U' is set to 1). Mobility Options: MUST contain the Restart Counter mobility option in each NERQ, NERP and U-NERP message sent. A NERP message MAY contain the Session Identifier mobility option and a MN-identifier mobility option. See below. 5.1. Mobility Options 5.1.1. Restart Counter Mobility Option The format of Restart Counter mobility option is shown below. It MUST be present in the NERQ, NERP and U-NERP messages. The alignment requirement for this option is 4n+2. Koodli & Laganier Expires January 4, 2009 [Page 7] Internet-Draft Path and Session Management July 2008 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Restart Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Restart Counter Mobility Option Type: Indicates that the option is a Restart Counter mobility option. Length: Length of the option in bytes not including the Type and Length fields. Restart Counter: A 32-bit integer corresponding to the Restart Counter value stored locally for the peer. Set to 0 when the value is not available, and the peer returns the value to be used in subsequent request messages. 5.1.2. Session Set Identifier Mobility Option The format of the Session Set Identifier mobility option is shown below. The alignment requirement for this option is 4n+2. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Set Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Session Set Identifier Mobility Option Type: Indicates that the option is a Session Set Identifier mobility option. Length: Length of the option in bytes not including the Type and Length fields. Session Set Identifier: a 32-bit integer that identifies a set of PMIPv6 sessions that are affected due to a failure. Koodli & Laganier Expires January 4, 2009 [Page 8] Internet-Draft Path and Session Management July 2008 5.1.3. MN-Identifier Mobility Option The format of this option is exactly same as that defined in [pmipv6]. 6. Protocol Configuration Variables The document defines the following configuration variable with a default value as suggested: NERQ_PERIOD 60s A NERQ message MUST NOT be sent at a rate faster than NERQ_PERIOD. 7. Security Considerations The protocol specified in this document uses the same security association between the LMA and the MAG to protect the NERQ and NERP messages. No new security risks are identified since the messages are meant for quick recovery and liveness checking. Support for integrity protection using IPsec is required, but support for confidentiality is not necessary. 8. IANA Considerations The Node Echo Request (NERQ), Node Echo Reply (NERP) and Unsolicited NERP messages described in Figure 1 need a single Type allocation from the Mobility Header Types registry at http://www.iana.org/assignments/mobility-parameters: The Restart Counter Mobility Option, Session Set Identifier Mobility Option and the MN-Identifier Mobility Option all need separate Type assignment from the Mobility Options registry at http://www.iana.org/assignments/mobility-parameters 9. Acknowledgments A concept similar to the Session Set Identifier to represent a set of "PDN Connections" was presented in document C4-081559 at the 3GPP CT4 group meeting in Zagreb, Croatia, June 2008. This document uses Session Set Identifier to refer to a set of PMIPv6 sessions. Koodli & Laganier Expires January 4, 2009 [Page 9] Internet-Draft Path and Session Management July 2008 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [pmipv6] Gundavelli, S. and al. et, "Proxy Mobile IPv6", May 2008. [rfc3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004, . 10.2. Informative References [3GPP-GTP] 3rd Generation Partnership Program (3GPP) TS 29.274, "General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface (Release 8)". [3GPP-PMIP] 3rd Generation Partnership Program (3GPP) TS 29.275, "Proxy Mobile IPv6 (PMIPv6) based Mobility and Tunnelling protocols; Stage 3 (Release 8)". Authors' Addresses Rajeev Koodli Starent Networks USA Email: rkoodli@starentnetworks.com Julien Laganier DOCOMO Euro-Labs Landsbergerstrasse 312 Munich, D-80687 Germany Email: julien.IETF@laposte.net Koodli & Laganier Expires January 4, 2009 [Page 10] Internet-Draft Path and Session Management July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Koodli & Laganier Expires January 4, 2009 [Page 11]