Network Working Group Yakov Rekhter
Internet Draft Juniper Networks
Expiration Date: March 2002 Daniel Tappan
Cisco Systems
Eric Rosen
Cisco Systems
MPLS Label Stack Encapsulation in GRE
draft-rekhter-mpls-over-gre-03.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-03.txt [Page 1]
Internet Draft draft-rekhter-mpls-over-gre-03.txt September 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-03.txt [Page 2]
Internet Draft draft-rekhter-mpls-over-gre-03.txt September 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-03.txt [Page 3]