Network Working Group F. Xia
Internet-Draft B. Sarikaya
Expires: April 28, 2009 Huawei USA
October 25, 2008
MPLS Tunnel Support for Proxy Mobile IPv6
draft-xia-netlmm-mpls-tunnel-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 April 28, 2009.
Xia & Sarikaya Expires April 28, 2009 [Page 1]
Internet-Draft MPLS Tunnel for PMIPv6 October 2008
Abstract
The Proxy Mobile IPv6 allows a mobile node's IPv4 and IPv6 traffic
between a Local Mobility Anchor(LMA) and a Mobile Access Gateway
(MAG) to be tunneled using IPv6, IPv4 or IPv4-UDP encapsulation
headers. In this document, Multiprotocol Label Switching (MPLS)
tunneling is proposed as an alternative tunnel technology which is
used between a MAG and a LMA. MPLS is now become more and more
popular, and MPLS support is an important function for edge and core
routers. Integrating MPLS and Proxy IP Mobility can leverage Proxy
IP Mobility deployment in the industry.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of MPLS . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
5. Local Mobility Anchor Considerations . . . . . . . . . . . . . 7
5.1. Operational Summary . . . . . . . . . . . . . . . . . . . 7
5.2. Extensions to Binding Cache Entry . . . . . . . . . . . . 7
6. MAG Considerations . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Operational Summary . . . . . . . . . . . . . . . . . . . 8
6.2. Extensions to Binding Update List Entry . . . . . . . . . 8
7. New Option . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Virtual Pipe Label Option . . . . . . . . . . . . . . . . 9
8. MIPv4 Applicability . . . . . . . . . . . . . . . . . . . . . 10
9. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . . 10
12.2. Informative references . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Xia & Sarikaya Expires April 28, 2009 [Page 2]
Internet-Draft MPLS Tunnel for PMIPv6 October 2008
1. Introduction
The Proxy Mobile IPv6 [RFC5213] allows a Mobile Node(MN)'s IPv4 and
IPv6 traffic between a Local Mobility Anchor(LMA) and a Mobile Access
Gateway (MAG) to be tunneled using IPv6, IPv4 or IPv4-UDP
encapsulation headers. Generic Routing Encapsulation (GRE) tunneling
is also introduced in [I-D.ietf-netlmm-grekey-option].
MPLS is now become more and more popular due to it's powerful support
of engineering, Virtual Private Network (VPN) and so on. Almost all
mainstream edge and core routers are equipped with MPLS
functionality. As a natural tunnel technology, it is possible for
the LMA and the MAG to tunnel packets between each other.
Integrating MPLS and Proxy IP Mobility can leverage Proxy Mobility
deployment in the industry.
The extensions defined in this document allow the MAG and the LMA to
distribute MPLS labels using Proxy Binding Update (PBU) and Proxy
Binding Acknowledgement(PBA) exchange.
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 [RFC2119].
The terminology in this document is based on the definitions in
[RFC5213], in addition to the ones specified in this section.
Downstream Traffic: . The traffic in the tunnel between the LMA and
the MAG, heading towards the MAG and tunneled at the LMA.
Upstream Traffic: The traffic in the tunnel between the MAG and the
LMA, heading towards the LMA and tunneled at the MAG.
LSR: A router which supports MPLS is known as a "Label Switching
Router", or LSR.
MPLS domain: a contiguous set of nodes which operate MPLS routing
and forwarding and which are also in one Routing or Administrative
Domain. In this document, LMA,MAG and the core routers belong to
the same MPLS domain.
MPLS edge node: a MPLS node that connects a MPLS domain with a node
which is outside of the domain, either because it does not run
MPLS, and/or because it is in a different domain. Note that if an
LSR has a neighboring host which is not running MPLS, that LSR is
a MPLS edge node. In Proxy Mobile IPv6 scenario, LMA and MAG are
Xia & Sarikaya Expires April 28, 2009 [Page 3]
Internet-Draft MPLS Tunnel for PMIPv6 October 2008
MPLS edge nodes
MPLS egress node: a MPLS edge node in its role in handling traffic
as it leaves a MPLS domain. In this document, the MAG is a MPLS
egress node for downstream traffic, while the LMA is a MPLS egress
node for upstream traffic.
MPLS ingress node: a MPLS edge node in its role in handling traffic
as it enters an MPLS domain. In this document, the LMA is a MPLS
ingress node for downstream traffic, while MAG is a MPLS ingress
node for upstream traffic.
Virtual Pipe (VP): as illustrated in Figure 2, MNs belong to
different operators, and virtual pipes are used for
differentiating operators' traffic. MPLS labels are used for
identifying VPs. A virtual pipe is unidirectional. A virtual
pipe which is used for conveying traffic from the LMA to the MAG
is called a downstream VP, otherwise a virtual pipe is called an
upstream VP.
3. Overview of MPLS
The following section provides a brief overview of MPLS. It is
intended as background information so that the solution in this
document can then be presented in detail in the following sections.
MPLS protocol cluster comprises many contents, and only operations
related to the document are introduced here.
[RFC3031] specifies the architecture for MPLS and [RFC3032] describes
MPLS label stack encoding. In these specifications, a shim layer
called label stack is introduced, and the shim layer appears after
the data link layer headers, but before any network layer headers.
The label stack can include one or more labels. Each label is
represented by 4 octets as illustrated in Figure 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
| Label | Exp |S| TTL | Stack
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry
Label: Label Value, 20 bits
Exp: Experimental Use, 3 bits
S: Bottom of Stack, 1 bit
TTL: Time to Live, 8 bits
Xia & Sarikaya Expires April 28, 2009 [Page 4]
Internet-Draft MPLS Tunnel for PMIPv6 October 2008
Figure 1: Encoding the Label Stack
In typical IP forwarding, a label is pushed to IP packets in a MPLS
ingress node, while the label is popped in a MPLS egress node. The
labeled packets are transmitted from the ingress node to the egress
node through a series of LSRs. The labels using for switching is
often distributed by Label Distribution Protocol (LDP) [RFC5036]
4. Protocol Overview
Suppose it is desired to transport traffic from the MAG serving as an
ingress LSR to the LMA serving as an egress LSR, across an
intervening MPLS network. We assume that there is a Label Switched
Path (LSP) from the MAG to the LMA through LDP or other protocols.
That is, we assume that the MAG can cause a packet to be delivered to
LMA by pushing some label onto the packet and sending the result to
one of its adjacencies. Call this label the "tunnel label", and the
corresponding LSP the "tunnel LSP". How to build the tunnel LSP is
beyond the scope of the document, please refer to [RFC5036] for
further understanding.
The tunnel LSP merely gets packets from the MAG to LMA; the
corresponding label doesn't tell the LMA what to do with the payload.
there must be a label, which becomes visible to the LMA, that tells
the LMA how to treat the received packet. Call this label the "VP
label". In this draft, new options are defined for distributing VP
labels between the MAG and the LMA.
So when the MAG sends a packet to the LMA, it first pushes a VP label
on its label stack, and then pushes on a tunnel label. The tunnel
label gets the MPLS packet from the MAG to the LMA or vice versa; the
VP label is not visible until the MPLS packet reaches the LMA or the
MAG. LMA's proscessing of the packet is based on the VP label.
As a example, Figure 2 illustrates a LMA providing mobility service
to MNs that are from different operators and are assigned IPv4
addresses from overlapping private address space. In this example,
MN-1 and MN-2 are visiting from Operator-A, and MN-3 and MN-4 are
visiting from Operator-B. In this scenario, the MAG and the LMA must
be able distinguish the flows belonging to a given operator from the
flows belonging to some other operators. The MAG and the LMA agree
upon VPs for identifying the flows belonging to each operator.
Xia & Sarikaya Expires April 28, 2009 [Page 5]
Internet-Draft MPLS Tunnel for PMIPv6 October 2008
+------------+
| Operator-A |
| 10.x.0.0/16|
+------------+
/
+----+ +----+ /
| | ============================ | | /
MN-1---| | / \ | | / VP-1
| M | / ------Flows with VP-1----- \ | L | / Traffic
MN-2---| A |--| |-| M |-
| G | \ ------Flows with VP-2----- / | A | \ VP-2
MN-3---| | \ / | | \ Traffic
| | ============================= | | \
MN-4---| | PMIPv6 tunnel LSP | | \
+----+ +----+ \
\
+------------+
| Operator-B |
| 10.x.0.0/16|
+------------+
Figure 2: VP Label Using for Differentiating Traffic
As per the base Proxy Mobile IPv6 specification [RFC5213], the tunnel
transport between the MAG and the LMA can be IPv6, IPv4 or IPv4-UDP.
When MPLS tunneling is introduced, two layer labels are inserted
before IP packet payload. The tunnel label assures the reachability
between the MAG and the LMA, while the VP label is used for
differentiating traffic such as IPv4, IPv6 and so on. Just as
illustrated in Figure 3, the MAG pushes labels before IP packets
while the LMA popes labels for upstream traffic. Otherwise, the LMA
pushes labels before IP labels while the MAG pops labels for
downstream traffic.
+---------------------------+
| Tunnel Label |
| |
+---------------------------+
| VP Label |
| |
+---------------------------+ +---------------------------+
| Payload Packet | ====> | Payload Packet |
| (IPv4 or IPv6) | | |
+---------------------------+ +---------------------------+
Xia & Sarikaya Expires April 28, 2009 [Page 6]
Internet-Draft MPLS Tunnel for PMIPv6 October 2008
Figure 3: MPLS Encapsulation
5. Local Mobility Anchor Considerations
5.1. Operational Summary
Upon receiving a PBU with the Virtual Pipe Label Option defined in
Section 7.1, the LMA records the label as a downstream VP label in
the Bind Cache Entry of the MN if the LMA accepts the binding update
message. The label is used for any IP traffic destined to the MN.
Based on the MN's profile and IP address, the LMA assigns a label for
identifying upstream traffic of the MN. The fields of label are
illustrated in Figure 1. The label value field is allocated by the
LMA for identifying upstream traffic from the MN; The experimental
field is set to zero; S bit is set to 1 to indicate this is the VP
label of the two layers label stack; TTL is set to 1 to indicate that
the LMA and the MAG are only one hop away from VP label processing
perspective. How to allocate label value is out of the scope. The
label is distributed to the MAG through Virtual Pipe Label Option in
the PBA message.
Once an IP packet destined to the MN arrives, the LMA processes as
follows:
1. Locating a Binding Cache Entry based on MN's IP address.
2. Fetching the downstream VP label, and padding it in front of IP
packet.
3. Identifying the tunnel label based on MN's Proxy CoA.
4. Encapsulating the packet with the two-layer labels, and sending
it out according to MPLS procedure described in [RFC3031].
Once an IP packets originated from the MN arrives, typically the LMA
has the following process steps:
1. Popping the tunnel label.
2. Striping the VP label and forwarding the packets to a
corresponding operator.
5.2. Extensions to Binding Cache Entry
Every LMA has an Binding Cache Entry (BCE) for each currently
attached MN, as explained in [RFC5213]. For supporting this
specification, the conceptual BCE data structure must be extended
with the following new additional fields related to MPLS label for
tagging the MN's tunneled traffic.
o A flag indicating whether MPLS tunneling is enabled for the MN's
traffic.
Xia & Sarikaya Expires April 28, 2009 [Page 7]
Internet-Draft MPLS Tunnel for PMIPv6 October 2008
o The downstream VP label used for differentiating downstream
traffic by different operators.
6. MAG Considerations
6.1. Operational Summary
Once a MN enters a Proxy Mobile IPv6 domain and attaches to an access
link, the MAG on that access link, after identifying the mobile node
and acquiring its identity, will determine if the mobile node is
authorized for the network-based mobility management service. If the
network determines that the network-based mobility management service
needs to be offered to that MN, the MAG sends a Proxy Binding Update
message to the LMA with the Virtual Pipe Label Option defined in
Section 7.1. The label is recorded as a downstream VP label in a
Bind Cache Entry of the LMA. The fields of label are illustrated in
Figure 1. The label value field is allocated by the MAG for
identifying downstream traffic to the MN; The experimental field is
set to zero; S bit is set to 1 to indicate this is the VP label of
the two layers label stack; TTL is set to 1 to indicate that the LMA
and the MAG are only one hop away from VP label processing
perspective. How to allocate label value is out of the scope.
After receiving a Proxy Binding Acknowledgment with the Virtual Pipe
Label Option defined in Section 7.1, the MAG records the label as a
upstream VP label.
Once an IP packets originated from the MN arrives, the LMA processes
as follows .
1. Locating a Binding Update List Entry based on MN's IP address.
2. Fetching the upstream label, and the label is as an VP label.
3. Identifying the tunnel label based on LMA's IP address.
4. Encapsulating the packet with the two layers label, and sending
it out according to MPLS procedure described in [RFC3031].
Once an IP packets destined to the MN arrives, typically the MAG has
the following process steps:
1. Popping the tunnel label.
2. Striping the VP label and forwarding the packets to the MN.
6.2. Extensions to Binding Update List Entry
Every MAG has a Binding Update List Entry for each currently attached
MN, as explained in [RFC5213]. For supporting this specification,
the conceptual Binding Update List data structure MUST be extended
with the following new additional fields related to MPLS label for
tagging the MN's tunneled traffic.
Xia & Sarikaya Expires April 28, 2009 [Page 8]
Internet-Draft MPLS Tunnel for PMIPv6 October 2008
o A flag indicating whether MPLS tunneling is enabled for the MN's
traffic flows.
o The upstream VP label used for differentiating upstream traffic by
different operators.
7. New Option
This section defines extensions to the [RFC5213].
7.1. Virtual Pipe Label Option
The option is used in the PBU and PBA messages exchanged between the
MAG and the LMA. The option is used in the PBU distributing VP
labels for downstream traffic, and it is used in the PBA conveying VP
labels for upstream traffic.
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VP-Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
<IANA>
Length
8-bit unsigned integer indicating the length in octets of
the option, excluding the type and length fields.
Reserved
This field is reserved for future use. The value MUST be
initialized to 0 by the sender and MUST be ignored by the
receiver.
VP-Label
four-byte field containing MPLS label.
Figure 4: Virtual Pipe Label Option
Xia & Sarikaya Expires April 28, 2009 [Page 9]
Internet-Draft MPLS Tunnel for PMIPv6 October 2008
8. MIPv4 Applicability
The main idea is applicable MIPv4 in case a foreign agent is a tunnel
endpoint. New MIPv4 options should be defined to distribute VP
labels. It will be elaborated in a separate document in the future .
9. IANA consideration
This document defines a new Option, the Virtual Pipe Label Option,
described in Section 7. This option is carried in the Mobility
Header. The type value for this option needs to be assigned from the
same numbering space as allocated for the other mobility options
defined in the Mobile IPv6 specification [RFC3775].
10. Security Considerations
There is a security consideration inherited from the MPLS
architecture. A MPLS label has its meaning by virtue of an agreement
between the LSR (MAG or LMA here) that puts the label in the label
stack (the "label writer"), and the LSR(MAG or LMA here) that
interprets that label (the "label reader"). However, the label stack
does not provide any means of determining who the label writer was
for any particular label. If labeled packets are accepted from
untrusted sources, the result may be that packets are routed in an
illegitimate manner.
In this document, the PBU and the PBA are piggybacked with label
distribution information. IPsec is mandatory to be used between the
LMA and the MAG for confidentiality protection on the PBU and PBA
messages.
11. Acknowledgements
The author would like to thank Young Lee and John Kaippallimalil for
their review.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Xia & Sarikaya Expires April 28, 2009 [Page 10]
Internet-Draft MPLS Tunnel for PMIPv6 October 2008
Label Switching Architecture", RFC 3031, January 2001.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
12.2. Informative references
[I-D.ietf-netlmm-grekey-option]
Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung,
"GRE Key Option for Proxy Mobile IPv6",
draft-ietf-netlmm-grekey-option-01 (work in progress),
October 2008.
Xia & Sarikaya Expires April 28, 2009 [Page 11]
Internet-Draft MPLS Tunnel for PMIPv6 October 2008
Authors' Addresses
Frank Xia
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: xiayangsong@huawei.com
Behcet Sarikaya
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: sarikaya@ieee.org
Xia & Sarikaya Expires April 28, 2009 [Page 12]
Internet-Draft MPLS Tunnel for PMIPv6 October 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.
Xia & Sarikaya Expires April 28, 2009 [Page 13]