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,
<ftp://ftp.isi.edu/in-notes/rfc3775>.
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]