One document matched: draft-koodli-netext-local-forwarding-00.txt
NETLMM Working Group Rajeev. Koodli
Internet-Draft Kuntal. Chowdhury
Intended status: Standards Track Starent Networks
Expires: September 2, 2009 March 2, 2009
Local Forwarding in Proxy Mobile IPv6
draft-koodli-netext-local-forwarding-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 September 2, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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
Koodli & Chowdhury Expires September 2, 2009 [Page 1]
Internet-Draft Local Forwarding March 2009
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Basic LMA-MAG scenario . . . . . . . . . . . . . . . . . . 4
3.2. Inter-MAG Local Forwarding . . . . . . . . . . . . . . . . 5
3.3. Single MAG, multiple LMAs . . . . . . . . . . . . . . . . 6
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Local Forwarding Request (LFRQ) . . . . . . . . . . . . . 6
4.2. Local Forwarding Reply (LFRP) . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Koodli & Chowdhury Expires September 2, 2009 [Page 2]
Internet-Draft Local Forwarding March 2009
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 such 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. This bidirectional tunnel 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. Similarly, a MAG may also send
the LFRQ messages to LMAs (when the two communicating Mobile Nodes
are anchored at different LMAs), and initiate local forwarding once
it receives LFRP messages from those LMAs. 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:
Koodli & Chowdhury Expires September 2, 2009 [Page 3]
Internet-Draft Local Forwarding March 2009
Local Forwarding: Data forwarding by a MAG without using the
bidirectional tunnel with the LMA.
Local Forwarding Request (LFRQ): A message sent by a node (such as
the LMA) requesting its peer (such as the MAG) to provide local
forwarding for a pair of Mobile Nodes.
Local Forwarding Reply (LFRP): A reply containing the resolution
of the LFRQ message.
3. Protocol
3.1. Basic LMA-MAG scenario
In this scenario, the two Mobile Nodes involved in communication are
attached to a single MAG and both are anchored at the same LMA.
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
Koodli & Chowdhury Expires September 2, 2009 [Page 4]
Internet-Draft Local Forwarding March 2009
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.
If a MAG is unable to make forward progress for packets using the
LFEs, it is likely that the MN has moved out of its range. Hence,
the MAG SHOULD fallback to using the BULE, and the LMA MUST forward
the received packets using its BCE. The mechanism used for
determining forward progress are implementation-dependent. The MAG
MAY use other mechanisms, such as Proxy MIP6 Fast Handovers [pfmip6]
to forward packets when there is handover.
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
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.
3.2. 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 a 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
Koodli & Chowdhury Expires September 2, 2009 [Page 5]
Internet-Draft Local Forwarding March 2009
means outside the scope of this document.
As before, each MAG responds to the LFRQ with an LFRP message.
Barring the error 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.
3.3. Single MAG, multiple LMAs
In this scenario, two Mobile Nodes are attached to the same MAG, but
are anchored at two different LMAs. Hence, each LMA has no means to
determine that the two Mobile Nodes are attached to the same MAG.
Only the MAG can possibly determine that the two Mobile Nodes
involved in communication are attached to itself. Hence the local
forwarding protocol has to be initiated by the MAG.
The MAG sends an LFRQ message containing the MN-ID, HNP and the
counterpart LMA address to each LMA. Each LMA makes decision to
support local forwarding independently, based on, among others,
policy configuration for the counterpart LMA. Each LMA MUST respond
to the LFRQ message with an LFRP message. Only when it receives both
the LFRP messages each with Status value set to zero (success) from
the two different LMAs, the MAG MUST conclude that it can provide
local forwarding support for the two Mobile Nodes.
4. Message Formats
4.1. Local Forwarding Request (LFRQ)
The LMA sends an LFRQ message to a MAG to request local forwarding
for a pair of MNs. The MAG may also send this message to request the
two LMAs for offering local forwarding Section 3.3.
Koodli & Chowdhury Expires September 2, 2009 [Page 6]
Internet-Draft Local Forwarding March 2009
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. MAY contain
the conterpart LMA IPv6 option, which is identical to the HNP
option except for Prefix Length equal to 128 bits.
The LFRQ message SHOULD be re-transmitted if a corresponding LFRP
message is not received within LFRP_WAIT_TIME time units, up to a
maximum of LFRQ_RETRIES, each separated by LFRP_WAIT_TIME time units.
Koodli & Chowdhury Expires September 2, 2009 [Page 7]
Internet-Draft Local Forwarding March 2009
4.2. Local Forwarding Reply (LFRP)
A MAG sends an LFRP message to the LMA as a response to the LFRQ
message. An LMA may also send this message to a MAG as a response to
the LFRQ message Section 3.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
2: Failure, unable to establish local forwarding with the
remote MAG
Koodli & Chowdhury Expires September 2, 2009 [Page 8]
Internet-Draft Local Forwarding March 2009
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].
5. 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.
6. IANA Considerations
The Local Forwarding Request, described in Section 4.1 and the Local
Forwarding Reply, described in Section 4.2 require a single Mobility
Header Type from the registry at
http://www.iana.org/assignments/mobility-parameters:
7. References
7.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", RFC 5213,
Aug 2008.
[rfc3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004,
<ftp://ftp.isi.edu/in-notes/rfc3775>.
7.2. Informative References
[pfmip6] Yokota, H. and et. al, "Fast Handovers for Proxy Mobile
IPv6", Mar 2009, <http://www.ietf.org/internet-drafts/
Koodli & Chowdhury Expires September 2, 2009 [Page 9]
Internet-Draft Local Forwarding March 2009
draft-ietf-mipshop-pfmipv6-02.txt>.
Authors' Addresses
Rajeev Koodli
Starent Networks
USA
Email: rkoodli@starentnetworks.com
Kuntal Chowdhury
Starent Networks
USA
Email: kchowdhury@starentnetworks.com
Koodli & Chowdhury Expires September 2, 2009 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 02:49:32 |