One document matched: draft-rekhter-mpls-over-gre-00.txt
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
draft-rekhter-mpls-over-gre-00.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 an
IP tunnel. This document describes how to do that using existing
standards.
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
TBD.
draft-rekhter-mpls-over-gre-00.txt [Page 2]
Internet Draft draft-rekhter-mpls-over-gre-00.txt July 2000
6. References
[RFC2784]
[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
e-mail: yakov@cisco.com
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-00.txt [Page 3]
| PAFTECH AB 2003-2026 | 2026-04-21 12:33:01 |