Network Working Group                                Yakov Rekhter
Internet Draft                                       Cisco Systems
Expiration Date: January 2001                        Daniel Tappan
                                                     Cisco Systems
                                                        Eric Rosen
                                                     Cisco Systems

                 MPLS Label Stack Encapsulation in GRE


1. Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

2. Abstract

   In certain cases  it may be useful to carry  MPLS packets through an
   IP tunnel. This document describes how to do that using existing

draft-rekhter-mpls-over-gre-00.txt                              [Page 1]

Internet Draft     draft-rekhter-mpls-over-gre-00.txt          July 2000

3. Encapsulation in GRE

   If one wants to establish a Label Switched Path (LSP) over a set of
   nodes that don't support MPLS, one could encapsulate MPLS header in
   GRE [RFC2784] over the parts of the path that spans these nodes.  The
   protocol type field in the GRE header should be set to the Ethertype
   value for MPLS Unicast (0x8847) or Multicast (0x8848).

   If GRE is extended to carry the Key field [1], then in principle the
   outer label in the MPLS header could be placed in the Key field, the
   TTL field could be placed in the TTL field of the IP header, and the
   value of the EXP field may  be considered when setting the value of
   the DSCP field of the IP header.  The Protocol Type field in the GRE
   header is set to the L3PID of the LSP. Specifically, when the MPLS
   Label Stack has depth of more than one, the Protocol Type field in
   the GRE header is set to MPLS. Of course, one could observe that in
   terms of the overhead encoding the outer label into the Key field
   doesn't offer any obvious advantages over carrying the outer label in
   the MPLS "shim" header and not using the Key field at all.

   One could observe that the above approach also works between directly
   connected nodes. In this case the encoding described in the previous
   paragraph provides (yet another) way to carry MPLS Labels over a
   point-to-point or Ethernet links.  However, in this scenario this
   encoding of MPLS Labels introduces additional bandwidth and
   processing overhead relative to carrying labels just in the MPLS
   "shim" header, and no rational benefits. And it still requires the
   nodes to support MPLS, as forwarding is based on the MPLS Label.

4. Security Considerations

   Security issues are not discussed in this document.

5. Acknowledgements


draft-rekhter-mpls-over-gre-00.txt                              [Page 2]

Internet Draft     draft-rekhter-mpls-over-gre-00.txt          July 2000

6. References


   [1] "Key and Sequence Number Extensions to GRE", Dommety, G., draft-
   dommety-gre-ext-04.txt, June 2000

7. Author Information

   Yakov Rekhter
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134

   Dan Tappan
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824

   Eric Rosen
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824

draft-rekhter-mpls-over-gre-00.txt                              [Page 3]