Internet DRAFT - draft-xia-netlmm-mpls-tunnel

draft-xia-netlmm-mpls-tunnel






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]