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 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]