Network Working Group Yakov Rekhter Internet Draft Juniper Networks Expiration Date: August 2001 Daniel Tappan Cisco Systems Eric Rosen Cisco Systems MPLS Label Stack Encapsulation in GRE draft-rekhter-mpls-over-gre-01.txt 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- 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. 2. Abstract In certain cases it may be useful to carry MPLS packets through a GRE tunnel. This document describes how to do that using existing standards. draft-rekhter-mpls-over-gre-01.txt [Page 1] Internet Draft draft-rekhter-mpls-over-gre-01.txt February 2001 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 [RFC2890], 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 TBD. draft-rekhter-mpls-over-gre-01.txt [Page 2] Internet Draft draft-rekhter-mpls-over-gre-01.txt February 2001 6. References [RFC2784] [RFC2890] "Key and Sequence Number Extensions to GRE", G. Dommety, RFC2890, August 2000 7. Author Information Yakov Rekhter Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089 Email: yakov@juniper.net Dan Tappan Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 e-mail: tappan@cisco.com Eric Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 e-mail: erosen@cisco.com draft-rekhter-mpls-over-gre-01.txt [Page 3]