NETLMM Working Group Rajeev. Koodli
Internet-Draft Kuntal. Chowdhury
Intended status: Standards Track Starent Networks
Expires: January 5, 2009 July 4, 2008
Local Forwarding in Proxy Mobile IPv6
draft-koodli-netlmm-local-forwarding-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 5, 2009.
Abstract
With bidirectional tunneling in Proxy Mobile IPv6, the communication
between any two Mobile Nodes is required to traverse the Local
Mobility Anchor (LMA). This is the case even when the communicating
Mobile Nodes are attached to the same Mobility Anchor Gateway (MAG).
This document introduces two messages between the LMA and the MAG
enabling local forwarding by the MAG. Such forwarding avoids the
delay due to bidirectional forwarding, and reduces the traffic load
on the LMA.
Koodli & Chowdhury Expires January 5, 2009 [Page 1]
Internet-Draft Local Forwarding July 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Extending to Inter-MAG Local Forwarding . . . . . . . . . . . 5
5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Local Forwarding Request (LFRQ) . . . . . . . . . . . . . 6
5.2. Local Forwarding Reply (LFRP) . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Koodli & Chowdhury Expires January 5, 2009 [Page 2]
Internet-Draft Local Forwarding 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 tunneling for forwarding all data traffic belonging to
the Mobile Nodes. This bidirectional tunneling is used even when the
communicating MNs are attached to the same MAG, or are attached to
two different MAGs in the same access network. This method of
forwarding always relies on the transport network (between the MAG
and the LMA) which could be the bottleneck in terms of delay and
cost. Furthermore, distributing the load to the network periphery
whenever feasible could also achieve load balancing within the PMIPv6
network domain.
This document provides a pair of messages between the LMA and the MAG
to enable local forwarding of traffic without the involvement of LMA.
The LMA sends a Local Forwarding Request (LFRQ) message to request a
MAG to establish local forwarding for a pair of mobile nodes
identified by their MN-Identifiers and Home Network Prefixes. The
MAG indicates the resolution of LFRQ message in the Local Forwarding
Reply (LFRP) message, confirming local forwarding when it is able to
establish Local Forwarding Entries. Subsequently, all the traffic
matching the HNP is forwarded locally, without traversing the
bidirectional tunnel with the LMA. Since HNP is used to identify
candidate traffic for local forwarding, the protocol allows the
flexibility of choosing a subset of the traffic for local forwarding,
while the rest of the traffic is allowed to traverse bidirectional
tunneling.
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].
The document uses the terminology specified in [pmipv6] and in
[rfc3775]. In addition, this document defines the following:
Local Forwarding: Data forwarding my a MAG without using the
bidirectional tunnel with the LMA.
Koodli & Chowdhury Expires January 5, 2009 [Page 3]
Internet-Draft Local Forwarding July 2008
Local Forwarding Request (LFRQ): A message sent by the LMA
requesting a MAG to establish local forwarding for a pair of
Mobile Nodes.
Local Forwarding Reply (LFRP): A reply from the MAG to the LMA
containing the resolution of LFRQ message.
3. Protocol
The protocol specified here assumes that both the LMA and the MAG
have established bindings for the communicating Mobile Nodes using
the PBU and PBA messages specified in [pmipv6]. Subsequently, a
trigger at the LMA identifies a flow between two mobile nodes
attached to the same MAG. The exact flow identification mechanism is
not specified in this document, and is left open for implementations
and specific deployments. An example trigger could be that an
application-layer signaling entity (such as a SIP Proxy) notifies the
LMA of a VoIP flow end-points, and the latter determines that the two
end-points are attached to the same MAG. Such a trigger mechanism
offers local forwarding at the granularity of an individual
application session, providing flexibility in usage. This and other
possible examples serve to illustrate the trigger mechanism for
initiating local forwarding.
As a response to the trigger, the LMA constructs a Local Forwarding
Request (LFRQ) message assuming the local policy is so configured.
This Mobility Header message contains the MN-Identifier and the Home
Network Prefix (as Mobility Header options) for each of the Mobile
Nodes involved. The LMA sends the LFRQ message to the MAG supporting
the two MNs.
The MAG verifies that the two MNs are indeed attached to itself. It
then creates Local Forwarding Entries for each direction of the
communication between the two MNs. The exact form of the forwarding
entries is implementation (and system) dependent; however, they
should contain the HNP corresponding to the destination IP address
and a next-hop identifier (such as the layer 2 address of the next-
hop which is known to ensure forwarding of packets to the
destination). These LFEs MUST override the BUL entries for the
specific HNPs identified in the LFRQ message. Hence all traffic
matching the HNPs is forwarded locally.
The local forwarding is not permanent. For instance, the LMA may
send a LFRQ message with a request to cancel an existing local
forwarding service. Such a message may be generated as a result of
Koodli & Chowdhury Expires January 5, 2009 [Page 4]
Internet-Draft Local Forwarding July 2008
termination of a VoIP session. The local forwarding also has a
default lifetime, upon the expiry of which, the forwarding reverts to
bidirectional tunneling. When local forwarding service ceases, the
corresponding LFE entries MUST be removed.
The MAG provides a resolution of the LFRQ processing in the Local
Forwarding Reply (LFRP) message. This Mobility Header message
includes the MN-IDentifier and the HNP for each of the communicating
MNs as well as an appropriate Status code disposing the outcome of
LFRQ processing. Status code 0 indicates local forwarding is offered
by the MAG. Any other value for Status code indicates the reason for
not offering the local forwarding service. When Status code is 0,
the LMA adds an 'F' flag to the BCE corresponding to the HNPs to
record that local forwarding is in progress.
The MAG may refresh the lifetime of an existing local forwarding
service. For this, it sends an unsolicited LFRP (U-LFRP) message
that contains the new lifetime value. The MAG MUST wait for the
following LFRQ message from the LMA before it can conclude that the
refresh request is granted.
4. Extending to Inter-MAG Local Forwarding
The LMA may choose to support local forwarding to mobile nodes
attached to two different MAGs within a single PMIPv6 domain. As
earlier, the LMA initiates LFRQ as response to some trigger
mechanism. In this case, however, it sends two separate LFRQ
messages to the two MAGs. In addition to the MN-ID and the HNP
options, each LFRQ message contains the IP Address of the counterpart
MAG. When the MAG IP Address option is present, each MAG MUST create
a local forwarding entry such that the packets for the MN attached to
the remote MAG are sent over a tunnel associated with that remote
MAG. The tunnel between the MAGs is assumed to be established by
means outside the scope of this document.
As before, each MAG responds to the LFRQ with an LFRP message.
Barring the wrror cases, all subsequent packets are routed between
the MAGs locally, without traversing the LMA.
The protocol does not require any synchronization between the MAGs
before local forwarding begins. Each MAG begins its local forwarding
independent of the other.
5. Message Formats
Koodli & Chowdhury Expires January 5, 2009 [Page 5]
Internet-Draft Local Forwarding July 2008
5.1. Local Forwarding Request (LFRQ)
The LMA sends an LFRQ message to a MAG to request local forwarding
for a pair of MNs.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|C| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Local Forwarding Request (LFRQ) Message
Sequence Number: A monotonically increasing integer. Set by a
sending node in a request message, and used to match a reply to
the request.
'R' flag: Set to 0, indicates it is an LFRQ message.
'C' flag: When set to 1, indicates a request to cease local
forwarding
Reserved: This field is unused. MUST be set zero.
Lifetime: The requested time in seconds for which the sender
wishes to have local forwarding.
Mobility Options: MUST contain the MN-ID, followed by one or more
HNPs for each of the MNs. For instance, for Mobile Nodes MN-1 and
MN-2 with identifiers MN-ID1, MN-ID2 and Home Network Prefixes
HNP-MN-1 and HNP-MN-2, the following tuple in the following order
MUST be present: [MN-ID1, HNP-MN-1], [MN-ID2, HNP-MN-2]. The
MN-ID and HNP options are the same as in [pmipv6]. MAY contain
the remote MAG IPv6 address option, which is identical to the HNP
option except for Prefix Length equal to 128 bits.
Koodli & Chowdhury Expires January 5, 2009 [Page 6]
Internet-Draft Local Forwarding July 2008
5.2. Local Forwarding Reply (LFRP)
The MAG sends an LFRP message to the LMA as a response to the LFRQ
message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|U| Reserved | Status | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Local Forwarding Reply (LFRP) Message
Sequence Number: A monotonically increasing integer. Set by a
sending node in a request message, and used to match a reply to
the request.
'R' flag: Set to 1, indicates it is an LFRP message.
'U' flag: When set to 1, the LFRP message is sent unsolicited.
The Lifetime field indicates a new requested value. The MAG MUST
wait for the regular LFRQ message to confirm that the request is
acceptable to the LMA.
Reserved: This field is unused. MUST be set zero.
Status:
0: Success
1: Failure, one or more MN bindings do not exist
Koodli & Chowdhury Expires January 5, 2009 [Page 7]
Internet-Draft Local Forwarding July 2008
2: Failure, unable to establish local forwarding with the
remote MAG
Lifetime: The time in seconds for which the local forwarding is
supported. Typically copied from the corresponding field in the
LFRQ message.
Mobility Options: When Status code is 0, MUST contain the [MN-ID,
HNP] tuples in the same order as in the LFRQ message. When Status
code is 1, MUST contain only those [MN-ID, HNP] tuples for which
local forwarding is supported. The MN-ID and HNP options are the
same as in [pmipv6].
6. Security Considerations
The protocol specified in this document uses the same security
association between the LMA and the MAG to protect the LFRQ and LFRP
messages. No new security risks are identified. Support for
integrity protection using IPsec is required, but support for
confidentiality is not necessary.
7. IANA Considerations
The Local Forwarding Request, described in Section 5.1 and the Local
Forwarding Reply, described in Section 5.2 require a single Mobility
Header Type from the registry at
http://www.iana.org/assignments/mobility-parameters:
8. 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>.
Koodli & Chowdhury Expires January 5, 2009 [Page 8]
Internet-Draft Local Forwarding July 2008
Authors' Addresses
Rajeev Koodli
Starent Networks
USA
Email: rkoodli@starentnetworks.com
Kuntal Chowdhury
Starent Networks
USA
Email: kchowdhury@starentnetworks.com
Koodli & Chowdhury Expires January 5, 2009 [Page 9]
Internet-Draft Local Forwarding 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 & Chowdhury Expires January 5, 2009 [Page 10]